Engineering Productivity; Problem-Driven Development; Feature Price; Cost of Abstractions
Issue #34 Bytes
š± Dive into Learning-Rich Sundays with groCTO ā¤µļø
šļøEngineering Productivity From a VPEās Lens| Maher Hanafi From VP of Engineering at Betterworks
Check out Ep58 of the groCTO Podcast, where Maher Hanafi, VP of Engineering at Betterworks, shares how he combines shared understanding, trust, and competence to empower his dev teamsā productivity. By fostering flexibility, ensuring alignment, and focusing on outcomes, Maherās approach enables teams to take ownership and deliver exceptional results.
Here is a quick teaser of the podcastš
How do you approach engineering productivity? Share your thoughts in the comments! š¬
Article of the Week ā
Expose and educate [your team] on the problems youāre having. [ā¦] If you only ever show people tickets, donāt cry when you have a team full of ticket-takers.
Problem Driven Development
Letās begin with Problem Driven Development, a sassy critique on technical decision-making and technical debt in teams you know and love.
Imagine you're a Senior Engineer or Engineering Manager, staring at a blank whiteboard. Craft the next big technical roadmap. The room is silent, the pressure is on, and suddenly, every idea seems either too vague or overly ambitious. Sound familiar?
Enter Problem Driven Development (PDD): a straightforward approach that shifts the focus from chasing shiny new solutions to tackling real, existing problems. Teams love to trip over their own feet by focusing on synthetic problems like fake deadlines, fake urgency and features nobody needs. Often, teams brainstorm by asking, "What should we do next?" This open-ended question can lead to a scattergun of suggestions, leaning in towards the loudest, most opinionated person:
"Let's upgrade to the latest library version!"
"How about refactoring the Foo class for better composability?"
"We should try out that new SaaS tool everyone's talking about."
ā¦ donāt even get me started on AI!
Common Ground
What these pitfalls have in common is the lack of āconcreteness". No connection to reality, data or direct, real customer feedback. This is called validating for value in typical lean/agile lingo. While these ideas might have merit, they often lack a direct connection to pressing issues. Therefore, you have to anchor them.
And what better anchoring point than problems and constraints:
Time wasted on activities
Uptime SLAās
Performance SLOās
Operational Cost
Failures, opportunity cost, penalties
Grounding in the problem areas defines the area where tasks and solutions āliveā.
Prioritisation
Once the area of the problem is mapped out, the process is understood, a plan can be shaped. With that plan, finally, the opportunity arises to make the decision of whether to actually act on the issue or if something else is more pressing. Remember, a task has to be real, actionable and solved at just the right time, ie. nothing else is more urgent.
Other highlights š
How to Calculate the Price of a Feature
Features Have Price Tags
Building a feature isn't just about time or lines of code; it's about understanding its real cost to your company. Mike Veerman emphasizes calculating a feature's cost by factoring in people's time and opportunity costs. It takes time and resources to build your chosen features, at the cost of not building something else (right now).
But software projects have an additional component: change. A change in requirements, a change in needs, a change in assumptions or a change in the makeup of the team, like onboarding and unplanned work.
Iterative Buffer Planning
Normally, managers blend together the day rates, squint and add 20%. Change requests, budgets, support tickets and tech debt are often compartmentalised this way in smaller, less experienced teams. Mike is well-known for his Iterative Buffer Planning (IBP) approach as a replacement for this conundrum.
Pricing is an area where the formal āAgileā schools have dropped the ball, proxying value and cost instead with pizzas, tshirts and story points.
IBP breaks down pricing to the following steps:
Plan an accurate focus block, where a team can focus on one thing
Plan (not estimate) how many focus blocks you want to invest
Take the salaries of the team and blend them together to carry the focus time
Add the recovery time (in days, weeks of the teamās attention)
The recovery time handles potential urgencies that got neglected as the (willing) opportunity cost of the team focusing on one thing. Normally stakeholders want to keep focus blocks short, at the risk of having to re-visit or wanting to revisit at a future date once ROI and/or value has been demonstrated and proven.
What Are the Hidden Costs of Over-Abstracting Your Codebase?
Abstractions are like creating a reusable recipe; they simplify development by allowing you to apply the same solution across various scenarios. However, as Maxime discusses in his article, over-abstraction can introduce hidden costs that outweigh its benefits.
How can you know what future needs you will have? Are your assumptions correct? This is called speculative generality.
The āHidden Layerā of Abstractions
Every engineer has at some point been burned by over-engineering a solution, providing way too much inheritance or decomposition only to be bitten by the maintenance burden it provides.
The costs are hidden. They come later when the software needs to be changed, often out of reach from the original author or unable to influence going back and fixing it. This is generally a cultural issue hiding other deficiencies in operations and process.
The hidden ābetsā to look out for and avoid according to Maxim are: universal, generic tools, over-use of patterns, too much flexibility in components that never change, assumption about future needs (and neglecting current ones!)
How to Avoid Over-Abstraction
Start with specific solutions. Be concrete solving the problem at hand. Are generic sub-platform part of what defines your business? If not, skip the unnecessary layers.
Think about maintenance. Will the abstraction make sense for the next change? What about in six months?
Embrace the rule of three. Defer a new layer of abstraction until the third copy of a problem being solved.
Review your abstractions regularly. Non-essential abstractions are a net liability, similar to technical debt. Review them regularly, especially in hot spots in your codebase where frequency of change is high.
Find Yourself š»
Thatās it for Today!
Whether youāre innovating on new projects, staying ahead of tech trends, or taking a strategic pause to recharge, may your day be as impactful and inspiring as your leadership.
See you next week(end), Ciao š
Credits š
Curators - Diligently curated by our community members Denis & Kovid
Featured Authors - Stay Saasy,
, Maxime MorinSponsors - This newsletter is sponsored by Typo AI - Ship reliable software faster.
1) SubscribeĀ ā If you arenāt already, consider becoming a groCTO subscriber.
2) Share ā Spread the word amongst fellow Engineering Leaders and CTOs! Your referral empowers & builds our groCTO community.