A few years ago, I felt I had enough experience - and had put enough thought into the subject - to write a book on governance in software development. I've run a few tech companies and consulted to tech firms and captive IT, both large and small.  I'd observed that most tech firms and captive IT organizations are largely left to self-govern, and both are pretty light touch about it. I'd also observed that governance is widely misunderstood and the term is used in technology in a lot of different ways, almost universally incorrectly. With more ambitious investments being made in software and the success rate of large projects not getting all that much better, the need for better governance was there. Plus, it seemed to me that if IT didn't get its act together soon enough, the CFOs of the world were going to get IT's act together for it, so it also made sense to write it from a bit more of a financial rather than an operations perspective.

The timing seemed right, because the prior decade had given us some very high profile and well documented examples of egregiously bad corporate governance, ranging from isolated cases of accounting fraud (Worldcom and Parmalat) to the near-collapse of the banking industry that resulted from so many firms taking too much risk onto their balance sheets, their boards having absolutely no idea they had done so (Citibank). At the same time, there was some nascent research suggesting that good governance has a measurably positive impact on business outcomes, and also that "activist investors" - people who force their way onto the board of a company to agitate for change - were by and large net positive to a business. All together, we had great examples of how not to govern as well as behaviors we could use as a standard to define what governance really means - practiced or otherwise - in software development.

Within a couple of years, I had written enough material to compose a draft. Then I took a hiatus from it.

In the years since I wrote the first draft, a tension has developed between advocates of "innovation" and champions of "scale" in software development. In one corner are the enterprise development people who say control over operations yields predictable results. In the other are the lean startup people who say that discipline in execution twined with feedback loops is control enough, so just let people go on voyages of discovery and you'll have far better business results. The control camp claims that innovation is possible in their way because it embraces Agile (evidently, all you need are "innovation sprints"). The lean camp claims they can scale to the size of a large business (which may be true, but they're light on practical details). Both say they can revolutionize business itself, but both require the buyer to take a position that is long hope, short practical details.

Plus, both camps take an execution (that is, operations) perspective. Execution is important, but if we're going to make organizational impact, we have to do it from a financial, not an operational, perspective. Operations are cost. Investments are value. To change the business of software, we have to speak the language and act the part of the latter. It doesn't matter how revolutionary or how beneficial a different way of delivering software can be to a company: nothing that comes out of either camp is going to cause the authors of Fundamental Accounting Principles to overhaul their text.

The confusion this creates in the investment landscape makes the subject timely once again, and so I have revived the book. I hope you find Activist Investing in Strategic Software thought provoking and destabilizing, quotable and irritable, but above all accessible and shareable with colleagues and peers.