(This is a snapshot of my old weblog. New posts and selected republished essays can be found at raganwald.com.)
Tuesday, July 13, 2004
What's all the fuss with the build process?
Hello!
You may have overheard C****, D*****, and B**** talking about overhauling the build process lately. What's all the fuss about?
The short answer is, we want to cut the amount of time required to develop O---- core and add ons, while increasing quality. So we look around, and what do we see? Smart people working hard. So the answer is NOT work harder. The answer is "work smarter."
Of course, not everyone agrees on what it means to "work smarter." Some people might come in here and tell us we need more UML diagrams, or throw out the C++ and start again with a so-called "better" programming language, or perhaps move everybody into their own offices and remove the telephones.
Those suggestions have some merit, but if you look around you'll find some companies that do very well using those ideas, and some that do very well doing the opposite. Let's put those kinds of suggestions aside for the moment. They might work for us, they might not. The problem with those suggestions is that they don't come with much of a guarantee. We have to study them a lot harder before trying any of them.
There's another kind of suggestion, like "hire the best people you can find." Almost every company that ignores this suggestion fails to ship software. It seems to be a "best practice." It comes with a good track record. Suggestions for producing software faster with higher quality that have good track records are priorities for us.
So back to the build process. I'm going to share a FACT with you. If you want to research this yourself, spend a few minutes with Google using keywords like "continuous integration" or "daily build." Here's the fact:
Companies that build their software more often produce higher quality products, faster.
Here are some opinions backing up this fact:
http://www.stevemcconnell.com/bp04.htm
http://www.joelonsoftware.com/articles/fog0000000023.html
Please read them both. All of them. It'll take you less than sixty seconds each. I'll wait while you read them. There will be a test later.
*****
Did you read them both? You didn't? You'll get to them "later"? Come on, read them right now, I'll wait, I really will. Take two minutes and make yourself a more professional programmer!
Okay, you've read them. Thank you. Wasn't that worth it?
Now, hopefully you're excited about daily builds. You might even want to build more often. XP zealots actually say "daily builds are for wimps": they build as they go, triggering a build dozens of times a day. Great. But we have to start somewhere. And that's why we're taking a hard look at our build process and working towards building at least once a day.
So... When you hear talk of the build process, you now know what's going on: we're "working smarter".
You read the articles, right? So you can tell me:
1. Jim McCarty wrote a book that mentions the daily build. What's its name?
2. When projects get really big, the build takes a long time. If you have more than five million lines of code, should you still do daily builds, or is your project too big for this technique?
3. Joel has a test for engineering group. How many questions are in his test?
4. Extra bonus: what's our score in the "Joel Test"?
5. Extra bonus: where can you get Jim's book?
Hello!
You may have overheard C****, D*****, and B**** talking about overhauling the build process lately. What's all the fuss about?
The short answer is, we want to cut the amount of time required to develop O---- core and add ons, while increasing quality. So we look around, and what do we see? Smart people working hard. So the answer is NOT work harder. The answer is "work smarter."
Of course, not everyone agrees on what it means to "work smarter." Some people might come in here and tell us we need more UML diagrams, or throw out the C++ and start again with a so-called "better" programming language, or perhaps move everybody into their own offices and remove the telephones.
Those suggestions have some merit, but if you look around you'll find some companies that do very well using those ideas, and some that do very well doing the opposite. Let's put those kinds of suggestions aside for the moment. They might work for us, they might not. The problem with those suggestions is that they don't come with much of a guarantee. We have to study them a lot harder before trying any of them.
There's another kind of suggestion, like "hire the best people you can find." Almost every company that ignores this suggestion fails to ship software. It seems to be a "best practice." It comes with a good track record. Suggestions for producing software faster with higher quality that have good track records are priorities for us.
So back to the build process. I'm going to share a FACT with you. If you want to research this yourself, spend a few minutes with Google using keywords like "continuous integration" or "daily build." Here's the fact:
Companies that build their software more often produce higher quality products, faster.
Here are some opinions backing up this fact:
http://www.stevemcconnell.com/bp04.htm
http://www.joelonsoftware.com/articles/fog0000000023.html
Please read them both. All of them. It'll take you less than sixty seconds each. I'll wait while you read them. There will be a test later.
*****
Did you read them both? You didn't? You'll get to them "later"? Come on, read them right now, I'll wait, I really will. Take two minutes and make yourself a more professional programmer!
Okay, you've read them. Thank you. Wasn't that worth it?
Now, hopefully you're excited about daily builds. You might even want to build more often. XP zealots actually say "daily builds are for wimps": they build as they go, triggering a build dozens of times a day. Great. But we have to start somewhere. And that's why we're taking a hard look at our build process and working towards building at least once a day.
So... When you hear talk of the build process, you now know what's going on: we're "working smarter".
You read the articles, right? So you can tell me:
1. Jim McCarty wrote a book that mentions the daily build. What's its name?
2. When projects get really big, the build takes a long time. If you have more than five million lines of code, should you still do daily builds, or is your project too big for this technique?
3. Joel has a test for engineering group. How many questions are in his test?
4. Extra bonus: what's our score in the "Joel Test"?
5. Extra bonus: where can you get Jim's book?
Labels: agile
