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?
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?
5 comments:
I shifted from coding to release engineering two years ago and don't regret decision.
Quite opposite, I find this job equally challenging. My developer colleagues have hard time to understand that, for example, Maven is a framework that matches any Java framework (when builds are complicated, of course).
Enjoyed reading this :) Keep on the good work !
I enjoyed reading. My builds are small compared to Eclipse but even these small things create puzzling errors and consume a lot of my time when they fail.
Release Engineering is an art and from what I can see, you and your team are doing a superb job.
I just set up an automated buckimnster build for my client/server osgi/eclipse rcp product. It's quite simple but it took me an avarage of 50 or more build runs until I had the first successfull output, not to mention what it took to make all the tests run on the headless linux box. From now on I have all the respect for all the build engineers out there.
Another myth is that there is no cost to forcing a build restart due to forgetting to do a build submission, releasing a last minute breaking change, etc.
Just because the code is committed to the repo by 5pm on Friday afternoon doesn't mean the work is done. (yes Kim, you can quote me on that one :-) Most likely the release engineer will be starting the build, continuously checking on it, addressing problems, and posting results on their own personal time at night and on the weekends.
Myth or not, statements with excessive generalizations like:
" ... all ... "
" ... nobody ... "
" ... never ... "
" ... always ... "
" ... every ... "
make a statement seem like it's worth less than it actually is.
I really hope next time, please attack myths that are more "balanced" (reasonable, targeted, with somewhat more precision) and in the rebuttal, provide the solution that works for 80% of the time (common cases) then identify the rare/extreme cases when it won't work that way.
To prove my point, all your points in this article can be summed up as:
Myth: Every X is bad/great/whatever.
Reality: Wrong, different X need to be treated differently.
It's a truism!
Post a Comment