Software research shouldn’t be about the tools

It comes down to essential vs. accidental complexity, as outlined by Fred Brooks. What we research is new ways to ‘nibble’ at the accidental complexity: new languages (GO, Swift), new abstractions (Actors vs. functional programming in distributed systems), new methodologies (random test case generation). It’s what nearly every story on Hacker News is about.

But ultimately, I think most problems come down to two factors: the problem complexity itself, and the team tackling it. To me, many of the problems highlighted as software/IT failures, like the FBI registry, have nothing to do with a lack of good tools or techniques. These are ultimately management failures: scope creep, poor leadership, insufficient budget, too much budget, negative work environments, etc. It is ‘executing’ that is the problem, not the technology. How many errors have been caused by the US reliance on imperial units?

Look at this quote by a senior VP at Oracle on failures in implementing CRM projects:

[M]y comments apply to ALL CRM vendors, not just Oracle. As I perused the list, I couldn’t find any failures related to technology. They all seemed related to people or process. Now, this isn’t about finger pointing, or impugning customers. I love customers! And when they fail, WE fail.

I’d be willing to say that software engineers have all the tools they need. We need some form of continuous integration and deployment, abstraction mechanisms to simplify the problem, tests to verify our solution, version control to maintain a history of changes, and some form of requirements (whiteboard, paper, spreadsheet, what have you) to keep track of what needs to be built. I don’t even think it particularly matters how you use those tools. If you have a mature organization and process then you can all into the following matrix (James Montier via Jonathan Chevreau):

	Good Outcome	Bad Outcome
Good Process	Deserved Success	Bad Break
Bad Process	Dumb Luck	Poetic Justice

But just having the right tools, the good people, and a mature process is not enough to guarantee success, of course. You could be tackling a ‘wicked problem’. You could have a team of misfits and losers. You could have a manager who refuses to accept responsibility or make decisions. Most software research does not address those issues. I’m not convinced there is any research that addresses those issues: leadership, management, sociology… nothing can help when your team lead is having a marital crisis and can’t devote any time to product development.