Life in a Software World

Various tech-industry “visionaries” have proclaimed that we are entering an “age of software”, pointing to the importance of software to today’s solutions and the world economy.  By and large, I agree that “all things software” is more and more a differentiator among companies, a focus of work, and a prevalent element of life outside of work.  However, it seems to me that no one has fully defined just what life in a “software world” will mean – what it has meant for those who participated in its formative stages.

Below, I lay out five things that I believe are worth considering as unique characteristics of enterprises in a “software world”.  They are my own point of view, based on 12 years in firms as a software developer informed by the business theory I learned at Sloan, plus 22 years as a computer industry analyst.  Everyone will have his or her own list; I’d just like these potential aspects of the “software world” to be considered along with the rest of those lists.

Project Management, Not Manufacturing

In a typical manufacturing firm, the norm was and is production of pieces of hardware.  In a so-called “services” firm, the norm is delivery of pre-designed service “solutions”, and therefore there is a reasonable analogy to manufacturing.  In a software firm, the cost of actually creating copies of a software program is pretty close to zero.  Instead, the focus is on creation of the next version or fixing bugs in this version.  In the manufacturing/service firm, the focus is often on optimizing the process of producing the same thing over and over.  In the software firm, the focus is on developing new features so customers don’t walk away.  And so, these firms seek to optimize new-product development – that’s the critical success factor for a software firm.  Does anyone suppose that if Google had simply cut the costs of servicing its search engine to the bone as its main focus, it would have survived, much less thrived?

But if ongoing success is a matter of new-product development, then it follows that success comes from successful development-project management, not optimization of the supply chain.  Apple grows profits and revenues while most if not all hardware/service companies achieve only flat revenues and lesser profit growth, and clearly the iPhone and iPad rather than Mac production optimization explain this. 

In fact, I believe that this changeover is also happening in so-called manufacturing and service companies.  50 years ago, it was still possible to say that the bulk of workers in a company were production workers, with support staff a poor second.  Today, pick any company and you have far more people in clerical and new-product development plus management roles, and those “clerical” and “managerial” tasks like administrative assistant, web designer, and product marketer are to a much greater degree about producing new solutions.  And so, the management of innovation projects is becoming much more important in traditional firms.

Accounting:  No Inventory, No Capital Stock

All right, that’s a bit of an overstatement, but not much.  Software requires very little if any hardware to produce these days:  just download it from a web site a small chunk of whose servers you have leased from a public cloud.  That cost is there no matter how many copies are downloaded of the single stored copy there.  What widgets of inventory?  What capital stock of hardware-producing machines and factory buildings? What FIFO vs. LIFO?

It seems to me that this software world therefore puts our favorite financial metrics out of whack.  Is inventory turnover really telling us that the firm is about to fail?  How about sales turnover?  If we are investing more in capital than in labor, aren’t we optimizing a non-existent manufacturing process rather than new-product development?  So are our metrics telling us, not that a firm is succeeding wildly, but that it is headed for failure?  And how do we tell what a successful new-product investment strategy is from our books?  For the last 20 years, since the Harvard Business Review suggested computer companies’ futures were in services rather than hardware, IBM has been focusing on both innovation and services rather than hardware, with strong metrics and some profit growth – but, especially lately, revenues have been flat overall, with only software showing strong growth over the entire period, and services effectively beginning to prosper only when IBM delivers innovative software. 

I confess that I have no strong sense for what the new accounting and the new financial metrics should be.  There needs to be some way to measure new-product development success and detect failure, and isolate it in the company’s books – but my textbooks tell me that projecting the revenues from software development is highly speculative.  Maybe so; or maybe Microsoft does have at least some handle on how many copies a new version of Windows will sell, so it’s not as bad as all that.

It’s About Growth, Not Optimization

One of the biggest shocks in the two software companies I worked in for 4+ years was the way that expectations escalated.  Every year was the baseline for the next year, no matter how good, and I was expected to do more in some way:  produce more code, do more tasks, whatever.  In fact, after the first two companies I started to assume a general curve, in which the 3^rd year was necessarily disappointing to my bosses – who, by the way, were never the same at the end of the year as they were at the beginning – and sometimes I wondered if the fourth simply laid the grounds for the end of my employment.  It wasn’t that I wasn’t producing; it was that I wasn’t producing that much more. And, in point of fact, until a change of strategy my fourth year there, it looked as if Aberdeen Group was going the same way.

