By Kent Spillner - 1 October 2008
Software development projects should not be managed with the assumption that the final product would be perfect if only there weren't budgets or deadlines. Although theoretically true -- given infinite time and effort, the perfect solution would eventually be developed (along with an infinite number of imperfect ones) -- this style of thinking only sets the team and business up for failure. Instead, project teams should focus on delivering a working product today, and a better one tomorrow.
Perfect Ain't Possible
I applaud the good intentions of teams that plan to build the perfect solution, but that's not a realistic way to work. No amount of planning can account for every contingency (well, short of infinite planning, but then there wouldn't be time to develop anything!) Ditto development. Endlessly cranking out code is not a recipe for perfection. Unfortunately, it's hard to argue against such behavior. That's partly because, again, the assumption is theoretically true, and partly because it's in our nature. When people can visualize a goal, they're able to figure out the necessary steps towards achieving it. That's a very powerful capability. It's also very misleading. It requires tremendous genius to correctly figure out every step required to build something of modest complexity. And it requires even greater will power to backtrack several steps when you start heading down the wrong path.
The rapid evolution of modern business makes it impossible to correctly figure out every step, often because the goal itself is constantly changing. And the dynamic nature of software makes it especially painful to head down a dead end because developers can push code quite a ways before eventually hitting the wall. Now throw in budgets and deadlines. Not only do teams have to do everything right, they also have to do it on time the first time. Trying to build perfect components that make up a perfect whole is an uphill struggle, even without the business constraints.
Lather, Rinse, Repeat
Instead of pretending to build the perfect system, software development teams should build a good one, then make it better. Not in the next release or the next update, but in the very next build. Continuous improvement, not ultimate perfection, should be the goal. The difference in approach can be staggering. Where teams that strive for perfection end up floundering, teams that focus on continuous improvement end up delivering. The uphill struggle becomes a leisurely stroll. This is not meant to imply that continuous integration is a convenient excuse for laziness or slack. On the contrary, continuous improvement is hard work that requires discipline and dedication, just like striving for perfection does. But whereas achieving perfection is impossible, stepwise monotonic improvements are manageable.
Prologue
When I was an undergraduate, I worked as a programmer at a research lab on campus. It was a formative experience. Super smart people, great work environment, interesting problems. Then we lost our funding. That's when reality sunk in: we weren't as good as we thought. To get our ship back in order, we hired a full-time project manager. Under his guidance, we rewrote two whole research systems from scratch in about nine months. Our experience from the previous systems certainly helped our productivity -- we knew several mistakes not to make again -- but it was his approach to building software more than anything else that made us successful. I've experienced similar situations three more times since then (I'm sure I'll learn eventually). In each case, the deciding factor in the team's turn-around was a dedication to steady improvement. Instead of shooting for the moon, we worried about building better software.
Stop Hitting Yourself
That's what this column is all about. I've been a part of underperforming teams. I've pulled all-nighters to meet deadlines, fixed bugs right up to the start of demos, broken my share of builds, and had my projects cancelled. I've also been a part of alpha IT teams. I've helped put systems into production ahead of schedule and under budget, I've worked on projects that release new versions week after week without any serious bugs, and I've felt the excitement return to the office as teams respond to disaster by building overwhelming success. I want to share with you the lessons I've learned, and help you avoid the mistakes I've made. I want to offer advice borne from my own personal experiences, and help you build successful software.
It's All About the Build
I used to think that the best place to start changing software development teams was at the bottom. Get the developers to write better code and focus more closely on building what the customer wants. Now, I think it's best to go straight for the gold: the build. Builds are the only true measure of success on a software project; they're the only product that delivers value. Hence, my first column on the importance of frequent, regular releases into production.
Then what? What should you do after delivering new features and functionality in individual increments? Make the product better. You don't have to invest in making it radically better, just better. And make it better with every release. And what then? Your product is improving, let's improve the process, too! I want to help you iterate, and iterate well. I want to help you organize your work, and then I want to help you manage it better. I want to help you engage every member of your team, and I want to help you keep every member engaged. And all the while, I want you to continue pushing out new versions of your software, and I want you to make each better than the last.
About Kent Spillner: Kent loves writing code and delivering working software. He hates cubicles, meetings and Monday mornings.
No comments:
Post a Comment