I want to admit that it took me quite a while to write the bowling code. Part of the reason is that I am very simply *not* a super fast coder (hence my blog title). Never have been.
<digression selfserving="1">Fortunately, my lack of blinding coding speed has not been an impediment to my career. In every job I've had, the actual time spent coding is small compared the the time spent doing all the other things that a programmer does. So if I'm slower at 15% of my job, and just as fast (or faster) at the other parts, my overall productivity is on par with the coding cowboys. If you need a code jumper, I'm probably not your guy. If you need code that will stand the test of time, I probably am.</digression>Anyway, when I started writing the bowling code, I tried using a TDD approach. One common practice with TDD is to not try to design an ideal system up front, but to only code the minimum required to satisfy the current test set. I call this the "short time horizon" approach to design. I've heard Agilists also argue in favor of a short time horizon -- only design your current iteration's software, and if that design turns out to be inadequate for future stories, refactor as needed.
The idea is that by not over-thinking the task at hand, you can do it ... (insert ominous music here) ... faster. Get something working now. Worry about the future when it arrives.
So, when I started writing the bowling code, I only looked ahead to the currently-written failing test. Being an old C programmer, I started with an array of 10 "frame" structures, each with 3 "rolls". It wasn't until late in the cycle that I included a test case with two strikes in a row, causing me to realize the difficulty in looking forward 2 rolls in a frame-based structure. I changed the data representation in a fundamental-enough way that the vast majority of the code had to be modified / re-written.
No problem, right? TDD and Agile is all about refactoring, right?
The danger is that time pressures will result in less refactoring, and more hacking and patching, leading to brittle software that takes a long time to maintain and enhance. It's always cheaper to hack in this one little feature *without* the refactoring, so the refactor rarely gets done and you end up with a mess. Ultimately, customers suffer from buggy software releases due to unmaintainable code.
Mind you, I don't blame "management" for this! (At least, I don't *only* blame management.) Any time I've gone to my manager -- be it project, product, or administrative -- and said, "It's time already! We *need* to refactor this code," they've always made time in the schedule. Sometimes, we've had to debate the definition of "need", but when I've pushed hard enough, they've always agreed. It's the programmers themselves who push back just as often, sometimes out of an assumption that management wouldn't agree, other times because they're just sick and tired of the code, and want to move on. With this bowling project, I was programming for fun, so I didn't mind re-writing it. But it still would have saved me a lot of time had I spent 15 minutes or so thinking and prototyping before deciding.
In the bad old pure-waterfall days, we tried to get the approach right during one marathon design phase, before line 1 of code was written. It resulted in low overall productivity, and still didn't eliminate the need to refactor. I firmly believe that the rapid cycle encouraged by Agile and TDD is a good idea, but yesterday I let the pendulum swing too far the other way. I should have been more meditative up front. :-) And I guess that's my point here: balance. Don't design to death, but also don't let TDD and Agile be the death of design.
---
Update: Who knew there was a whole movement around slow programming? (Thanks John!)
- http://en.wikipedia.org/wiki/Slow_programming
- http://ventrellathing.wordpress.com/2013/06/18/the-case-for-slow-programming/
No comments:
Post a Comment