Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
My Personal Tradeoffs
We’ve barely touched the surface of the tradeoffs involved in method design. At this point, many people just want an answer. Sadly, I can’t tell you how to lay out your methodology; I’m not in your shoes. I can, however, tell you that I’ve spent my entire career in commercial, non-government software development, and in that time period I’ve learned the following truths:
- Given a choice, my customers are generally happier with working software than with comprehensive documentation.
- My projects change so rapidly that comprehensive documentation is often a waste of time.
- Written requirements with developer review has worked well for my teams.
- Estimates done by someone who isn’t going to do the actual work are a serious cause of friction.
- Simple working system + customer-prioritized features works.
- Time spent on "process improvement" could often better be spent on skills improvement. After all, you can have a wonderful process description for how requirements are gathered, but if your analyst doesn’t have basic analysis and writing skills...you’re horked.
The answer to most of these tradeoffs is not going to be A or B, but some balance between the two that’s appropriate for your organization, your customers, in your context. I’ll leave you with just one piece of advice on how to get started: First write down what your organization actually does now, even if it’s just "I write a spec for Bob; he disappears into the server closet and comes back after a couple of weeks." After that, don’t try to develop the perfect-o-rama software methodology; instead, make small changes, one at a time. The pain of change will be less for everyone, and you can take pride in each inch-pebble change. If software methodology is a product, remember:
Simple working system + customer-prioritized features works.
Oh, and one last thing: Try to have fun.
Matthew Heusser actively develops working software and also writes and speaks on systems improvement. You can email Matt at Matt.Heusser@gmail.com, or visit his web site. He would like to thank Sean McMillan for his feedback on this article.