4 Steps to Reduce Software Delivery Time
A common problem in the tech industry is how to deliver working software, fast. You may feel tempted to take shortcuts, but everytime you do, the system incurs tech debt.
To illustrate this concept, I find it helpful to think of electrical wiring.
Basically, the insides of a poor-quality software product look something like this:
(That’s why it’s also known as “spaghetti code”)
This mess usually happens:
- when people are short-sighted; they sacrifice future maintainability for immediate gain
- when people don’t care; “nobody is looking under the hood”
- and this can happen even if teams have the best intentions, but not all members are on the same page on quality standards, or are unable to push back to stakeholder pressure
Even though code is only seen by programmers (usually), signs of poor quality code are:
- Increasingly long delivery times (imagine trying to find and fix a faulty wire in this clutter)
- Bugs arise frequently (since people cannot understand the system, it breaks unexpectedly when it changes)
Good software takes time and consideration. One example is thinking how the system might change in the future, and structuring your work today in a way that supports growth.
I’m no expert at electrical wiring, but the image below definitely captures the intention behind high-quality software work:
Now imagine being tasked with making a change to this system.
At first glance there’s labels to help you identify where to start & how the wires are organized. It’s easy to see where each wire is coming from and where it goes. Once this pattern is implemented, future maintainers can preserve it.
This system is a clear example that supports future maintainability.
Setting up these useful patterns requires a combination of effort, experience, and vision. It’s best to do this key work early, and constantly, as the system evolves (new patterns emerge).
If you want to reduce software delivery time, sacrificing quality is not an option. Instead consider these four steps:
1. Cut scope
The simplest option to consider is removing features, or delivering a “watered-down” version of the feature.
2. Avoid time/effort wasters
Re-evaluate the effectiveness of your current effort. What do you expect to get out of the practices you follow? How could you tell if you’re not getting it? Challenge your assumptions & keep doing only whatever adds value.
3. Temporarily re-allocate staff
Before increasing the size of your team, you could enlist help from other parts of your organization which are not resource constrained.
4. Hire more staff
The options 1-3 above should be tried first because they use your existing resources, but lastly: add more staff.
But be careful, IBM’s Fred Brooks made a popular observation in his book, The Mythical Man-Month:
Adding manpower to a late software project makes it later
There’s more context behind that phrase but the consensus is it generally holds. This was published in 1975, and those who listened have learned (history helps us not repeat mistakes after all; bit of a cliche, but true). I’d revise this quote as:
Adding novice manpower to a late software project makes it later.
If you add new people, and have to hold their hand constantly, then yes, that’s one instance where his observation is logically true.
On the other hand, a team of disciplined professionals can definitely help course-correct projects that are running late.
Here are a few examples of how Dynamic.Tech has helped businesses facing this dilemma:
- We’ll work with your team, side-by-side, to reduce software delivery time.
- Our 15+ years of quality experience help identify & ditch non-essential work.
- We offer training to detect & prevent issues that stem from poor practices.
If your system looks like the mess of wires above, we can help.
