Quality over Features: 8 Excuses You Don’t Have To Make

Key to being able to execute Continuous Delivery (CD) is keeping your software deployable at all times. Most CD books will talk heavily about automation, but that is only part of what you need to achieve it. CD is often built on Agile and Lean foundations. Key to both of those is building quality into your process at all stages. Agile methodologies like XP have many technical practices to help developers and “building quality in” is one of the key principles of Lean Software Development.

In an organisation I have worked in, the long release cycle resulted in people let quality drop for a while. Then they spent a significant part of the cycle re-stabilising. In one of the organisations I’ve worked for, rough estimates for put this at around 20-40% of engineering time on fixing bugs on old branches. Clearly this time could be better spent elsewhere.

In a team that want to do CD, you must value being able to release software at any time. To achieve this you must keep quality high. This implies you need to value quality over features.

Over the years, I’ve seen many excuses for writing crappy code, and I’ll address them. 

FAQs Frequently made excuses

1. But we don’t have time!

Time for what? The only person who can give estimate is the developers actually working on the code. If someone is trying to beat you into compromising quality then you have bigger problems than CD.

2. But doing it right will take too long!

Shortcuts make long delays — JRR Tolkien 

Similar to the above, but developers are terrible for making shortcuts. They’re optimistic about the time saved and pessimistic about the value added of doing it right. If during a sprint, the initial investment is 20% more for the right choice, then it shouldn’t even be debated – more than likely that will return on the investment in less than a day.

3. But I’m building an MVP or prototype!

Never compromise the quality of your code. An MVP is a minimal set of features. A prototype is about proving a concept or a technical challenge. Fundamentally these are about making sure the scope of your work is correct and small.

4. But this feature is too big to implement without bugs! We’ve over-committed this sprint!

It’s not always easy but sometimes the plans have to be changed. In implementing features we learn more, therefore surprises are inevitable. Try breaking the features down into smaller parts or using feature toggles to deploy something incomplete but safe.

5. But I don’t understand this code!

Take the time you need. You shouldn’t need permission to code things right. If you don’t understand the code you’re using then how do you know it is right?

6. But I’ll refactor it later!

No, refactor mercilessly (see XP practice of the same name). Refactoring is something you do all the time. If you aren’t spending hours each day “refactoring” then your code will suffer. A feature isn’t finished if there are obvious refactoring to do: just do it.

That said do not over engineering your code; it must be fit for purpose.

7. But I don’t have a spec!

Agile doesn’t get rid of specs. It changes them to user stories. If you don’t have something that resembles a spec then how do you even know what you’re doing? 

8. But it will take only 5 minutes to explain why this code is weird!

Ideally code should be self explanatory and unsurprising. Weird code needs explaining for someone else. If you have to interrupt someone for an explanation then you’re ruining their flow for a time far greater than the help they give you. Don’t underestimate the cumulative effect of all these “5 minutes” even directly. These interruptions are an impediment to scaling a team.

Keeping code quality high should be a top priority, it will give you agility and in turn raise the quality of the product. I deliberately haven’t mentioned anything about what quality is. There are lots of practices that can help raise quality but if you aren’t trying then quality isn’t going to get better on its own!


A Programme Manager in an Agile Organisation

In a previous job, a Programmer Manager came for guidance about what he should be doing. Since that time, I’ve gained more insight into his skills and know where I could have better made use of him. I thought I’d write some notes on my thoughts.

A Programme Manager should be a communication hub. Ideally, if a stakeholder wants to find out info about something inside then they should be able to come to him for that information.

To that end, I think there are some artifacts he should maintain. When I say artifacts, I mean these things should result in web page or documents that anyone can access.


Ensure roadmap is well formed, refined. He is not responsible for populating the roadmap – that belongs to the product team but must ensure that it is flowing correctly.

Facilitates with work to the relevant teams; ensures that things are progressively refined.

Project Lifecycle Status

Knows the status of any “work”, or at least who to go to, to find out. This status could sometimes be “not started” or “maintenance”.

RAG project status

Maintains and publishes a status of any current projects in progress. That said, Agile organisations should be thinking more in terms of products than projects so this might translate better into KPIs for particular initiatives.

Maturity matrices

Facilitates the development of Maturity Matrices and the team’s current levels

Other stuff

  • Champion the process: should be involved in and help facilitate the day-to-day Agile processes.
  • Manage Risks: within the traditional scope of a programme manager. Do we need a risk register? Probably not…
  • Dependencies: Agile processes seek to minimize dependencies, but when they do exist having someone to traverse teams is useful.
  • Security: works best as a team sport and therefore should be implemented as a process.

Updated Joel Test

Back when I started my career, Joel Spolsky published his list of 12 Steps to Better code. It’s incredible how well its stood the test of time. Some of his things were from the point of view of Fogbugz; a bug database.

I’m not the first person to do this but, I’ve updated them with a more modern twist – they probably won’t last as long as Joel’s but I think my changes make them more representative of modern best practices. I’ve not changed number 5, 11, or 12. I’m pretty confident these still make sense, although I’ve never done hallway usability testing, but maybe I should give it a try!

Original test:

  1. Do you use source control?
  2. Can you make a build in one step?
  3. Do you make daily builds?
  4. Do you have a bug database?
  5. Do you fix bugs before writing new code?
  6. Do you have an up-to-date schedule?
  7. Do you have a spec?
  8. Do programmers have quiet working conditions?
  9. Do you use the best tools money can buy?
  10. Do you have testers?
  11. Do new candidates write code during their interview?
  12. Do you do hallway usability testing?

Updated list:

  1. Do you use source control that supports lightweight branching? 
  2. Can you checkout, build and run your software in one step? 
  3. Do you build (and unit test) every pushed commit? 
  4. Do you have a backlog and roadmap?  
  5. Do you fix bugs before writing new code?
  6. Do you deliver progress every sprint? 
  7. Is your spec validated automatically? 
  8. Can developers work from anywhere? 
  9. Can developers pick the best tool for the job? 
  10. Is testing everyone’s responsibility? 
  11. Do new candidates write code during their interview?
  12. Do you do usability testing?

What do you guys think, agree or disagree? How well do you score on this – old and new? What would your updates be?