Budget as a requirement for feature development

What is the most annoying thing you encounter as a professional software engineer? Back in the days when I was actively writing code, it was often missing the right context. Work would come in as a stream of tickets, often hastily written, each representing small pieces of work that would seem unconnected. That would usually lead to wrong assumptions, miscommunication and the one thing that all software engineers hate: wasted work.

When I started to work more on the production management side of things, I strived to make sure that when I’d create tickets or feature specs, I’d go out of my way to include as much context as possible: links to background discussions on Slack, any related documents or tickets, and at least some basic description about how this work relates to the bigger picture and why it’s important. I might have gone too far on some occasions, but this is one of those cases where I believe more is usually better.

As software engineers, we are used to designing and tweaking our code so that it satisfies a given set of constraints — size, memory, CPU time, response time, you name it. Give a performance target to two software engineers with good profiler tools and you’ll see more competitiveness than in a road cycling race. When these constraints are defined in concrete terms, it brings a sense of clarity — and a sense of great accomplishment when the numbers are met or surpassed. So these constraints should be included in the context of feature specs as well.

However, the more I worked with defining the context for each feature, bug fix or some larger project, the more I came to a conclusion that the ultimate constraint for any piece of software — or for any other work for that matter — is for it to make sense from a business perspective. If you already know (or can guesstimate) how much sales you expect a feature to bring in, the constraint you have to define is the development budget (see how Basecamp’s Shape Up method places great emphasis on “the appetite” — a strict development budget for each project).

A development budget for a feature is a constraint — just like the constraint that an app must run on iOS versions starting from iOS 10. If half of your end-users still haven’t upgraded to iOS 13, maybe you should reconsider that iOS 13 only SwiftUI idea, even if you are very excited about the concept. If you are going to sell your customer that feature for €10k, you’d want to make sure that your implementation plan will leave something under the bottom line. And if things start to look bad, cut your losses early, as in Shape Up. The budget becomes the driving requirement for a feature. It covers time (how many work days can you afford?), any direct infrastructure costs and allocated overhead.

But one cannot understand development budgets — much less describe them to someone else — without understanding the business to which all this work is meant to add value to. What would be a better place to start figuring out the business than by diving into financial statements? To help myself understand a bit more about what I was looking at, I decided to take the “Introduction to Accounting” class in Open University (organized by the University of Eastern Finland) to learn about basic bookkeeping, taxes, payroll, inventories, depreciation, accrued liabilities, income statements, balance sheets, and some basic cost accounting and budgeting. I found the course to be pretty exciting (even though combining Uni studies with a full-time job and competitive triathlon hobby did require some serious calendar Tetris for a few months). My long-term goal is to combine the ideas of Open-Book Management (well-forgotten topic from the early ’90s) with managing development in a software product company of today.

What I realized is that it’s the responsibility of the person who defines projects or features to also define the allowed budget and include it with the context, alongside other constraints like OS versions, performance requirements, etc. Sometimes a constraint is unrealistic — you won’t parse 5MB of JSON on an iPhone X in under a millisecond even if you try really hard, and you won’t implement a native layout engine with a long list of requirements for a news app on iOS and Android in a week. But it’s better to talk about unrealistic expectations up front — and to hopefully come up with alternative plans — than to start coding without the business context and start reacting only after your budget is already vastly overrun. Knowing the available budget up front can affect a lot of architectural decisions, just as knowing the supported operating system versions.

We as an industry talk a lot about autonomous teams and giving people more ownership over their work. At the same time, we are surprised when solutions of these autonomous teams are driven more by the technical novelty than by business reality. But can these results be any different if we consistently fail to communicate this business reality to autonomous teams?

Modern software companies should strive to be businesses of business people, not steel mills of Taylorism era.

How do you make sure that business expectations are communicated and understood within your team? Do you involve your technical people in discussions about sales and costs? Are your financial statements part of your daily and weekly discussions?