An excellent article by Matthew Heusser about the tradeoffs in designing a software development methodology. I’ve been involved in software development for over 20 years as a developer, designer and architect, both within software product companies and as a systems integrator or consultant to large organizations’ IT departments, and I’ve seen a wide range of software development methodologies from rigidly-imposed waterfall to much more agile techniques. Many of my customers are large and conservative, and tend towards the more rigidly structured methodologies that fit into the larger corporate budgetary process. Heusser nails the problem with that:
For example, if the organization wants accountability and predictability, it may require documented requirements with various levels of review and signoff, and create a change-control board with the power to line-item veto changes in requirements that may affect schedule. Everything sounds good so far…until about six months later, when the VP of New Product Development can’t get the feature set changed in order to respond to a market demand. Some ninny down in software engineering is holding up the company’s ability to deliver products to customers, all in the name of “process improvement”!
He also examines the tradeoffs between estimates and code, delivery date or features, control or productivity, and organic decision making versus mechanic. He’s obviously a fan of agile development, preferring (like me) to get a simple working system in place first, then let the customer set priorities on what features to implement next.
(via Managing Knowledge Processes)