SDLC, Waterfall versus the rest of the world!

The readings we had this week were very interesting. They are all pretty old by computer standards, [which is depressing, in that one was published the year I left school]! You look at them all and the universal theme is that how teams were doing the software development lifecycle is bad. You scratch below the surface, and you see they are all operating in a world of waterfall. In that sole subject area they are correct. But I have a problem, read on to learn why.

I have worked in a waterfall world. Put simply we have a big bang release every year. I worked for a games company. The game went to customers for Christmas, and we cut our master in November. So we developed code all year, and in the month before we cut our release we all worked 20 hours a day and 7 days a week to get things done [not unlike our friends in the soul of a new machine book IMHO!]. When we had an issue we went back to the start, and it was an utter nightmare. I think back and I'm amazed how we got things done, and Im also amazed as how terrible our software really was at the time. But we got away with it, as people loved it, and also we had a dedicated team of work-a-holics who fixed issues quickly.

So in this waterfall world the Software Development Lifecycle [hereafter SDLC] is indeed pretty rubbish. As a simple example, you design something, you write many months code [maybe several thousand[s] of lines], and then in test you find an issue[s]. Of course this is stupid and terrible, as the bug could be anywhere and could take a long time to find and fix [think finding a needle in a stack of needles!]. This takes time, and is very costly in terms of human time, build and deploy time and time, this is time not spent adding other value to product, and basically costs money on any metric you care for.

This is why many companies have moved to an agile world [which we speak about later in the course]. It is why the software world is slowly moving to micro-services and continuous delivery. In this world, the SDLC is fantastic.

Let's take an imaginary payments service, from an online company. In a Waterfall world you will have a massive service doing all kinds of payments, incoming and outgoing . This old school payments service could be dependent on other services or indeed other services may be dependent on it. So you can break other stuff, and other stuff can break you. This service does many things, so most of it can work fine, and one small bit can cause havoc. You would likely build and release it to live every month, quarter, year or something like that. If it's broken you won't send or receive any payments. Your company is dead and losing many euro every minute, in terms of hard cash and customers going somewhere else.

In the modern world, you won't have a single payments service, you will have 20 [or so] 'micro services'. Using last week's reading, your development team will have spent time untangling the payments ball of wax. Each of these micro services can be built on their own. They should work on their own. So ifor another easy example, 'Payments.Outgoing.CreditCard.Visa' is broken and therefore, your automated outgoing payments to visa may not work, 'Payments.Incoming.CreditCard.Visa' should still work and is totally unaffected, you folks paying you with Visa works fine. Not to forget that 'payments.*.mastercard' was never affected.

In this world, the issue is very localised. You should know the exact problem and location quickly. Therefore you should be able to identify who is needed to examine, code and test a fix. You should not require 20 people in a room! It should not take months. Its quick and easy [..most of the time!] :)

So my personal issue with this week's readings is that, they are outdated. When the papers were written, the issues were very real, Now, these issues don't exist in the modern world as even companies I know of who release in a waterfall manner, develop behind the scenes in an agile world and want to break up and untangle their services. [But that being said, these papers are good for academic study such as ours, in class!].