When X is not 'built-in' anymore ...

When X is not 'built-in' anymore ...

I'm not really a Scrum aficionado. Actually I'm pretty far from calling myself that way ;) But I can still remember the moment years ago when I was reading through Scrum Guide & some accompanying materials and I've found out a term that has really caught my attention:

"the quality built-in"

It may look inconspicuous, but in fact it's a very powerful concept. It can be described with the following statements:

  • once the product has a desired level of quality, the effort to keep it there (at that level) is very low but continuous
  • once the product's quality has decreased, getting it back to previous level of quality can be very expensive or even practically impossible

In other words, this concept is all about:

  1. importance of setting the standards high since the very beginning
  2. huge cost of negligence and "rotten" compromises - when you sacrifice high standards for the temporal velocity boost, the future recovery cost very quickly surpasses by the level of magnitude (!) whatever you temporarily gained due to this sacrifice

In practice, very few manage to recover at all ... The new low becomes the new standard. Until next time (next trade-off).


After few years of extensive practice in software engineering, I've learned that this concept - of "X built-in" - applies to many other Xes, not just quality!

All kinds of automation (test, infra code, etc.), living documentation, architectural conventions, holistic domain model - they all fall under the description put above: are relatively easy to introduce in the beginning & ultra-expensive to bring into mature, complex solution with more than few years of history. That's why it's so hard & expensive to conduct test automation of legacy platforms or even to fix (by automating) their deployment pipeline.

I'm not saying there's no place for trade-offs. Or sacrifices. Reality claims there has to be some :) My point is about being very conscious when making such decisions: giving up something that was a key factor of your success until now for some temporal gain may not be a reasonable price when you look long-term ...

Sebastian Gebski

About Sebastian Gebski

Geek, agilista, blogger, codefella, serial reader. In the daylight - I lead software delivery. #lean #dotnet #webdev #elixir. I speak here for myself only.

Comments