Communications of the ACM
Software Quotes and Counter Quotes
There are certain phrases and motifs that get repeated in software efforts. I've encountered a few particularly problematic ones with such regularity that I've catalogued them, and I've additionally collected counter-quotes for use as spot treatments as well as an inoculation against future ill-formed thinking.
Heat vs. Light
- "In any moment of decision, the best thing you can do is the right thing, the next best thing is the wrong thing, and the worst thing you can do is nothing."
- Attributed to Teddy Roosevelt, 26th President of the United States
Teddy Roosevelt is credited with establishing the national park system, which was no small achievement and something that millions of Americans still utilize to this day. He briefly studied Judo as president — certainly the first and probably the last president to do so. He started the construction of the Panama Canal. Though pro-business, he was a trust-buster. He was an imperialist, but he mostly got over that and at least didn't start any wars while in office. He was known as a ball of energy. While most software leaders won't generally quote Roosevelt directly, they can mis-use the above quote by emphasizing his "busy-ness" and assuming equal efficacy. Be quick! Make haste! The trick was that that Roosevelt was extremely well-read and a prolific writer, and arguably better than most in his day at making "right thing" decisions on the fly. Most people aren't that adept and should take the time to stop and think, especially when making big decisions. Doing "nothing" at a certain point in time might be a better option than blowing something up accidentally.
- "That is the first rule of flight control. If you don't know what to do, don't do anything!"
- Gene Krantz, NASA Space Task Group flight director, Failure Is Not An Option, pg 32.
Gene Krantz was not advocating inaction, but rather advocating against *random* action. Do the problem research, choose a path, document it, test it, and if the path holds up, then make it happen. Otherwise, go back to the beginning. Do not, under any circumstances, run through mission control flipping switches in the hopes that something good might happen spontaneously. The same goes for any production software environment today. Software leaders frequently not only miss the discipline and rigor of writing up problem research, but also frequently fail on budgeting, on test environments, and the time to test effectively. Not being able to adequately test changes — either functionally or technically (e.g., scale or performance) — should scare anyone. Plan ahead.
Reactive vs. Proactive
- "We should set up a SWAT team and…"
- Various people I've worked with.
I've lost count how many times I've heard people say this, and it is typically said when something is either in flames or about to combust. It's good to address problems and be responsive to emergencies, and sometimes fast roping-in for some furious coding needs to happen. But the spirit of "SWAT" requests tend to be short-term and without follow-through on addressing underlying causes. Similarly, the members of the proposed team were probably doing something else, or are being asked to put in some serious overtime. "We should have a hackathon and…" falls into the same category.
- "Special ops don't win wars, armies do."
- Told to me by a former Israeli commando I used to work with.
My co-worker was not arguing against special operations per se, but rather overreliance on them. He was highlighting the importance of easily overlooked activities such as transporting troops, food, shelter, other supplies; maintaining communication networks, treating the wounded, establishing a defensive perimeter, collecting intelligence, and trying to establish relations with allies. In short, things that appear less exciting than kicking in a door, but are still complex and support sustained effort and progress. If your software wants to have users and marketshare, it needs to be able to take territory and hold it and not burn out the team after the first release. Properly staffed DevOps & SRE teams are an example of critical technical support activities, and they can be as important as the product itself — especially for preventing things from going wrong in the first place, and to have adequate logging, metrics collection, and monitoring already in place for when they do.
Are We There Yet?
- "We need an MVP."
- Various people I've worked with.
Speaking of burning out after the first release, "MVPs" are one of most quoted and misquoted aspects of software development. Whatever the development methodology employed, it is completely reasonable to want to put out a release that meets a market need, full of features that represent a Minimum Viable Product. But I've seen too many instances where the MVP effectively becomes the final state, because funding or interest for the effort disappears after the first release. "Haven't we done enough?" goes the argument for inaction. But MVPs are supposed to be a beginning, not the end.
- "If your framework is successful, you are never done."
- I heard this at a Strata Data Conference years ago. I believe it was a presentation from Netflix.
Successful software efforts are defined by having users and forward momentum. If users like what they see, they will ask for more; if there is forward momentum, they will get it. If users like what they are getting, they will keep using. And the cycle continues. As I wrote in my ACM blog "Anna Karenina on Software Development," it doesn't matter what software methodology is employed, there are common traits that all successful software efforts share, and no shortage of ways to make them slip on the tracks. Happy software efforts are all the same, and unhappy software efforts are unhappy each in their own way.
The Need For Speed
- "We need this for performance reasons."
- Various people I've worked with.
Performance issues are a factor in any software solution and there will always be bottlenecks — they just move over time and from place to place. But before any performance-related changes are made, teams should first get performance data, and a lot of it. It is surprisingly easy to chase something on a belief that it is "the problem," only to realize it was only a shadow or background noise. There's nothing wrong with starting research with a hunch, but that can't be the complete analysis. Invest in performance monitoring and tooling so this information is regularly available to teams for incremental improvements, and not just in emergency situations.
- "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil."
- Don Knuth, The Art of Computer Programming, Volume 1
Software runs on computers, but is written and maintained by humans, and human confusion is an expensive problem. Confusingly optimized software written by confused humans is even more expensive.
See Also
On decision making in software efforts, my post on The Art of Design Regret.
References
The "decision" quote is attributed to Teddy Roosevelt, but may be apocryphal.
Doug Meil is a portfolio architect at Ontada. He also founded the Cleveland Big Data Meetup in 2010. More of Doug's ACM articles can be found at https://www.linkedin.com/pulse/publications-doug-meil
No entries found