Software development methodologies evolution

Software development methodologies evolution

In the late 1950s the second generation computers, transistor-based and replacing the enormous punch band fed vacuum-tube machines, started the commercial usage of computers. These Mainframes had to be fed with punch cards that took days or weeks to “program” and which had to be entered into the computer in a small available timeslot. CPU usage was extremely expensive, hence off-line programming and extensive preparation of the program via the Waterfall method. The only available bullet had to be on target.

It was termed "waterfall" because teams complete one stage, fully, before moving on to the next. Requirements must be complete before moving on to functional design, functional design complete before detailed design, and so on through the sequence. And like water not flowing uphill, there are rarely provisions to return to an earlier stage of the process. Once you were finished with a stage, that stage was frozen in time. The Application Crisis Time between a validated business need and an actual application in production was about three years Source: agility beyond history

Storage and terminals

The introduction of magnetic storage in the 50’s and terminals in the late 60’s speeded up the software development process, but this was still organised based on the old days punch card practices with long development cycles in the waterfall model. Solutions for unspecified or missing features (aka bugs) and change requests had to come through the complete Waterfall cycle again. Development of large systems took years and many projects ran over budget and schedule. ICT departments and consultants started a strained search for technology and practices to better control the delivery. The Waterfall model originates in the manufacturing and construction industries in which after-the –fact changes are prohibitively costly, if not impossible. The structure and design of a delivered office tower or bridge cannot be modified anymore. For punch cards it was more or less the same, only small modifications after creation were possible, hence the Waterfall approach. Electronically stored data however can be copied and modified instantly. On top of that CPU processing power became less and less scarce so deviation from the old practices was technically possible since the 60’s.

Computing over the years

The PC era

After the Mainframe Era PC’s (with their killer apps), client/server and the internet were introduced, but still Waterfall remained and in many cases still is the preferred way of developing software. Although in theory already introduced before, it was in the 90’s during the application development crisis, when rapid development tools together with affordable PC processing power, made agile development practically possible. Agile was the natural way to go in the mid 90’s for Web Applications. Business/users did not know too much about the possibilities provided by the internet technology - many of them had never seen a webpage in their live. The traditional waterfall method was not fit for developing Web Applications. Users cannot describe something they do not even know it exists. The only way was to show the technical possibilities and in narrow cooperation iteratively develop the first Web Applications.

DEVOPS and scrum in the IT value chain

Scrum and DEVOPS

This new Agile way of developing applications revealed another problem: IT development and IT operations are miles apart. A quick and dirty “developed” mock-up running on a laptop sets expectations to users, but is far from PRD ready - “I like the App, can we start using it?” On top of that bringing a system that is development ready into PRD will also require the necessary time and effort. It will not be accepted that easily by OPS to deploy, run and manage. OPS has some valid reasons. They will be the ones called out of their bed for problems on xMas night and will take the first hit from unsatisfied users. In this area of tension developers came up with DEVOPS to bring their results of work with the users faster into production.

Read also:

Software delivery, how do the BIG guys do it?