If it ain’t broke, don’t fix it. Or, what?

When I  promised to write about how to reduce friction from developers’ work day, I am sure that most expected me to focus on what non-developers ought to do in order to improve the working lives of developers.

But let’s face it, the major cause of friction, crappy legacy code, is our own fault. Developers wrote that crappy code, after all. So let’s focus on what we can do about that.

Software developers have a natural tendency to keep the hands off code that already works. After all, conventional wisdom tells us that it is a bad idea to try to fix something that works.

Such conventional wisdom often makes a lot of sense, even in the world of software development; any change involves an element of risk, and you surely do not want to risk introducing bugs unless you need to.

On the other hand, we need to think about the risk of not changing code. This risk is often overlooked, so I was happy that Martin Fowler in a recent article on the second edition of his Refactoring book reminded us that he was impressed while working with Kent Beck because,

[…]one thing that really stood out was they [sic] approach he took to continually reworking the code base to keep it healthy[…]

I strongly suggest that serious software developers dig into the wisdom of those two gurus (Martin Fowler and Kent Beck) in order to understand why code which is not continually trimmed will actually rot.

In my humble opinion, there are numerous reasons for constantly trimming code. For example, new requirements cause existing code to get in the way of changes, or as time goes by you get wiser on the underlying problem you are trying to solve. In short: When you get wiser, use that wisdom to continually improve your code.

If you don’t continually trim your code, if you postpone needed refactoring too long, then you end up with unmanageable code that you wish you could rewrite from scratch. Rewriting from scratch might be the only feasible option, but you will probably nevertheless have to focus your time elsewhere.

Don’t get me wrong here. I have written code which still runs unchanged after many years without needing a change. In the rare cases when this happen, don’t change the code just for the sake of a principle.

Still, in conclusion, even when code works, if the way the code is crafted is no longer good enough, you really should change it.



Frictionless Programming

It has been my plan for a while to start writing about all the things that make a software developer happy and active –  or loyal and productive, if you prefer to see it from a manager’s perspective.

When I am asked about my opinion on the topic, I usually mention that I need the right challenges, good colleagues, a decent work/life balance – and a fair compensation.

But if you have all that and you still feel frustrated every work-day, it might be because of what I intend to write about in future blog posts – too much friction.

Friction to me is everything that gets in the way when I need to get my work done. Friction to me is hour-long check-in times, processes that slow me down rather than helping me to get things right, using mind-sets, frameworks and tools that simply do not belong in 2018, and so much more.

At the end of the day, all I want is to look back and see that I actually managed to implement functionality that will benefit my users.

In future posts I will give examples as well as my opinion on what to do in order to achieve true frictionless programming.