Breaking Down Software into Smaller Units

In the last decade leading HackerNoon, I’ve worked with a lot of talented software developers, and early on in their tenure, I usually end up saying the same thing: ship smaller units of software and limit the size of your local host branches. Why? Here are the two key reasons and one big ole but:

1. Users reap more benefits from – and give feedback to – your work while you continue to work towards completing the project.

If you have a project that’s 6 months worth of work, and doesn’t go live for 6 months, that’s 5 months and 30ish days of the users reaping zero benefits from your work. Only when it’s live can the rest of the internet even have a chance to benefit from what you ship. And even then, that’s just when the massive uphill battle for adoption starts. If you were to instead ship part of the project every week, users would start to gain value over the lifecycle of the project.

Dane Lyons, my former colleague, once put it to me as “we should continue adding atomic units of value and do as many releases as it takes. We could easily have 10 releases on [functionality] before we’re happy with it and ready to move on.”

As the CEO, I often judge new hires on how long it takes them to become profitable contributors. In sales, this is more cut and dry, did their sales exceed their compensation? There’s of course other things to consider, like marginal costs on marketing, infrastructure, etc., but however you slice it, it’s more difficult to measure how a software developer impacts the bottom line than a salesperson. If you are ramping up in a new role as a software developer, I recommend successfully trying to string together singles before going for home runs.

In the game of software development, there are no universal rules for what the score is. Sure some people assign point systems and others define KPIs, but at the end of the day, it’s the people using your product who determine if and how you are creating value or not. By shipping sooner, you receive feedback sooner. The people using your software will make it more clear how to build and not build the project’s next atomic unit.

2. The further your branch deviates from production reality, the harder it is for teammates to contribute to your project and move adjacent projects forward.

The externalities from not shipping the most up to date version can be harder to see at first. Everything is connected. In a product like HackerNoon for example, the profile page and story page do not exist in vacuums; they exist as connected pages within one product. If changes happen to how one page functions, it affects how all pages connected to it function.

If your local branch is very large, other changes that happen on pages or functions connected to it, will often not work once your obese branch finally ships to production. This breaks things. This creates bugs. This forces the need to redo work. This creates a desire from your teammates to want to not work with you. This could even create a product experience that is worse than the one you already had, before all the work you put into your local branch.

By making smaller changes more regularly you are empowering others to contribute. They feel what they ship will also work because you both already agreement what the production baseline is. Incremental is your bff. It connects you to reality. If the incremental changes are negatively affecting the product, what makes you think larger changes in the same direction will positively affect the product experience?

And the big old but is: don’t be afraid of bold projects that may become branches that are too large because you are a bad mofo that is capable of making a difference to how this fucking thing works for people.

Some projects simply have to be large branches. For example, things with massive dependencies like new databases can just be so ingrained in existing usage that it’s best to turn back the clock and approach the project like a yearly on premise 2.0 release. And other breakthrough technologies, like ChatGPT, took so long to build that it just wouldn’t make sense for adoption to release an untrained, incomplete, shit UX version of the new technology. Take big swings. When you have the runway. When you have the team onboard. But don’t grandiose yourself. Most of the time software development isn’t reinventing the wheel. It’s simply shipping the next atomic unit.

This article was originally published by David Smooke on Hackernoon.