What I Think About
Subscribe To The Salient Voice Journal

The U.S. Government is Developing A Useful Software Engineering Management Case Study

Obamacare’s tech rollout has crashed. As a software CEO with plenty of software background and absolutely no insight into the actual Obamacare project, I’m regardless noticing a couple quick lessons peeking out from the media noise. They largely point to some failures in project governance. So in that spirit, here’s a couple tests from which to assess the software projects that are presented to you. Actually these tests derive from very old lessons in building software systems … this is just a new chance to air them out.

1. Dates without technical analysis. It would appear that lawmakers set policy and software delivery dates without a functional scope or design of the software system. Further, over the first couple years of the software effort, lawmakers were still changing policy, the functional requirements, and other externalities regarding the system. You can’t set believable goals for engineering-dependent policies without a sufficiently precise analysis of the software engineering scope and effort. Obvious.  So management vision has once again has met engineering realities. And once again engineering realities have won. This mistake has been the end of more than a few MBA's and strategy consultants (and now lawyers). 


2. Change without costs. The project was in flux but the dates were not. Functional requirements can and do change. Software design is by its nature iterative learning and ongoing adaptation. This is unremarkable. But there are always costs to changes. These costs show up as (pick one or more): mid-project feature and software usability compromises (also known as unhappy software users), software performance and scalability problems from quick fixing internal design assumptions (no time to start over!), quality problems from increased fragmentation of software design and its testing (or from the minimization of testing to meet delivery deadlines) and productivity reductions caused by all this software refactoring and regression retesting. If your system requirements are “evolving” and costs and dates are not moving, you should worry because one, more, or all of the above are in your future.


3. Resources growth is not acceleration. Massive resources don’t necessarily yield proportional increases in software development outcomes. This Obamacare dev effort has been remarkably expensive and resource intensive. Here is something that has been long understood in software development. Fredrick Brooks defined it. He developed the idea of The Mythical Man Month (The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition). Metaphorically it states as untrue the following: if one woman can make a baby in 9 months, then nine women should be able to make a baby in one month. On a more practical level, the deployment of people on your software projects at some point will increase your coordination costs without accelerating the project (it can even slow it down). The trick is how to figure out that tipping point. There was an optimal resource model and deliverables time frame by which to build this health care software platform. I wonder what it was.


4. Complex dynamic systems and the number and diversity of stakeholders. It’s hard to model economic systems in software. These systems and their actors (users) continuously evolve and their actions vary widely.  But software cannot have infinite and changing design use cases. Even if your software could be all things to all people, this won't all be in Release 1.0. So you must constrain the software. It must do less. But alas, if you do less, the software will naturally constrain choices within the economic system and thus make it less dynamic, less innovative, and, as a consequence, less adopted - if not actually avoided and circumvented. You must whittle down the core stakeholders and use cases to the critical core for a first phase project. This health care systems project has done the opposite with all care to all people. It's a governmental version of the 1990’s mega-ERP software projects. This era saw massive corporate spending on meta enterprise resource planning systems and related process reengineering (along with lots of consultants of course!). Then one day it became apparent that a focus on integrations and middleware between disparate smaller best-of-breed systems was better than deployment and adaptation (constraint?) to large monolithic platforms ... and these systems started to become diluted. An interesting software design question: if you build software that constrains users, will they stay constrained? 


5. Staged Rollouts. They just threw the big red switch to "on" for zillions of people. Very brave. In the real world, you stage rollouts of software to mitigate risks. If your development team goes for an all or nothing deployment, it's important to remember that one bug delivered to 310 million peoples is, well, millions of customer support phone calls (and then lots and lots and lots of marketing to overcome the ill will). Your simple management rule is this: the cost of bugs grow exponentially after they get deployed to customers. Look carefully at the scope of your team's testing and the open bugs before software rollouts. And regardless, stage software rollouts to an initially small but expanding group of customers, while incrementally fixing and extending the software features.

6. Scalability and performance. It’s clear that server capacity planning and volume stress testing was insufficient for Obamacare (or alternatively and less generously the planning was sufficient, the problems were indicated, and it was rolled it out anyway). More generally, when a system cannot handle user transaction volume, there are several possible reasons; the first involves the technology and tool stack used to build the software, the second is the software and data base design itself, and the third is network and server environment. Working backwards, money solves network and server problem easily, then software re-engineering will slowly (but at some expense) improve performance (especially if structural software rewrites are required), and a bad software development tech stack decision is a disaster and points to a redo (bad choices include wrong programming languages, wrong data base technology, tool sets, etc).


