It’s tempting: You need to solve a problem and you know that in 6 months time you will need to support a related feature. Instead of just solving your current problem, you now start to think ahead, realizing it will create more work once your team starts working on this new feature. You start to see ways that you could prevent some of this refactoring work, perhaps by introducing some extension points, maybe an interface or an abstract class is needed and then the code will be beautiful, well organized and you have done your professional duty.

Wrong!

What you have actually done is:

• Introduced more code as needed to solve the current problem.
• Introduced complex abstractions, increasing complexity of the code base.
• Code that requires review and perhaps additional unit- and end-to-end tests
• Code that makes it harder to read and understand the code of the current feature.
• Written code that is very likely to never be needed or will likely anyway need to be rewritten when the actual requirements of this future feature are known.
• Increased time-to-market by not focusing on what is needed here and now.
• Created more work for everybody involved: More discussions, more testing, more documentation.

While this may seem a bit over-dramatic – you just wanted to be a bit proactive for this one particular upcoming feature – the problem is that once you go down this road, this way of thinking starts to creep into every feature being developed and the end-result is a 10x more complicated code-base than needed to solve the actual here-and-now business requirements.

As developers we often do this out of the best intention, we do it because we care. We tend to think that a code-base that is not well prepared for future requirements is full of technical debt. We will blame business management that not enough time is reserved for managing this technical debt – when in reality we mean doing unnecessary complex refactorings that prepares for vague future requirements.

We also do this because we are seniors, because we have confirmation-bias based on past experiences – we tend to remember the times where upfront code preparation was well invested, but forget about all the other times where it was simply a waste of time.

In my previous post, I discussed deliverying value over tech obsession.
Changing to a value-driven mindset is a journey. In this post I go a bit more hands-on and outline a couple of key topics that have helped me on mine so far.

The agile movement and Scrum

Agile development is all about delivering value as early and often as possible.
In Scrum we do this through sprints where at the beginning of each sprint we consider what we can do in this sprint that will bring the most value to our end users.
A sprint is 1-4 weeks – with 2 week sprints seemingly the most popular.
Done right, real business value is delivered even after the first sprint.

Real agile development is a collaborative effort in which the end users are driving the needs of the application. Be vary of long-term product visions worked towards in sprints, this tends to violate this principle!

However, it is fully possible to work agile and use Scrum and still build overly complicated solutions. As developers we are still susceptible to tech obsession and it is easy to argue for over-engineered solutions even within the context of an agile Scrum team, it only requires convincing the other team members.

An agile process does not equal an agile mindset!

KISS & YAGNI

“It seems that perfection is reached not when there is nothing left to add, but when there is nothing left to take away” – Antoine de Saint-Exupéry

Keeping solutions simple and cutting away features you are not going to need anyway, is easier said than done. While the principles are easy enough to understand, it takes practice to realize the full extend of these principles applied to software development.

Look for the simplest possible solution that will solve any given problem and try not to disregard the idea just because it might seem “ugly” and go against everything you have learned thus far. There is a good chance the simplest solution is the right approach, bringing the most value here and now to end users and that your disregard for it is based on years of indoctrination in a technology-focused mindset.

While we, as developers, tend to think of these principles more from an implementation point of view – even more important is to apply these on the conceptual level. It is easy to create product visions that will take months to implement. When approaching new product ideas, try to find the very essence of your product and think hard about what would bring the most value with the least amount of effort. Ideally you have a small prototype after the very first sprint that can already be used to illustrate the core concept.

Act like a surgeon

When building new products, we want to start as simple as possible. Every time you are introducing tooling and frameworks to your solution, you are increasing complexity. This complexity will cause hard-to-debug problems, you will have to research more in-depth how the framework or tool actually works and you will end up spending a lot of valuable time on this – time taken away from actual product development.

When the need arises and you have to introduce a framework to solve a given problem, think like a surgeon. We want to go in, fix the problem and do as little harm as possible to the surroundings.

The best frameworks solves one problem. When we introduce a framework, we want the one that fixes our problem with as little effect on the rest of our code as possible and with the least amount of additional complexity introduced. Stay away from frameworks that tries to solve every problem within a domain, these tend to be super complex and have a huge impact on the way you write your application as well as making your application much harder to debug.

Good enough is good enough

Accept solutions that are not perfect. If the solution is fit for purpose, it is good enough.
Striving for perfection tends to increase complexity and is very time consuming with diminishing returns on the value delivered.

Accept that good enough is good enough and you will be able to deliver value more frequently.

I’ve been there. Most developers have. Most developers stay there:
Over-generalizing solutions and obsessing over tech.

Sure, we’ll rationalize about it. We’ll argue things like:

• We’ll need this in a year from now, to support feature X.
• Let’s make sure we can extend this data in any way we want in the future.
• This code should be reusable, so others can use this for their projects too – while we’re at it, let us turn it into a library/framework.
• If we just develop this tool now, we’ll be able to work 3x faster in a couple of months.
• Community Best Practices say we should do it like this, these are proven practices that will make our product better.
• We can do this 10x better than those guys who wrote library X, give me 3 weeks and you’ll see.
• This is never going to be performing/scaling once we get to 10.000 concurrent users, we need to make sure everything is optimized for launch as we might get slashdotted.

What is much harder to admit is that we are often rationalizing about this, because we do not want to admit that we want to build something in a certain way because it is fun, motivating, exciting and a great way to learn some new tech.

Catering to our technology fetish however, we tend to end up with:

• Over-complicated solutions, often orders of magnitude more complicated than needed to solve the given business needs.
• More code. Even if you write the most readable and maintainable code possible, more code is still more code – more to read and more to maintain.
• Technical solutions that are hard to hand-over and hard to introduce new employees to.
• A lot of wasted effort that usually amounts to zero – yes zero – business value.

Value as motivational driver

While obsessing over tech can be very motivating, fun and exciting, nothing really beats seeing your hard work in the hands of the end-users. Seeing their reactions, getting feedback and knowing that you (hopefully) improved their life a tiny bit with your new release.

If we are not releasing often, we tend to forget how motivating this actually is. The less often you release, the more likely you are to fall into the trap of finding motivation in tech solutions instead.

Value-driven motivation tends to align with business expectations and goals, tech obsessed motivation on the other hand tend to go against these. While it is easy enough to convince the business that we need some fancy tech, our goal should be to bring as much value to the business and end users as possible.

Interested to know how to approach this more practically?
See my next post Practical steps towards value-driven development.