Wednesday, August 06, 2008 12:09 PM
Software Engineering Methodologies are a great way of selling textbooks.
Waterfall, Extreme, Agile, every couple of years there's a new style, a new buzzword, a new technique that will Solve All Your Problems, Meet All Your Deadlines, and Reward You With Meats, Cheeses, Riches and Massive Job Satisfaction.
I was recently asked which methodology I like best. Slayer or Pantera? Levi's or Wrangler? My apathetic response was met with puzzlement, and then with headshaking. "Grumpy old bastard, should have known..."
But I'm not that old, and I'm not that grumpy.
I believe that it is valuable to have a systematic approach to building software, and that any method (let's drop the '-ology', my wrist is already sore) is better than no method at all. I just don't buy ionto any particular one. I just don't believe that the way you structure your development cycle is more important than maintaining discipline within those cycles in order to incrementally build and enhance a product.
(Don't get me started on people who don't understand that development it is, indeed, a cycle). Any software project that doesn't follow this cycle is going to fail, regardless off the 'Methodology' fromt he textbook you chose because it had a busty geek chick on the cover (yeah, I bought that one too.)
0. REQUIREMENTS
If you got no requirements, you got no product. Either you're gonna be out of a job soon, or you're living the glamorous lifestyle of a Hollywood hacker. If you were not involved in a car chase, a shootout, or a cocaine-and-hookers binge in the last twelve months then you need to be asking for requirements
before your project can proceed.
1. DESIGN
Design is paramount. If there's no design, or inadequate design, it doesn't matter how strictly you adhere to your Methodology.
Make sure you address the requirements. Design for the future, but make sure you address the requirements of the present--otherwise there is no future.
You don't have to design every last class and routine up front, but the high level design needs to be set in stone before a project begins. No design is going to be one hundred percent perfect, so you have to allow some wiggle room--but have a big picture design and stick to it. Smaller subsystems may be designed later in the process, but be wary of spending too much time on this--if a small feature requires a lot of design, either it needed to be part of the grand scheme or you're fiddling. Don't overdo it.
2. SCHEDULE
Once the design phase is done, the implementation effort needs to be properly planned so that those designs can be built out in a logical and efficient way, according to sa chedule--no matter what 'method' you are using to determine that logic or schedule.
You have to have a detailed schedule if you have a deadline. And there's always a deadline.
3. IMPLEMENTATION
Stick to the design as closely as possible. The more design decisions you break the shittier the codebase becomes. Higher level design breaks cause bigger problems. It's that simple.
Be honest about the schedule. If you've slipped it needs to be reported, not covered up--the sooner that a problem is known the cheaper it is to fix it. This will allow you to address the problems properly, rather than running around screaming, pointing fingers, laying blame and finding scapegoats when the deadline is missed, the budget is blown or the project is a failure.
If the schedule slips too badly or the design is broken too many times you're in real trouble, probably because insufficient effort when into the design and planning phases.
Don't break the build. The source repository is not a backup drive. Don't check in code that doesn't compile or link, you may very well end up forcing the rest of the team to be idle while you fix the problem--or forcing somebody else to fix your mistake. If you need to version broken code start your own local source repository or take a branch.
Hack Smart. Sometimes you have to take a shortcut--something isn't done in time, something didn't work, some pieces didn't fit together right, something was missing in the design. If you have to hack, do it smartly--document exactly how the hack was created and why. Even hacks should be well written and object-oriented--if the hack is clean enough it may become part of the design (an adaptor class, for example). Hacks should be easy to remove when the problem you're hacking around has been resolved.
Refuse New Features. Even if they fit the design--or seem to. They're not on the schedule. Even if the customer agrees to change the schedule you should resist--scope creep is insidious and demoralizing. Take the moral high ground for once. Grow a spine. You're not gonna win this every time, but, if you don't resist you're going to get caught in the Neverending Story--and that usually ends in failure of one kind or another.
4. QA
Schedule enough QA time. You know this never happens, but now is a good time to start.
Be super-disciplined about code reviews, bugfixes, unit tests. Lock the codebase down. The closer you get to release the fewer checkins should be allowed and the more closely vetted they need to be. If this means that a big part of the team is sitting idle, then... good. They deserve a break. At this point it's cheaper to pay them to surf google than to introduce more bugs.
Laugh rudely at anybody who suggests a new feature be added.
5. SHIP
Champagne and caviar all around.
6. CLEAN UP
Clean up the puddles of vomit and the empty pizza boxes. Conduct your post mortems.
7. NEW REQUIREMENTS
Gather new requirements.
Analyze failures in the previous cycle or cycles and correct them, wherever they lie--in the design, the scheduling, the team structure, wherever.
8. GOTO 1.
// ******HACK****
// This should have been a do-while loop. I screwed up the design of the article and now I've had to HACK to get it done in
//time.
NEXT UP: (Whenever that might be): Smarter/Stupider User Interfaces.
-- JF