Systems & Software Talk 

Silver Bullet Development?

This a heavily opinionated response reprint of mine to a Tech Republic article:

http://techrepublic.com.com/5100-3513_11-6049011.html?tag=search

And since RUP...

... came from Spiral (Barry Boehm) which came from waterfall (*); Barry having refined it in terms of adding a risk-based flavor - has anything really been gained here? The big bell curve of effort is still present on all projects.

(*) "Waterfall" or "Cascade" is a misnomer for, and a now classic misunderstanding of what was really iterative development. I lived on both sides of DoD so-called waterfall contracts going back 32 years. I have learned over the years that the tendency for people to misjudge a book (MIL-STD-483, MIL-STD-1679 aka DOD-STD-1679x, MIL-S-52779a, etc.) by its cover is very real. All the iterative development related fine print was overlooked by many! I suppose confusion may have come from the diagrams of components in the standards and specs. They did/do look like water flowing. I cannot argue the refinements. I am all for refinements, including the refinements made to the so-called waterfall. And to be fair, perhaps I became involved after the standards I mentioned were refined. However, I can assure you that the people developing software and systems in those days were bright enough not  to accept or even wait on items in a sequential assembly line. That "line" just did not exist. If one looks at, and understands that most of the defensive, tactical, and strategic systems that are part of the nation's arsenal and realize they were developed under the "waterfall"; perhaps one would take pause. Granted there have been issues and we certainly hear about those issues. However, the successes far outweigh the issues. As far as projects being within budget and on time, the same issues that exist in that world are found in all other projects in the outside world. In other words, the methodology really hasn't made a difference from that respect.

Sad that we now have people propagating a myth and then making critical decisions based upon myth!

A real test for the folks coming up with these silver bullets that continue to miss the mark, would be to have one or more of them magically materialize on many of any random projects and inherit some actual project work - be it definition, design, development, or testing, etc., etc. While looking "upward" and "sideways" at the project issues while under the bell curve apex, one would not be able to tell which methodology is/was in place. Agile does not change that! Invariably people end up unbeknownst to them, in a "waterfall" AKA iterative development. When it comes to crunch time and getting stuff out the door - iterative (formerly known as "waterfall") seems to be the thing we keep coming back to! Can anyone argue that?  :-) I suppose I'm blessed with having been on "waterfall" projects and iterating through tightly wound spirals!

When I see a model that actually flattens the bell-curve and actually shifts more of the work up front, in practice - I will become an avid supporter of this silver bullet! In other words, when someone invents a methodology, names it “Silver Bullet” and can back it up, I will be singing along with the Monkees, “… now I’m a believer.”

And ...
Software development "tools" have always been promised to speed development. Your statement about that is a repeating echo from the past and will echo many times into the future! I agree that improvements have been made and maybe some "squeezing" can be done relative to what you suggesr. Even so, there are many development environments that have all kinds of features that go unused. Why? Because development is already squeezed! Example: Lack of naming certain properties is one thing I used to see very often. This has a ripple effect into the automated test world such that automated test development eats up any gains made by those omissions. In these cases, the test automator has to get really creative, or the developer has to go back and apply values to properties to help make objects unique. Rob Pedro to pay Pablo!

RAM manufacturers love development tool enhancements of the bells/whistles flavor. They know bloat = more sales!

Anyway, I see no real hard evidence that development is "speedier" relative to the bottom line of getting stuff out the door. People tend to forget about the learning curves. People also tend to forget that most of the world's software ships late, has defects, and is over budget. Your company, Mr. Bogue is the world's largest offender!  Not only that, all these feature richened enhancements usually require the user to spend more money on RAM and burn more dollars on the learning curve effect. And the binaries are even more bloated. Then the "enhancer" decides, "Oh, we can speed development even more. Let us add more features!"  (How many ways does one really need to cut/paste sections of text or graphics?) The bloat cycle is repeated along with more learning curves. The users/developers complain loud and hard enough and look for a new development model and slap it in place. Again, the real problem goes unsolved. The bell curve still exists.

Points to ponder:

The RISC processor innovators got it right regarding bloat-like tendencies - do more with less...
It is a good thing many people did not believe Mr. Gates when he announced to the world that no PC would ever require more than 16KB of RAM. His own employees proved him wrong in short order!
This entire bloat phenomenon further erodes away the basis under your article about "The Declining Importance..." Some of the performance test tools reveal just how bad things have gotten in terms of bandwidth-chewing chatty applications. One need only look at the tool's recording log to see large viewstates and the chattiness of interacting with sharepoints.

I predict that Scott Adams will create two more Dilbert characters: "Bloat" and "Chatty" – the Performance Robbers.

The root causes of late, over-budget, and defect-ridden software are not addressed adequately by any methodology. The root causes are simply:
a. Over-promised/over-sold,
b. Under-delivered,
c. and poorly estimated.

Where's Longfellow? Where's Vista? I think I'll just put Linux on my AMD 64-Bit Athlon!  :)

Is there any objective evidence to show that one can "Squeeze more out of the construction phase of application development"?