The Problem With Your Software Isn't in the Code
Actually, it might be — but even then it's (almost) always a reflection of another problem.
Actually, it might be in the code — but even then it’s (almost) always a reflection of another problem.
I’ve worked in software development since 2013, and over these almost ten years I’ve seen a lot of good and a lot of scary things in the field. I used to believe that, after all this time, software companies would have figured out that no client pays for source code (whether well-written or not) — they pay for a problem solved. Unfortunately, that still hasn’t happened, and there are companies chasing their own tail, thinking the problem is purely technical.
Our main goal, as software professionals, should be finding a simple and efficient way to solve problems — and only then worrying about beautiful code with 100% test coverage.
Don’t get me wrong, I think well-written code and good test coverage are essential, BUT that shouldn’t be an excuse or take priority over adding value and shipping a feature that actually makes sense for your client’s problem.
Photo by Daria Nepriakhina on Unsplash
It’s relatively common for software teams and companies to focus on shipping code and clearing as many tasks off a board as possible, forgetting that every piece of software is part of a product — and a product needs to do one thing well: add value for whoever uses it.
Shipping 10 features with 100% test coverage, plenty of lines of code and commits, that will only ever be used once by an internal user of the system has far less impact than shipping a single end-to-end feature that the end user can actually interact with and get real value from. In other words, one shipped feature that solves a real problem is infinitely better than a dozen that don’t.
And here’s where we get to the heart of the discussion: even though we have people with titles and the responsibility to gather requirements and prioritize tasks, this is something that should be everyone’s responsibility. That’s where the problem with your software (or even your company) actually lives — and that’s what I want to bring 5 reflections about, to help you share that responsibility better.
1. Train junior developers
In recent years, nothing has recharged my professional batteries more than getting a team of new developers eager to learn and grow. It’s a hard, tiring task, but one that should be part of every company’s growth process — and it’s the perfect moment to teach that ownership over a product matters more than the amount of code produced.
These professionals, early in their careers, are eager to learn and code, but also to deliver value and be recognized. Teach them to spot what actually delivers value, to push back on peers when a prioritized task doesn’t match the product’s direction or the current iteration — and they will undoubtedly help you go further.
2. Think about technology, but don’t let it limit you
As a software company, technology obviously plays a huge role day to day, but don’t get too attached to it in order to deliver results. Your client cares more about having their problem solved than about knowing whether it was solved with language X or Y.
It’s the role of the more experienced engineers and developers to have the final say on which technologies are used, but in my experience, the simpler, more standardized ones — the ones that make it easier to onboard new people — usually make it easier to deliver results too.
The team’s experience should also be part of that equation, because no matter how cool the trendy new technology of the moment is, it takes time to build a team mature enough to solve problems with it. Which brings us to the next point…
3. Money isn’t infinite
Wouldn’t that be nice?
Money is a finite resource. Those who have little need to save it, and those who have a lot don’t want to lose it. So every decision about architecture, tooling, and services needs to take that into account. A brilliant idea with no funding to execute it is the same as no idea at all.
The amount of money you have available is like the length of a runway. If you’re focused on the right activities and execute them well, you can take off even with a short runway — but you’ll never have enough runway to take off if you spend your time painting the plane instead of building one that actually flies.
Make sure your team knows this too, because it directly affects how tasks get prioritized and how tools and technologies get chosen (or replaced).
4. Ship small, constant deliveries
Every piece of software tends toward infinite — there’s always one more feature, one more screen, and (unfortunately) one more bug to fix.
Breaking deliveries into small pieces, besides keeping a continuous delivery flow, helps you “test the water” and better guide the prioritization of upcoming tasks.
In a normal scenario, the ideal is to always prioritize the “next most important task” and make it your team’s delivery artifact — whether that delivery cadence is monthly or (as I’d recommend) weekly. This keeps your team more focused, since the focus stays on that one task, and it keeps your client satisfied, because you’ll always have something ready to ship with minimal risk of delay.
Bad prioritization calls will happen — we can’t avoid that — but small deliveries help minimize the impact of those decisions, and let you run technical experiments and validate the product’s direction with a lot more speed and confidence.
5. Micromanagement
Last but not least: don’t micromanage your team. Train people you trust to execute what needs to be done. Share knowledge and give everyone the tools and the ability to act on their own.
A leader who acts as a shield for the team, absorbing outside interference and noise, is worth a lot more than a leader who questions and needs to be part of every single decision, no matter what it is.