Write less code

I know this isn’t going to be a popular concept and the title might make engineers walk away without reading but here we go. I think people should write less code. Stay with me; I don’t mean you shouldn’t write code at all and just buy software or anything. I am talking about the inevitable over-engineering that seems to take place entirely too often. I’m talking about all the research into LOC and it’s relation to defects count(a weibull distribution seems to be the relationship). I’m thinking of all those times I found myself writing some really cool piece of software, only to discover we aren’t actually going to need it(YAGNI). Or other times where I saw “not invented here syndrome” take hold and watched a team to just reinvent patterns that already exist in solid, well maintained OSS libraries. Not every situation is a ‘write less code’ lesson waiting to happen but keeping the mentality in the back of your mind as you traverse your problem space is a good operating mode.

We are often handed vague and unhelpful requirements for what it is we’re being asked to build. This often is the start of what motivated me to author this post: unfocused and unrefined efforts often lead to writing more code than is necessary. Over indexing on the bias towards action in modern agile has also compounded the problem. We often get pressure to deliver as fast as possible and it can result in some half baked stuff making it’s way into production. Ultimately for a given feature ask, I advocate looking at it through the lens of ‘how can we do this with the least amount of effort’ aka, least amount of code. By approaching each task with the mindset of what’s the simplest thing that could work, we set ourselves up to avoid over engineering

I am big fan of XP practices which mostly advocate for an aggressive form of iterative development, aka code to what you know, rinse and repeat. Day after day you do this. It may sound like this is advocating for writing more code but really it becomes a series of mini rewrites you do as you learn more and uncover new requirements. There have been times this process has stopped me from writing immense amounts of code and led to a leaner, cleaner solution. It often goes hand in hand with TDD approaches as well, which to me also helps set the table for clearer understanding of what problem we’re really trying to solve.

One of the biggest reasons I’ve tilted toward the writing less code ethos is we are so rarely able to pay off tech debt once it accrues sufficiently. There’s no worse feeling than showing up to work every day with utter certainty that you cannot ever pay down the immense mountain of tech debt your team has. Writing less code isn’t a silver bullet to eliminating tech debt but approaching problems with that kind of mindset gives you a better chance of building up less tech debt in the first place.

To summarize my position, I believe that writing less code often helps software teams solve the right problem, the right way, at the right time. It may sound a little foreign, but less coding and more thinking leads raises your chances to succeed.