Anti Pattern #1

Quality over features

In an Agile development we need to build quality in (Principle #9), we produce code of a high quality and don’t rush features. The code is solid. This also can and probably would be fully tested software, and automated testing if possible.

But what does this mean?

Developers often come from a background of working on old monolithic applications with thousands of lines of code spanning multiple tightly coupled applications, brittle server configurations, 3rd party dependencies, regression testing which takes weeks. A simple bug fix could take a month to find out actually what was happening in the code let alone being able to fix it, and adding a button to the main screen…. may not even be possible. These applications are really fucking hard work to do anything with. We don’t want to go back there.

Now, there’s a lot of new ‘stuff’ which helps avoid this, design patterns, containerisation, service orientated architecture, micro-services, separation of concerns, SOLID principles, automated pipeline testing, TDD, BDD, FDD, DDD, build and deployment servers, etc…

All these things help in their own ways to ensure development is easy, easy to write, easy to fix, easy to test, easy to deploy, easy to extend and just a joy to work with.

Why this can be a problem

This is actually a big problem when going from an old style fixed scope mindset to Agile. In the old days, if you needed a feature it would be hammered into the system, it may have some bugs, but could be sold. It wasn’t the best way of doing it, but what you tended to get was a high number of features and low quality. Agile flips this on it’s head and puts quality over features.

It sounds good, each feature is well developed, and tested. But it’s not that simple.

The problem lies within the extent of the quality we’re putting over features. What can and often does happen, if the team are left to their own devices their interpretation of quality will mean to develop a button on a screen which previously took an hour, now takes 3 weeks.

As a dev, I want automated testing, automated deployments, I want to follow design patterns, and push everything onto the cloud.

If you’re going to put quality over features, you first need to understand that you MUST have features, if you’ve got high quality with nothing you can sell, you have nothing.

To apply quality, we should do this in the same way as everything Agile, incrementally, ensuring we deliver at the end of each sprint.

To do this, we need to measure what we deem as quality. So, we run experiments.

Experiments in Quality

• Sprint 1 – 10 features developed.
  We want well written code, so apply code reviews.
  
  
• Sprint 2 – 8 features developed …. Is that acceptable? Yes, cool we’ll keep that.
  We want testing, so use manual testing.
  
  
• Sprint 3 – 6 features developed … is that acceptable? Yes, cool we’ll keep that.
  We want automated testing, so use TDD.
  
  
• Sprint 4 – 3 features developed … is that acceptable? No, we need to pivot.
  We want a good level of testing preferably automated, we could reduce manual testing and apply automated selenium testing?
  
  
• Sprint 5 – 6 features developed….

Quality is good

Having worked as a software developer for over 20 years, and still developing now in my spare time, I don’t want to go back to the dark days of working on these huge old systems, hammering out a feature overnight to hit a deadline just praying it doesn’t break other parts of the system. I wouldn’t want to put things out that aren’t tested, and I don’t want some other developer to curse the shit code I’ve written. Not a chance, but you can’t be a purist about this. But as a business owner, I know you have to sell something. Quality and features are both highly important, but both must be a comprise.

If you don't have an unlimited developer budget, then this really is the way you should introduce the quality aspect of quality over features. If quality is going to be the centre of your world, and it comes before features, which it should. You need to be able to quantify it, comprimise on it, adapt it, and you HAVE to deliver features.