Busting Build Myths
>> Thursday, September 01, 2011
Who doesn't love Mythbusters? It must be great to wake up every morning and go to work in a fantastically equipped lab, build things and maybe set off a few explosions. A dream job.
Unfortunately, my lab is filled with aging build machines, not cool toys. When a build explodes I have to pick up the pieces and make it work again. I've never been invited to the White House to talk science while sporting a snappy beret either.
Source Wikipedia: Washington Post blog, credit given to The White House/Chuck Kennedy, The White House/Chuck Kennedy
There are a few myths surrounding builds I'd like to bust. I'll use the only tool I have available to dispel them, my keyboard:
1) My six bundle build is easy. Thus your build is easy too. There is a big difference between building a few bundles and building products, p2 repositories, API tests, tens of thousands of JUnit and performance tests for many platforms. Is running an Apache server in your basement the same as running Slashdot? No. Builds are the same. Scalability issues and complexity.
2) Building with X will solve all your problems. Changing to a different build technology to compile and package your bundles can solve a lot of problems if it has been tested fully and works for all your requirements. But there's a cost to migration. To working out all the bugs and corner cases. Is it worth the transition? Only time will tell. The more complex the build, the higher the cost of migration. Yes, it would be wonderful if we could all run our builds the same way at Eclipse to help our consumers. But this requires a considerable time investment to ensure that everything works. As well, it means forgoing work in other areas to facilitate this transition. It's a tradeoff.
3) Once you get your build working, you never have to change it. As my previous post described, build scripts evolve in concert with the code base. Constantly changing. More code, more tests, more build gymnastics. Building software is like owning a house. You can try to to forgo all maintenance to save money, but your risk long term damage from broken pipes, a leaky roof or mice as the building deteriorates.
Image ©graywolfx47, http://www.flickr.com/photos/graywolfx47/4308623603/sizes/z/in/photostream/licensed under Attribution-ShareAlike 2.0 Generic (CC BY-SA 2.0)
4) Nobody in needs to understand how the build works, they just need to push a button. That's great. Until the day before a release when your build fails with a cryptic message about unresolved dependencies. And you have no idea how to fix it. And neither does anyone else on the team.
5) Release engineers are unskilled monkeys. On the weekend, I attended the Software Developer's Summit here in Ottawa. Interesting conference and it was great to meet some new people. In the afternoon, there was a meeting to discuss the long term build support with Eclipse foundation staff and other interested parties. The term "monkey" was used by several participants as a colloquial expression for a release engineer. I don't think it meant to be a malicious expression but at the same time, I found it interesting. Many developers have limited knowledge of how builds work, to them it's a big black box. Monkeys. Big black box. Hmmmm. This sounds familiar.
Source: Wikipedia. Interpretations of 2001: A Space Odyssey
Since we release engineers understand how the black box works, maybe we're not the monkeys :-)
What other build myths are out there? Read more...
Unfortunately, my lab is filled with aging build machines, not cool toys. When a build explodes I have to pick up the pieces and make it work again. I've never been invited to the White House to talk science while sporting a snappy beret either.
There are a few myths surrounding builds I'd like to bust. I'll use the only tool I have available to dispel them, my keyboard:
1) My six bundle build is easy. Thus your build is easy too. There is a big difference between building a few bundles and building products, p2 repositories, API tests, tens of thousands of JUnit and performance tests for many platforms. Is running an Apache server in your basement the same as running Slashdot? No. Builds are the same. Scalability issues and complexity.
2) Building with X will solve all your problems. Changing to a different build technology to compile and package your bundles can solve a lot of problems if it has been tested fully and works for all your requirements. But there's a cost to migration. To working out all the bugs and corner cases. Is it worth the transition? Only time will tell. The more complex the build, the higher the cost of migration. Yes, it would be wonderful if we could all run our builds the same way at Eclipse to help our consumers. But this requires a considerable time investment to ensure that everything works. As well, it means forgoing work in other areas to facilitate this transition. It's a tradeoff.
3) Once you get your build working, you never have to change it. As my previous post described, build scripts evolve in concert with the code base. Constantly changing. More code, more tests, more build gymnastics. Building software is like owning a house. You can try to to forgo all maintenance to save money, but your risk long term damage from broken pipes, a leaky roof or mice as the building deteriorates.
 |
| Homeowner forgot to visit Home Depot |
4) Nobody in needs to understand how the build works, they just need to push a button. That's great. Until the day before a release when your build fails with a cryptic message about unresolved dependencies. And you have no idea how to fix it. And neither does anyone else on the team.
5) Release engineers are unskilled monkeys. On the weekend, I attended the Software Developer's Summit here in Ottawa. Interesting conference and it was great to meet some new people. In the afternoon, there was a meeting to discuss the long term build support with Eclipse foundation staff and other interested parties. The term "monkey" was used by several participants as a colloquial expression for a release engineer. I don't think it meant to be a malicious expression but at the same time, I found it interesting. Many developers have limited knowledge of how builds work, to them it's a big black box. Monkeys. Big black box. Hmmmm. This sounds familiar.
 |
| Let's pretend these apes are monkeys. |
Since we release engineers understand how the black box works, maybe we're not the monkeys :-)
What other build myths are out there? Read more...
