Software Capex
"Every block of stone has a statue inside it and it is the task of the sculptor to discover it." -- Michaelangelo
In this regard, building software is not unlike sculpting. Every solution has a problem and it's the engineer's job to discover it. Building software is a process of discovery. It's like groping blindfolded to learn to shape of the subject.
Even the best business or product partner will struggle to elucidate and codify all of the idiosyncrasies and edge cases of a problem. Where humans would generally chose to "cross that bridge when we come to it," the computer throws a temper tantrum and refuses to move on. Humans are flexible and adaptable. Computers are not. Ultimately, it's the engineer who's going to have to uncover and clarify the details with subject matter experts in order to satisfy our implacable adversary, the computer.
The Intial Outlay
This is precisely why estimating the cost of a software project is so difficult. There are known unknowns and unknown unknowns. You won't know what you don't know until you've discovered it. If that weren't difficult enough, requirements change. The problem being discovered may morph mid-discovery. Consequently, just determining the initial outlay of a project is arguably one of the most difficult tasks of software engineering.
If you must go with waterfall, the best way is to break the project down into small steps, estimate the steps, account for uncertainty, parallelize all tasks that you can, then aggregate. Remember to include testing and launch as depending on the project these can be quite complex. In fact, this process can be so difficult and opaque that entire methodologies have been created to try to replace it, culminating in Agile
Since the early 2000s when Agile came into fashion, we've generally seen growth in technology. Since then, whatever economic contractions have occurred may have temporarily slowed things, but overall the trend towards growth hasn't changed. Agile worked for Lean Startups in this growth environment. With cheap capital, Private Equity was willing to maintain conviction in a problem space and iteratively test hypotheses against their market. Silicon Valley monopolies with fat balance sheets also had little trouble maintaining conviction
With mass tech layoffs, bearish economic sentiment, and AI/No-code hype, what's happening in early 2023 reminds me a lot of the the dot.com bubble. Have we reached an inflection point in technology investment? If so, will companies be willing to exhibit the same conviction required to continue with Agile?
The IRS appears to be doubling down on treating software as "research," requiring that it be capitalized and amortized over 5y (Domestic) and 15y(International) from 2021. Previously, the requirements were more liberal, including the option to record software development costs as an expenses.
Maintenance Cost
Despite what the IRS says, software is a liability not an asset. The R&D only ever ends when you pull the plug. The decision to invest in it should be guided by the understanding that it involves an ongoing commitment of capital beyond the initial outlay. Consequently, post-launch maintenance should be budgeted for and included in initial project planning.
Successful software project returns should generally follow the business S-Curve. Returns grow over time and eventually wane. A profitable project should aim not only to maximize the profit margin at any moment but also the duration over which it can be held. Maintainable software has a lower running cost. To improve profitability, businesses should aim to make software maintainable as early as possible.
Start-up -> Growth -> Maturity -> Decline
MVP -> VP -> MP -> MLP
Minimum Viable Product Viable Product Mature Product Minimum Liable Product
Cheap interest rates gave us the MVP, Minimum Viable Product. An environment of technology investment contraction calls for the Minimum Liable Product. Businesses are interested in reducing costs. Focusing on "Keeping the Lights On" while reducing maintenance overhead is a low risk way to accomplish this.Controlling Costs
Software development is as much an art as a skill. Even if you limit a problem to a well defined quiz like a Leetcode exercise, you'll get ten different answers from ten different engineers. If we create a standard to code to, we can improve the quality and consistency of the delivered solution. One way to approach this is by framing development as an optimization problem. Our objective function is known, we must meet user requirements. Let's assume for simplicity, that this establishes our project's revenue, R. Now we need a cost function.
Project costs include the initial outlay, the cost to delivery features included in R. It also includes, platform running costs and general overhead. In recent years, cloud computing and the increasing maturity of platform and SRE practices have made great strides in measuring and controlling software running costs.
C = Cost = Initial Delivery Effort + Lifetime Maintenance
Maintenance = Platform Cost + Other Overhead
By grouping costs into overhead, we lose the ability to measure and thereby optimize. We should strive to tease this apart into it's granular constituents. Each project will have its own idiosyncrasies.
Pinpointing Overhead
In order to generalize, let's return to the S-Curve. Businesses at different
stages of maturity face different challenges and their approach to
software projects should reflect this.
Young Companies
Young firms are building out their product, trying to break into or establish a niche in a market. They need to deliver quickly. They'll likely be building a monolith, accepting some tech debt in the process.
The main driver of cost here is likely opportunity cost due to time to market.
Engineers would do best to focus on quick delivery with minimum complexity. Tech debt will have to be paid down at some point in the future. So called "Clean Code" is a good idea. It can help minimize the cost of future cleanups. It can also facilitate team communication, speeding delivery.
Growing Companies
More mature companies may face growing demand and alter their focus to scaling out their product and expanding their product line, all while addressing accumulated tech debt. Often at some stage an MVP, the product may be rebuilt entirely. There just won't be enough people to get everything done.
The main driver of cost here is likely manpower.
Getting the most out of engineering is key. Adoption of more mature processes can help deploy resources judiciously and efficiently. Offshoring certain projects or roles may be beneficial.
Mature Companies
Mature companies will be facing competitive pressure, squeezing their margins . Focus is on efficient processing of transactions at high volume.
The main drivers of cost here are production incidents and system downtime.
Stability and incident management are critical.
Comments
Post a Comment