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’s 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 tends 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.
Practical steps towards value-driven development
Changing mindset is a journey. To get a bit more concrete and practical, here are some key topics and things to have in mind 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 solve 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.
