The Cost Center Trap
leanessays.com
leanessays.com
The ironic thing is that this "cost-center culture" has even affected the mindset of individual software developers and how we think of our own work.
Most developers ONLY look at their work in terms of cost. ALL pros and cons arguments are really about ways to reduce cost. Consider the term "tech debt" -- nothing could be clearer. Yet discussions rarely ever take place among engineers at a company about how to maximize profit or increase revenue. In fact, I would argue there is a heavy cultural bias on most engineering AGAINST optimizing for revenue, as it is seen as something that motivates sales or product people to rush timelines and sabotage sound engineering practices.
The obsession with cost is baked into programmer culture in such a deep and foundational way, I'm skeptical will ever change, even if the accounting of software projects changes. If you perform a search for the word "cost" on the eBook for the Principles of Object-Oriented Design in Ruby by Sandi Metz, you will find it dozens of times in various sentences about the urgency and critical importance of reducing costs, but the words "profit," "income," or "revenue" appear not even once. I'm not trying to make a point about POODR in particular, because this bias is only reflective of the culture as a whole.
You can certainly make the argument that it has to be that way, and engineering should be separated from revenue. I find it very interesting that, as a culture, we are only willing to speak about the monetary value of our work in negative terms.
Talk to any electrical, mechanical, or civil engineer and they will be focusing on getting this on time and under budget, not trying to increase "income" or "revenue".
One of Boehm's "fundamental problems of software" is that it's so easy to change, that it's easy to assume that you can always change it later at no cost. This is really why the problem is far greater in software.
Something I've realized, tho it's, as you write, seemingly against my nature as an engineer, is that there are lots of situations where it's reasonable to 'assume' technical debt to reach a more important goal.
We absolutely should continue discussing technical debt, but also in the context of 'technical revenue' and 'technical profit'.
Interestingly, 'technical debt' works amazingly well as a concept. I suspect it's not even really a metaphor. Consider that probably the most important pragmatic consideration about whether you should assume a debt (of any form) is whether you can expect to make all of the 'scheduled payments' that it requires. And even if you can, will you still have sufficient slack to be able to pay-off or pay-down other currently un-expected debts or expenses that you might incur between now and whenever it is you finally pay off all of the original debt?
What unfortunately happens a lot is orgs taking on tech debt without realizing it (devs are too junior, or management doesn't listen to devs, or various other reasons). Then 1-2 years later, the system is falling apart and the old engineers are gone. The new ones just call it tech debt as this kind of unavoidable force of nature that was dropped on them (because it kind of was).
Or worse, the devs of old ARE still there, but pretend that after 1-2 years, its inevitable for a system to be falling apart and needing to be rewritten from scratch.
This level of industry immaturity prevents the tech debt concept from fully working.
In organization where tech debt IS a fully thought out and planned out compromise to get value today at some cost to be paid off later, then yeah, it not only works: it's often the right thing to do.
Messy code is painful so the answer is sought, when we don't have much experience, in what we learned in classes and books: elegant abstractions. But we end up abstracting business logic in such a way that when the business needs to change, our code can't change with it, and that's when we have true tech debt of the "let's rewrite the world!" sort. It might be beautifully designed abstraction, but if it's tied to the features of yesterday too much, it's going to become increasingly brittle and painful.
Now when someone says "we can ship this sooner but it'll be hacky and introduce tech debt to make the code re-usable" I'm much happier, and would rather have the code not be intended to be re-used until we prove that we understand how we'll want to use it next time.
The output of the effort put into technology is a new process or workflow, rather than raw "tech stuff". It's a multiplier to a different input, some other task or application, and so the creators of the technology are frequently disconnected from feedback about its actual use.
For tech to be useful it has to succeed at creating enough leverage that you would use it over what was there previously, and plenty of technical projects get stuck on that point: they show an immense engineering effort but are solving the wrong problem because they don't optimize the desired workflow, or they expect everything to change around the product's workflow.
In that light, in a universe where most of these designs are bad and misguided and deserve to be put out to pasture, the cost-center mentality makes total sense because it asks the design to prove itself as early as possible. And the outcome of that in turn is the familiar rushed, unmaintainable prototype-in-production scenario.
New technology efforts always have this element of being a judo match: if you can find just the right time and place to strike and take the problem off-balance you can get an instant win, but the same strategy at a different moment doesn't work at all, no matter how hard you flex your coding muscles, and would leave you better off not attempting any new tech.
The balance-sheet model doesn't explain when and where to strike, though. It just says whether or not you're trying to do so this quarter, and any benefit will most likely show up on a different business unit's balance sheet.
Ostensibly, every net-new feature increases the pool of people for whom the software, as a whole, solves a problem. The performance and usability of that feature further adds to that.* I'd argue that is technical profit, and is realized into real profit when it converts to purchases/subscriptions/whatnot.
[1] For the sake of argument I'm assuming a scenario where the feature and its performance/usability is positively received.
When Paul Graham talks about how writing Lisp enabled his startup implement features quicker than the competition, that's technical profit. Google's internal systems that allow them to maintain thousands of machines; create large, distributed filesystems; and who know what else are technical profit.
There was an article recently about Boeing retiring the 747, and it commented how pilots would take a picture of the plane after flying it. (Passengers, too) In aerodynamics form is function, and I suspect that the outward beauty reflected excellence of design. The design served them so well they just now retired it after 40 years, despite all the advances since it was originally designed. If I'm right, this is technical profit.
Perhaps the idea of technical profit would be an easier sell to management, especially as management types see debt as useful, but programmers see it as a liability.
Technical profit is a feature or capability really that's possible because of some technical thing (e.g. code). But the 'revenue' of the capability has to exceed the cost of designing, developing – and maintaining – the tech for a profit to be realized.
http://www.ontechnicaldebt.com/blog/bad-code-isnt-technical-...
When a bosses bonus is tied to quarterly results then quality goes out the window every time immediate revenue or cost cutting comes up
Debt is a liability that you typically need to make payments against; preferably at predictable intervals and of predictable amounts.
Every known (and significant) bug, that isn't fixed, is tech debt. Presumably something has to be done about the effects of the bug and that something has a cost. Fixing the bug then is paying down the associated debt.
I don't dare speak of this in engineering circles, though. I'd be chased out of the office with pitchforks...
What's the taboo implication that you expect the people in your engineering circles to fear or otherwise react negatively?
The idea of paying down tech debt sooner than later?
That may be because those mechanisms are usually much more situation- and industry-specific, it's the X that software lets you do.
Conversely, software costs are the part that is more generalizable in a book about software.
At the CEO level, the money-making potential of software is clearly understood, so why, at the ground level, is it the exact opposite? Every programmer is paranoid about the costs they're introducing to an organization while totally ignoring the financial upsides. Every discussion is "cost now vs. cost later."
If our only goal at work is to minimize the cost to our companies, then our managers can do that better than us: he can just fire us and cancel the project. There, cost is now zero.
This book "The Goal" was incredibly beneficial for me in understanding the concept of throughput. While the book is a parable focused on manufacturing, it can be easily applied to companies in tech. https://www.amazon.com/Goal-Process-Ongoing-Improvement/dp/0...
https://www.amazon.com/Phoenix-Project-DevOps-Helping-Busine...
And like this throughput accounting thing, his ideas can be quite heretic in some circles.
This shows a poor understanding of managerial accounting.
High "working capital" requirements, of which inventory is a big part, are a huge drain on free cash flow. Any company that sees its inventory as a % of assets go DOWN would view it as a positive by both its management and investors.
Of course now management theory knows of many reasons the above is wrong, it is entirely accepted that you want inventories low because of the advantages it brings.
Advantages ... until you have an earthquake in Taiwan and the entire semiconductor industry shuts down because nobody has any inventory ...
It's a double whammy, you pay (in terms of utilities, rent etc) to hold stock that means you can't use the money elsewhere and for a lot of stock you also have depreciation (though I work for a company that makes stone products so at least our raw materials don't expire).
My own arms-length exposure at that time suggests that, however simplistic it might seem, the assessment in the article is correct. It might seem obvious that lowering inventory as a percentage of assets is good, but only if you look at that, rather than just seeing the top-line assets total go down.
This article seems to very accurately represent my experience.
Maybe what would help is if you could explain what metric a reasonable manager would measure that would get worse under JIT versus better.
I guess maybe if your assets go down you could look more highly levered, but financial leverage isn't really something that a manager can affect anyway (more of a CFO level metric).
All of the asset-oriented measures I can think of -- like asset turnover, working capital as % of sales, working capital as % of assets, WIP inventory as a % of total inventory, etc. -- would all improve.
Look in the mirror before throwing stones at others' knowledge.
Only a deranged accountant thinks the cost center is the scarce talent that delivers outsize customer value, and that the profit center is the back-office filled with billers who "monetize" a relationship that wouldn't otherwise exist.
In tech, this flipped around in 2004-2008, I think. From 2001-2004, people thought IT was "over". Now, they realize software is "eating the world".
I am hopeful a similar realization will eventually come to medicine. Doctors deserve Google-style work perks and competition for their scarce talent. Insurance, back-office, and billing deserve to be turned into the AWS of medicine -- outsourced commodity.
AWS and the Google Cloud are evidence of the possibility of escape. Are there any writeups for how they came about? (Particularly in the case of AWS.)
https://news.ycombinator.com/item?id=12022915
Yegge's famous rant about Bezo's 2002 mandate https://plus.google.com/+RipRowan/posts/eVeouesvaVX
You will find an in house equivalent of the cloud in every single big company. Except, the software and the UI will be terrible because they have much less resources and competence than Amazon/Google.
Like anything else in business this seems like a case where some hard, one size fits all rule is occasionally misapplied.
It's really just a matter of how easily can you see that A led to B.
Release of what?
For banks, it's the same thing. It can be external: my bank added a feature that let me enter and see projected expenditures and incomes so I can see my future balance, it's an effective aid to my budgeting. It can be internal: Like a POS system, making it easier or harder for tellers or lenging agents or others to do their job. Giving them more accurate and up to date information with reports generated daily or down to the minute, instead of the historic weekly or monthly batch reporting.
Car manufacturers have control systems developed by IT, same results as above on a new release.
Customer support is certainly treated as a cost center, but it oughtn't be. Mary Poppendieck (author of this article) has a good example in one of her books where the customer support center improved profits by being able to aggregate and identify the majority of customer complaints. This led directly to improvements in infrastructure and delivered systems that reduced overall corporate costs (less rework, customers were happier, more sales).
[0] http://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pro...
Some IT expenses are indeed cost centres and should be just deducted from the profits immediately.
However, other "IT expenses", like creating "back office cost reduction software" and generally IT infrastructure are no different than acquiring some fancy machinery that enhances an industrial process. This also applies to companies whose main revenue model is building software and cloud services.
Everybody has a disagreement with metrics until it suits them. Metrics justify mid-level management to upper management, which then justify themselves to top management, then the board of directors, then the shareholders. “Look at the numbers!”
It’s similar to a grumbling slogan of fund managers in the 1980s about the then-consistently poor stock performance of IBM: “Nobody gets fired for buying Big Blue.”
See what companies outsource, that's what they see as cost centers.