Stefan van Raaphorst – 24 April 2014
1156 words in about 5 minutes

Every strength has it’s weakness or maybe a little bit more positively formulated: every force has it’s counter force. Dan North, in his keynote speech during the Joy of Coding 2014 brought up the example of DRY (Don’t Repeat Yourself). While DRY is a industry wide accepted good practice, whenever applied on source code it inherently creates coupling. This makes it the opposite force of another valued principle: loose coupling. Leaving aside the misunderstanding about code and knowledge/concept level of DRY.

Another example I like to use is being pragmatic. While there is room for interpretation of what it actually means, I will use the following definition: “relating to matters of fact or practical affairs often to the exclusion of intellectual or artistic matters”, eg: skipping steps we artisans would always like to apply but the effort sometimes outweighs the business value delivered.

When being pragmatic this can alway be the first or following step in a death march. In other words every time the pragmatic approach is taken, a little bit of technical debt is introduced. It can be as small a not having a test for a hard to test item, which adds a tiny amount to the cost of change as there is no automated regression test. Bare in mind that the cost of change determines the life cycle of an application. As the cost of building a new feature increases, it will at some point outweigh the business value, this brings the application to the end of it life cycle.

This puts pragmatic on the side of being able to sell a product as the saving on cost meets the business value short term, but introducing cost for long-term development shortening the life cycle of the product.

Product development

In essence developing software to create a product is a balancing act around this topic.

Building features and creating business value is what wins the tender, brings home that sweat deal or attracts paying users. Without this no money is made, it is as easy as that.

On the other hand building these features in a production ready manner, puts effort in activities that are not directly delivering business value. Let me explain this, before people jump to the comment section. A perfect professional development environment has characteristics like:

To move toward these idealistic goals or a least not getting further and further away from them, time must be spent to create this. However no end user will ever praise these things, but only the derivatives, eg: Low bug rate, high uptime, etc. If we reduce the scope, or this story, to development time: spending time on these aspects enables faster feature development. So enough time must be spent on this topic to keep, certainly in the long run, enough time for building features, instead moving into the swap of ever growing bug list, time lost on regression testing, etc.

As Robert C. Martin puts it so nicely in his clean coding dojo: “The only way to move forward fast, is to move forward well!”

The same duality principle goes for design/architecture, documentation, etc. This is why the Agile manifesto is powerful in it’s formulation: while there is value in x, we value y more (makin it the leading principle). This way it acknowledges the duality in place. Unfortunately this is often mis understood.

Take away

As an artisan I am always aware of my context. People tend to call out that, which is not inline with a the leading value or principle, while not explicitly taking into account the side effect of duality.

Example: Doing xyz is not delivering business value.

Making things explicit is the key. To do so reversing this statement would lead to the following question: What is the cost of not doing xyz?

When putting time and effort on things that are beneficial for long term, be sure to understand what positive effect it has on short term value activities are. E.g. know the cost/benefit effect of keeping a tidy ship on producing the goods. This means it becomes better measurable when clean is clean enough for the current iteration or why this cleaning must be done now although of being a long term gain.

Secondly there can always be short term events like tenders, which make focus on the direct business value temporarily outway xyz action. This is however a slippery slope, because that forces to slow down and cleanup later, but later new deadlines arise putting pressure on keeping a tidy ship. As we all know cleaning a stain later is more costly at best and not possible at worst.


Both forces of a duality need to be kept in check and balances, like the eco system of the world. With the financial crisis more people seem to understand this for things like financial bonus structures, having a preposterous effect on the intended goal. Now it becomes time that product development teams, this includes the stakeholders, start to grasp the danger of only churning features. The danger being teams ending up with a big ball of mud even when starting with good intentions, product owners not understanding why the new recruits do not delivering as fast as hoped, or worse good developers that just refuse the job of developing this product. Effectively burning money on slow development or starting form scratch a new product. Going slow after the glory of cowboys whom saved the day, but put the product on costly course.

It is not an easy balancing act and it requires skilled people, both product owners as well as developers and a balanced team. At least calling out and making it explicit, offer product owners and stakeholder insights into benefits and dangers of the choices they make will help drive out overengineering, cowboy behaviour and stimulate transparency.

Often software development is compared with construction building and on this topic is actually correct: product development has the same reputation: being slower, over budget and hard to get a grip on.

So as a relatively young industry we have a long way to go to proof this comparison is incorrect. Only transparency and insight can help the business start to trust in their development team and stop putting damaging pressure on the development team. This is the challenge professional developers face, but wil gladly and without concession act upon.