Technology Managers: You May Want To Jot This Down

Mitt Romney didn't just lose the popular vote and electoral college, he also lost the technology battle. Some unexpected but important lessons from the 2012 election:

(1) in-house development is better than outsourcing to consultants;
(2) free, open-source tools perform just as well, and often outperform expensive proprietary tools;
(3) flexible, user-driven requirements are almost always better than requirements predetermined by management;
(4) using untested software is risky;
(5) you cannot rush software development.

What am I talking about? The Obama campaign's software performed flawlessly throughout the campaign, while the Romney campaign's application was DOA. I've seen this pattern time and again in my fourteen years in technology. At the beginning of a software development project, there is a lot of time and money spent making a decision between developing the software in-house, or purchasing a vendor product and customizing it using professional services. This is a waste! I've never seen the latter approach work effectively. Managers often make a decision between these approaches based upon the cost. Hidden in vendor products, however, is that the total cost of ownership is usually a great deal higher than the initial price tag. Ask the Romney campaign if they think Orca was a great deal.

When development begins, projects often become overheated by unrealistic deadlines. This is unnecessary and almost always due to poor planning. Using this election as an example, Romney had already run for president once, and had been actively campaigning since 2009. He and his advisers should have been ready to build and deploy technology resources to support their campaign. Instead, their project had a seven-month development cycle, while Obama's team had a development cycle almost three times longer. This compressed timeline often cuts crucial quality assurance and load testing from the schedule with disastrous results. 

If you have a complex business problem, don't fall for a sales pitch: you likely need a custom piece of software. Hire the staff with the expertise, give them a stake in the system after it goes into production, and allocate enough time to do the project right.

Perhaps it is also a good reminder that a businessman doesn't always make the right decision. What makes software great is requirements based on close scrutiny of what the users actually need. What makes software great is metrics and thorough testing, not assumptions. Finally, what makes software great is collaboration and transparency, not competition and secrecy. Maybe all of this is a metaphor for good government as well.