Recently, I met a car salesman who, as in many traditional jobs, had been there for many years.  It was clear that he was not constantly faced with rising expectations; the fact that he continued to excel compared to others was reason enough to keep him.  Clearly, an auto dealer is not yet a software company. Why the difference, I keep asking myself? 

I would suggest that in a software world, optimization of the machines that support a process simply does not speed up software development significantly – and yet, managers want to grow both revenue and profits.  The obvious answer:  everyone must do more. No matter that it does not fit the mold of unpredictable new-software development, or that it is a one-size-fits-all approach to labor; it must focus on growth of production rather than accepting optimized production, in order to conform to the expectations of the firm.

I don’t say this is good or bad, although I have my opinions.  It does suggest to me, however, some reasons why agile software development seems so inefficient and yet produces such great bottom-line results.  That is, agile development removes the ability to demand more from each person – it changes the metric from lines of code per day or some such to customer satisfaction.  And so, the company can have its bottom-line growth without efficient, ineffective programmer optimization. Because today, more and more companies, like software companies, are thinking dynamic, not static:  seeking growth in unpredictable markets with changing consumers, not seeking to optimize the supply chain or manufacturing process in more stable markets.

It’s About the New New Thing, Not the Success

In some ways, this is a repetition of my first assertion.  In a software world, especially a “virtual” one, lack of hardware means relative lack of chains to keep the customer attached – or to make the customer feel trapped.  It amuses me to see the venom attached to Microsoft Office as a boat anchor for innovation, when in point of fact it is far more innovative than, say, the gas station or the fashion industry.  And that’s the point:  software firms have a significant amount of new content in each version of each product, because they have to.  They don’t focus on success by standing still or recycling:  they focus on adding features.

I see this as a real problem for our present foundations of microeconomics.  I believe that Paul Krugman wrote recently that static manufacturing firms producing widgets in microeconomics indeed did badly as a model of real firms and markets, but that was OK, because it captured the essentials needed for effective macroeconomics. I question whether that is still true in a software world.

Specifically, it is a recipe for underperformance of macro-economies. For example, over-investment in capital that represents the capital stock necessary for optimizing a manufacturing process and under-investment in labor that represents new-product development may show decreased costs, but it also does less well at meeting consumer needs, and hence static IS-LM curves are achieving less sales at a price than they could – the economy is under-performing not just relative to “potential GDP”, but also “potential GDP” at full customer satisfaction.  Or so I wonder.  This wasn’t a clear problem when we had no alternatives; but now we have a software world.

Flexibilists Rule

This is perhaps the most speculative of my suggestions – and I realize that’s saying a lot.  There’s been a lot of attention paid to Brynjolffsohn’s assertion that increased automation via computing has meant the loss of jobs, even including knowledge workers, and it’s not clear if and when that will reverse.  I would suggest that while that may very well be true of manufacturing and service/support jobs, it should not be true of new-product development jobs in a software world, and, in the best software firms, like Google, it isn’t true. 

For one thing, software automation is very far from replacing programmers.  This is something I’ve been arguing for thirty years:  programming is partly creation of new mathematics, and that’s something that we are not near automating (and yes, that’s very distinct from the “I get human semantics” analytics of Watson).  For another thing, programming in a software world is usually about development of new features, i.e., new-product development, and it makes sense to invest there rather than in non-existent inventory management.

I say, it should be true, but I recognize that in many firms, even software ones, programmers are thought of as disposable and capital investment as to be preferred – e.g., the offshoring of development that is still ongoing, even in areas where the supposed lowered wages are pretty much vanished.  That is partly because, I think, these firms tend to think of programmers, and marketers, and so on as narrow specialists, so that as technology and so on changes, it becomes necessary to hire someone who knows the latest language.  That is completely untrue of most of the programmers I know; in an environment free of threat to their jobs and with a little time to burn, they are the most avid consumers of new programming technologies, and a wide variety of other things.  They are flexibilists, not specialists.

The same, it seems to me, can be said of the agile marketing movement, which is – surprise, surprise – strongly associated with the software industry and software-heavy firms.  Agile marketing is more and more about flexible creation and delivery of new product – in fact, a continuous feedback loop of such creation.  And testimonials from practitioners echo those from agile programming shops:  it does better, and people stay around longer.  In a software world, or at least in a better one than we have today, flexibilists rule.

Conclusion

Them’s my preliminary thoughts.  Reactions?