As “software eats the world” executives need to “understand software”. If you were an executive that was old-school and wanted to “understand software”, what would you teach them?
These things come to mind:
- The software delivery lifecycle (feature request, defintion, build/test/deploy, operate, revise)
- Software is never “done”. Expect periodic updates, structure your engineering around many updates, not one big release; structure your budget around this. Even if software is “done” (feature complete) you’ll discover bugs and new security issues that require new releases.
- Operations exists and is important. You write software once, you run it billions of times perhaps for decades.
- Software is not magic. A lot of features look magical, but there is no magic. Just because gmail is really good at spotting spam, doesn’t mean a computer can easily (oh… for example) spot disinformation, evaluate a resume, etc.
- The size of a feature (as perceived by the user) is unrelated to how long it takes to create. A little feature might take years to make, a big feature might take a month (but not usually, natch!). In fact, providing simpicity to the user can be the most complicated endevour (it might take a year of UX testing, data science, etc. but what the user sees is that something automatically happens).
- Good software comes from breaking out of silos. Teams have to communicate bidirectionally, and across organizational boundaries that will probably make you uncomfortable.
- Malleability is expensive. Software that is easy to change takes longer to make initially but saves time in the future. Software that is difficult to change is faster to make initially but future changes may require major rewrites.
What would you add to the list? Please post comments below.
(NOTE: I’m crowdsourcing ideas for an article. I will try to give credit if you include your real name.)
