Worse Than Waterfall
Software is tricky to produce with quality, on time and on budget. After 70 years at least young and old in the software business agreed to that. Besides novel buzz words, styles of development and available historical lessons one object remains: record companies continue to straggle when comes to producing decent software products on the market. The question is where we are headed?
If we drive back to 1956 we would find traces of the first methodology, how to build software, published by Herbert D. Benington. He puts a hint on building prototype as fragment of the model and not to scale vast when moving from minor to large projects.
Next immense splash in the area of software development was the Waterfall methodology by Winston Royce. Frustrated by the poor quality of the software projects, the aeronautical engineer quickly produced one of the ultimate controversial models to this day: the Waterfall model.
He proposed drastic changes of how software is built and published the following diagram
Implementation steps to develop a large computer program for delivery to a customer
To this day majority of people in the software industry associate his model with this diagram. That is due to lack of understanding and never read his paper. In the strict hierarchy in the 70s, people who had nothing to do with software were defining how projects are done.
Consequently, same people never discovered another diagram he published in his paper: The iterative interaction diagram.
Hopefully, the iterative interaction between the various phases is confined to successive steps
Accordingly, in Mathematics, a spiral is defined as r = aeθ cot b, where a and b are constants, θ is the angle of rotation and r is the radius.
Using the theory that history repeats itself, but not exactly, we can apply the spiral model and based on the two software models from 1956 and 1970 we can derive a third model that combines aspects of the two models : the birth of Agile methodologies.
If we try to describe with one word what Agile stands for, probably the word ANGRY comes to mind. The revolution behind the agile was not the methodologies that produced, but the idea that software developers are finally in charge of the process and not out of touch boss.
There are countless agile methodologies, but one of the wieldiest used/abused today is scrum. One of the biggest promise crum brought was the control and the ability to minimize risk during software development.
Well, it turns out resembling every previous model Srum grew quickly abused and turned into same nowhere to be found model I called Water Jump.
Nevertheless, with Water Jump model, the process tries to fight gravity and instead of following the normal common sense, quickly adapts the non-polynomial way to getting something done.
A question comes to my mind suddenly: Are we trying to find the software philosophical stone much as the earlier alchemic? Today we can in fact turn lead into gold, but at what cost.
Using particle accelerators we can successfully mark that as completed.
Whoever, the cost is astronomical. If we apply the same concept to software we may be able to produce the perfect software one day with cost bankrupting the budget itself.
Moreover, one other reason why cost of software is becoming a bottleneck is the complexity introduced by the innovative discoveries in the last 20 years in the software domain. The ability to automate, introduced non-essential testing code, continuous integrations, continuous development, continuous deployment, PaaS, etc. creates an environment where the learning curve exceeds the turnover. This is where the rubber hits the road. Entropy is the tendency to break properties down and in this universe the entropy increases complexity.
Ordinarily, applying the same entropy concept, combined with the spiral model it shows that at one point either software programs will posses a longer life to keep know-how around, increase cost to maintain the products, or move to a fresh development model that caries different licensing agreements.
Notwithstanding, software development is at crossroads. In two years, the Agile manifesto will turn 20 years. That is similar to 200 years in normal life. Which direction we would adapt? Conversely, continue to build entropy or swing back to much leaner models with clients discovering and reporting bugs, or relying on artificial intelligence to write software?