Corporate Software Estimates
Hey!
Welcome back to another week of musings.
I hope you had a peaceful weekend and were able to relax. This week, we might see the "SF Henge." With the changing weather, we never know.
Was this forwarded to you? You can subscribe here!
Things I discovered in the past week
- I listened to this interview with the creator of Wiremock, which is an interesting look at the history of such a tool.
- Betteridge's Law of Software Engineering Specialness is a short thought on why software engineering problems tend not to be unique, or we think they're because we don't know how other professions deal with issues.
I recently read reactions to Apple Intelligence's delay, which made me think software is always late in a corporate environment.
The practical reality is that in a corporate setting, a large project involves significant coordination. Any ticket created that is one sprint behind schedule might get you a next-year type of delivery. In any case, I feel empathy for the project or program managers dealing with this Apple Intelligence project.
Variation in Software Delivery
If you're into systems thinking, you might have encountered W. Edwards Deming, who discusses understanding variation as one component of understanding the world.
Variation in software is expected, as that's what developers are trying to introduce. We're always looking to acquire more customers, improve customer issues, reduce load on a given application, etc. On the flip side of that variation, there's the variation in code and logic cases, the increasing complexity of onboarding for new hires, etc.
So, as we make our software better for customers, we are making it harder for us to work on it!
Asks for estimates will continue until morale improves
As we make it harder for us to work on our successful software, it also makes it hard to estimate when a new feature will be delivered. "It will be done when it will be done" will only get you into daily update meetings.
You'll step into a negative feedback loop that will create bad results for your team!
Is there hope?
There is hope, as the industry and other industries have dealt with these issues for a long time. What sometimes stops teams is that it is hard to say no to new features to tackle sustaining or improving engineering efforts. You need buy-in from multiple stakeholders, which might seem more complex than "working harder".
What are some alternatives?
Reduce WIP
The first thing that might make managing complexity difficult is the work-in-progress (WIP) that your team is working on.
If you imagine that building your git branch for a new feature takes two hours, you might be tempted to start work on something else while it's building. We're concurrently working on new features! We've all dealt with the pain of context switching and how it makes it hard to return to the first thing we were working on.
While it looks like a hit on productivity, reducing the mental load on people will help in the long run.
Quality Controls
Look into the current quality controls for your software and introduce or increase existing ones.
You may be missing automated regression testing, continuous integration, or delivery. The longer you take to deliver software, the riskier that release will be.
Some teams are hesitant to start this because their code bases are so old that they think they cannot cover all cases in tests. In practice, testing new features, as progress over perfection, will give you better quality, and some tests are better than no tests.
Reduce code complexity
This sounds obvious at face value, but multiple avenues exist to reduce code complexity.
We could split out a part of the system into another system. We can refactor small pieces of the existing code base while adding automated tests. We can remove unused code.
These can be small enough to start and kept small to iterate regularly.
Rewrite from scratch?
Let me stop you right here: never rewrite software from scratch.
Your turn!
How do you deal with predictability in your estimates? Is your company strict about timelines? Are you working on legacy code that makes it hard to estimate deliveries? Let me know your thoughts by replying to this email!
Happy coding!
website | twitter | github | linkedin | mastodon | among others