I agree with Asterion 99.999%. Probably a sampling error…
Mitch, yeah, read that article but did not change my opinion.
Source code is not design. Design is design. Trivial perhaps, but undeniable.
It can be easily demonstrated that source code is not design by just compiling it (or interpreting it).
If what you (Mitch) states as true “Source code is design”, is true then it follows that object code is design. Machine code is design. Voltages are design etc. etc.
Where does that leave us?
I think design is a bit (heh, heh) more than voltages, don’t you?
In many organisations iterative is not an option. Typically these are large organisations requiring stage gates or accreditations to be met. And empirically, from 11 years of contracting, it is obvious to me these organisations suffer the most from runaway project syndrome.
The almost ubiquitous push for SOA from large organisations is only going to exacerbate the problem, since SOA only helps to lock organisations into simultaneous releases of large numbers of systems and hence the waterfall process. I’d really like to see KPI’s from a few organisations that have done SOA to prove that it really improves delivery times, becuase while the upside is unclear, the downside is very evident.
These stories highlight the importance of a fail fast mentality. It’s pretty hard to accidentally blow a half a billion dollars on a project with short iterations. You find problems early and either correct them quickly, change your scope, or cut your losses.
It’s wild that people work so hard to fail so colossally. I’m sure that all these projects had huge specifications representing thousands of hours of analysis and word processing. What could have gone wrong?
Source code is not design. That is the thinking that causes project failures.
I think people are starting to understand that the Gang of Four patterns are often implementation patterns and not design patterns - so it is a common delusion.
The myth that “the design is in the code” has been spouted by many so-called Gurus including Gates who’s precious Microsoft has now turned tail and is investing heavily on getting requirements and design right because the knock-on cost of post production fixes is hitting the bottom line.
Problems I see with some of the data on this page includes mixing up “gotten a lot smaller” with a move away from waterfall. Note the missing historical context of “build it all from scratch” to use of substantial open architectural frameworks which is what distinguishes them old daize with the rich open frameworks that are available today.
Smaller projects are bound to be statistically more “successful” (all things being equal) so I am not sure that the info has necessarily transcribed the source info correctly.
The problem with waterfall is the same problem with agile. No software constructionist goes back to the requirement engineering fraternity to pick up on the latest best practice in RE.
If you look at the flip, for example, between “successful” and “failed” projects you could account for it simply “a lot smaller” projects.
So how do you interpret the “limp” still being proportions as the old daize of waterfall.
Have a look around at other data.
The statisticians are still calling on my old favourite - no clown is spending time on getting the requirements sorted.
You see agile is great but unfetted requirements don’t make sense from a business perspective. Sure, hotshot developers want to have their faces licked and feel god-like but in the end the bottom line is no requirement baseline, no stopping condition.