I’m stealing the term from “big” Dave Thomas, who used it over 30 years ago. For me it means the “meat and potatoes” software development, whether it’s product development or custom IT work, embedded systems or applications, server or client. The key characteristics are:
- It’s done for commercial or business purposes (there are business stakeholders to really care about the outcome)
- It’s done by ordinary developers and teams… in general the teams will have a range of skills and experience. This includes some junior or mediocre staff.
- It’s project-based… it has time, content, and resource constraints.
This is “development in the trenches”. In fact “in the trenches” is a good analogy. You can learn a lot about S/W development by drawing analogies with other disciplines. I’d highly recommend reading the book Warfighting - The US Marine Book of Strategy. All you need to do is replace the term “war” with S/W Development Project, and you can learn a lot. I recognized in the book what I refer to as the “4 Fs”:
- Friction: In war, and in S/W development projects, everything is much harder than it should be. Things that are easy in a small or practice setting are slower and more difficult in the heat of battle.
- Fog: The information that comes to the leaders, whether S/W development managers or military officers, is delayed, imperfect, sometimes conflicting, and can’t be completely trusted. The higher up chain of command you go the more difficult it is to get accurate, timely data of the situation on the ground.
- Fluidity: The best-laid battle plans often do not survive contact with the enemy. The situation evolves and changes, and your plans have to change to align with the new reality. (waterfall development is particularly bad at dealing with fluidity)
- Fatigue: Troops can only sustain a full offensive for so long. Humans get tired, supplies runs out, equipment breaks down. Assuming that your staff and resources can sustain a “110%” effort on an on-going basis will only bring on eventual defeat.
Of course in war, as in S/W development projects, there are strategies and tactics that can be used to combat the 4 Fs, and increase your odds of victory. Warfighting emphasizes the criticality of the “OODA Loop”. OODA refers not to “Object-oriented Design and Analysis” but “Observation, Orientation, Decision, Action”:
- Observation: where am I?, What’s happening around me?, What do I see?, What data do I have
- Orientation: I need to make sense of my observations, interpret the data, deal with conflicting or suspect information
- Decision: Based on by observation and orientation, What’s my next action?, How should I adjust my plans?
- Action: Implement my decisions so I can move forward.
Implementing your decisions of course changes the situation and you then go around the loop again. The Marines’ belief that being able to go around the OODA loop faster and with more precision that your enemy is a strategic advantage in war.
Warfighting was released in the late 1980’s… before agile development practices evolved. But what is “going around the OODA loop in a fast an accurate way”, if not the basis behind the various agile development practices that are now mainstream? And isn’t it obvious the ways that agile development offers both strategies and tactics to address the dreaded 4 Fs?