The New Normal

Like many people in my generation, I studied the waterfall model of software development at both school and university level. Knowing what we do now, I often wonder if anyone thought to question it at the time. It was presented so matter of factly; it seemed perfectly normal and I accepted it as such. Many things were this way back then in fact, not just in academia. In the enterprise, waterfall was normal. Writing code without tests was normal too. Sure there was some discussion around techniques but the vast majority of companies simply ploughed on oblivious.

It's impossible to say whether companies struggle more with agile today than they did with waterfall back then, although sometimes it sure seems like it. We have to take a step back and think about the comparison we are making here though. Even though we consider it the successor, agile is still not 'normal' in our industry. Maybe that's for the best but that's not what this article is about. What I'd like to know is, how long does a technology or process take to become mainstream, to a point where we hardly even notice it's there?

"How long does a technology or process take to become mainstream, to a point where we hardly even notice it's there?"

Perhaps I need to explain myself a little better when I talk about something being 'normal'. Email is an example -something that has become normal, but as recently as 10-15 years ago was not. Brushing your teeth is normal but electric toothbrushes - although vastly superior - are not yet normal; they are still a bit of a novelty. When something becomes normal we stop questioning it so much. We are intimately aware of it's pros and cons but are happy with the results we're seeing, at least for now.

It's vitally important that we question things once in a while of course, but when we are finally happy with the trade-offs, when we stop thinking about them and trying to reason about them, only then can something be said to have become normal. Waterfall never stopped being normal - we didn't discover anything revolutionary about it or anything terrible we didn't already know - but our point of view changed when we had something better to compare against, and so the balance of pros vs cons shifted.

Agile on the other hand should have become normal a long time ago, but it's still this enigma. It's still this big thing that's going to solve all your companies problems. It's up there on a golden pedestal as the ultimate solution and we in the community are perpetuating this scenario, even if we don't mean to.

"Agile should have become normal a long time ago. But it's still this enigma, it's still this big thing that's going to solve all your companies problems"

Frequently dissatisfied with the approaches of others, every company is interpreting agile slightly differently so it never gets a chance to settle down and become a baseline that we can use for future comparisons. As a moving target, it's almost impossible to determine how to improve upon it. If we're not careful we're going to end up comparing every new thing against Waterfall instead as it's (ironically) 'stable', and we're never going to move forward. We'll have been going sideways for the better part of a decade.

It's not just agile that suffers from being put up on a pedestal. Microservices, TDD, domain driven design, functional programming. Even our good old friend OOP is still misunderstood - what become normal there ended up being a diluted, mangled form.

The fact of the matter is we keep these things at arms length because there's a risk involved. Instead of looking at the pros and cons, learning to accept the trade-offs and apply them in the appropriate situations we put them on their pedestal, admiring their glory from afar. We blog and prepare talks about how shiny they are and how amazing we are for using them - and this hyperbole is the very essence of the problem.

Things will not become normal until we start treating them as normal. Lets take functional programming off it's pedestal and stop preaching about how agile is going to change the world. Lets stop debating the optimal size of a microservice (as if that's important) instead of simply stating the facts and stressing the importance of making a sensible, informed decision.

"Things will not become normal until we start treating them as normal. Lets take our tech off it's pedestal."

Instead of all these things, we should discuss the aforementioned technologies and processes as if they're as usual and as mundane as brushing your teeth. Focus on the facts and not the evangelism, and stop giving big fancy names to things. Eventually this calm feeling, this normal feeling will filter down from the community to the wider software development world and we can all get on with our lives.

Yes we must always question things - but we need a solid baseline for comparison so we can measure our success and ensure we are moving forwards not sideways. It's time for a new normal, and believe me it's long overdue.

About the Author

Pete Smith

Pete is a software consultant, speaker & writer living near London, UK. He started off with C# and Javascript, and nowadays likes to code in Scala. He enjoys running training courses and speaking at conferences. Sometimes he works on OSS, and one time he even finished something.

Latest Tweets

Blog Tags