Topic: waterfall

Architectural Anxiety and the Waterfall Approach

Dietrich Kappe, Monday, February 8, 2010 @ 4:50 am

photo credit: bark

We've discussed the benefits of Agile development before and that the iterative approach to building the architecture -- where you explore architectural issues (very few apps are completely new and unknown) a little bit through each iteration -- is an effective method for arriving at a good application architecture. What is less obvious is the psychological benefit to working in this way.

It's frankly been a while since I've participated in a large waterfall project directly (one benefit of working for a firm that does agile software product development), but I regularly talk with folks who are still in the corporate trenches doing things the old fashioned way. One thing that hasn't changed is the BIG ARCHITECTURE wrestling match up front. Management wants to know the architecture, the guys with "architect" in their job titles want to know the architecture (so they can criticize, natch), the project manager(s) want to know the architecture. How will we scale? How will we ensure security? More useless brainpower is spent on this ultimately fruitless task -- solving problems that end up being no problem at all -- than almost any other activity in the project.

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development

Requirements Set in Stone and Software Made of Concrete

Bernhard Kappe, Monday, December 21, 2009 @ 12:06 pm

Twas the night before Christmas, and 500 pages of detailed requirements had been produced. No line of code had been written, not even by a mouse.

It sounds great in theory: You produce requirements up front, getting them so detailed that they cannot be misunderstood, you vet them with a full committee of stakeholders who will be impacted (except your customers.) Then you give it to the developes. The result: you can get a really precise cost and timeline, you'll save on expensive development time, and your CFO will sleep soundly at night.

It's a nice fantasy, but it's wrong. It's a fundamental misinterpretation of how software development works. In fact, it's a guaranteed way of increasing your costs and producing bad software.

Here's why:
If you're developing software, you're coming up with a new solution to a problem, or solving a new problem all together. Otherwise, why are you building software, rather than buying it?

Traditional requirements definition processes are a spectacularly bad way of understanding stakeholder needs, and coming up with, conveying and vetting a solution for these types of problems. You will miss certain requirements, you will over specify others, and some of them will never get used. Your stakeholders will only be able to provide feedback of limited value until the working software is actually in their hands. At that point, you will finally start getting valuable feedback that you can push through as change orders.
Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development

Under the Waterfall: The Cost of Bugs After Launch

Dietrich Kappe, Monday, October 19, 2009 @ 1:44 pm

photo credit: bobistraveling

We have a few simple principles when it comes to software guarantees: either we have developed the software according to our rigorous testing standards or the third party code we being asked to support meets some basic criterea:

1. It has full functional specifications.
2. It has unit tests that provide better than 85% line and branch coverage.
3. It has automated functional tests that exercise 100% of the user stories.

That may seem pretty extreme, but if we're promising to fix bugs on our dime, we can't have it any other way. Doing without these basic criteria is like guaranteeing you can drive from New York to Los Angeles in 30 hours, keeping under the speed limit without a speedometer and without being told what the speed limit is. Spelling it out a little more, if you can't tell me what your application should do, how do I know if it is "broken?" If I can't run and inspect unit tests to tell if individual classes and methods are doing the right thing, how can I quickly tell if my changes have broken the system? Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development

Agile Development Improves ROI – But RFP Processes are Stuck in Waterfall.

Paul Dittmann, Monday, June 15, 2009 @ 9:17 am

Agile development, when done right, results in better software at a lower cost. More and more companies are coming to this conclusion, but most are struggling with how to adjust their RFP and Governance processes to adapt.

The typical RFP process for custom software development is looking for a fixed bid, thinking this will provide budget protection and guarantee ROI. History clearly shows this is not true. Issuers expect to come within 10-20% of budget. Studies show that custom software costs can range from 50% under budget to 300% over budget. Why?

• Requirements are usually inadequate (though there is a very wide range if inadequacies.)
• The requirements produced generally have little to do with usability.
• Things change – requirements change, technology changes, the competition changes, etc.
• Too many features are built that aren’t used – studies show that 45% of features build under waterfall are never used.

Because all vendors know the above, they all take different approaches to responding to RFPs. Some try to provide a relatively accurate estimate by using historical patterns. This can be fairly accurate if they’re building an application they have done many times before using the same technologies.

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (3)

Software Development