I’m sure there’s more. What’s interesting about these tests is that any world class software engineering manager knows them. So the troubles mean poor choices in hiring for project governance, or weak organizational design such that project management could not control the processes and resources (and therefore the outcomes), or weak development methods and processes, or political management and goals simply overruling the dev teams. Taxpayer dollars are helping write a great software project management case study.




Crowdsourcing The Destruction of Software Patents

I've written previously in this blog about my skepticism regarding patents (and especially software patents). To this end, Joel Spolsky has done enterpreneurs a community service.  He's created a website for crowdsourcing the discovery of "prior art" to help prevent the issuance of software patents. Spolsky explains all.  Here's a link to his explanation and to his site, Ask Patents. Go out there. Find some prior art. Blow up somebody's crappy patent as a community service to entrepreneurs everywhere. 


Thinking Independently Starts With Control of The Information You Receive (And an RSS News Reader)

I've advocated for some time that a person who seeks independent (and innovative) thought needs to construct their own "online" newspaper with a heavily reliance on bloggers. I explain my rationale here.

At the center of my reasoning is that television networks, Google News, and other curated outlets limit and re-contextualize what you see. Watch this TED video by Eli Pariser and consider the following thought: if I'm running a business and I'm relying on Google Search, Yahoo News, the New York Times, or the Wall Street Journal, or any other news outlet; then what am I missing or misunderstanding that could damage my company and life (or for you opportunists, what have I been missing that could have enriched them)? To paraphrase Eli Pariser's terminology, "what is my online content provider's "filter bubble" actually filtering? The answer to this question is of course that you don't know. You only know if you own the filter. This problem is accentuated since Google has further diminished your personal control of information (RSS feeds) by the sunset of Google Reader. This will now require that your information be pre-aggregated (and monetized!) through their Google search engine or their social media. Which requires participation in their information bubble.

I'm not the only person with furrowed brow. Dave Winer helped develop the RSS messaging architecture used by blogs and Google Reader today.  Here's a post from his Scripting News blog.

"Waking up to the world around you, it's always controversial to say that big tech companies make money by controlling the flows to and from users and charging others for access. But that is at least one of the businesses Silicon Valley is in. And it's definitely the business Google is in, so if you want to understand why they might do something to restrict or try to control the flow of RSS, that's probably part of the story, at least. (I'm bending over backwards to be conservative here.). The thing to fear is that Google intends to control the news people can subscribe to, the same way Apple controls what apps you can buy for the iPad. And the way Twitter decides what clients can have access to our tweets. We broke free for a bit there with unrestricted flow from blogs and news orgs via RSS. There are people who would like to put the genie back in the bottle. They're not going to run press releases saying that. This is one of those cases where the reporters have to investigate to get the news. News people -- if your plan for the future includes free flow of news from journalists to readers, now's the time to take a look."

What should you do to become a "sustainable" independent and innovative mind? The answer is straight forward: manage your own information flows by seeking a direct unfiltered connection to knowledgable bloggers. The tool required for this is an RSS Feed Reader.  I currently use NewsBlur  because I like its ability to organize a large number of feeds. Find the tool that works for you. 



Just In Case You Need a Philosophical Basis For Your Entrepreneurship

If entrepreneurs and entrepreneurship have a modern day philosopher king, it is surely Nassim Taleb. (I'll leave it to you whether you personally need a philosopher). Taleb, the author of the The Black Swan: Second Edition: The Impact of the Highly Improbable", has written his next book, Antifragile: Things That Gain from Disorder . In Antifragile, Taleb describes, philosophically, how to thrive amidst uncertainty. He draws on philosophy and reason to (re)structure your strategic thinking around the ideas of risk and optionality. You will to your benefit learn to distrust forecasting and punditry. And having read the book as an entrepreneur you will also learn that you are fragile, if not expendable, to the benefit of a less fragile world, and as such you should be celebrated. But you probably already knew the fragile part.


Steve Jobs on how to think about things ...

Robert Cringely just released Steve Jobs: The Lost Interview.  The video boils down what an entrepreneur should learn from Steve Jobs; first, his huge focus on products and their meaning, second his attention to excellent people (and his distaste for mediocre people), and third his core belief that changing the world (or at least the marketplace structure) was the meta to selling products. Internalize those things. They are wise.