Words interest me. They don’t exist in the real world. They’re the names, and descriptions we give to the items and events we notice in our environment. A classic on how well this works is Blind Men and the Elephant. It’s a short read, I’ll wait here.
Bad Matters Worse
The bigger and more complex object we try to describe, the more problems we have accurately doing so. So what happens when we try to describe something that doesn’t exist using words that don’t really exist? Sort of a meta-non-existence if you will.
For example, how about the word “software”? What comes to mind? I can’t show you a pound of software. I can’t hear running software like I can a running engine. I can’t feel software like the resistance of the keys as I type this sentence. About all software can be is mind stuff.
Since we’re using mind stuff (words) to describe mind stuff (software), can we expect to have anything but confusion?
Sliding Down the Slippery Slope
But that doesn’t keep us from trying. So we borrow words from other activities and use them. Words like “software engineering”. Mary Shaw’s original paper is titled “Prospects for an Engineering Discipline of Software” but somehow the “Prospects” got lost, and software engineering/engineers is/are everywhere.
The difficulty arises from the mental image created with the word engineering. Engineering disciplines have centuries of use, most prior to the mathematical models and physical understanding we now have. Engineers use standard repeatable techniques to build real world objects with specified characteristics in predictable time frames. If the time frame needs to change, it’s because of phenomena visible to all (such as it rained for 40 days and we can’t build while it’s raining).
This same mental image can’t apply to creating software since the field:
- is still young (less than 100 years).
- we’re still learning how to do what we do.
- there is no physical basis.
but we use it anyway.
Since we have the engineer mental image, it naturally follows that software projects should be managed using the same techniques as other engineering disciplines creating the next mental image, software project management. And how well has this worked? Take a quick peek at Kelly Waters’ post on Most IT projects fail. It doesn’t look good from here.
So Why Don’t We Change?
The first reason we don’t change is mind share. We have organizations like the Project Management Institute and the Software Engineering Institute proscribing how Things Should Be Done, and certifying those who pass certain criteria as PMP® or a certain CMMI® level. Disclaimer I am not anti PMI or SEI. All things have their place. But we’re dealing with meta-mind-stuff and management often confuses certification with both the ability to deliver the project and suitability of the certification to the actual problem at hand.
Another reason we don’t change involves inertia. In this case I compute inertia as:
inertia = mind share * time;
The equation’s time component involves how long we’ve thought this way, and a second order effect on mind share as people who believe this way get promoted to positions of management, then upper management.
The third model lock in involves cognitive dissonance. Data says the way we current run software projects isn’t working. But mind share tells us this is the way to run software projects. Common ways to resolve the cognitive dissonance include:
- Admitting it didn’t work, but we’ll try harder next time.
- Ignoring the project failure data (could this be why we don’t do a good job with metrics?).
- Chastising those lazy, incompetent programmers.
- (insert your favorite here).
 Change always comes from below. No one dealt four aces asks for a re-deal. Anonymous.
Perhaps the greatest barrier to change revolves around the question “Who loses?”
Guiding the Runaway Train
We need to be aware and accept that we’re working with the wrong analogy or metaphor. Software involves some aspects of engineering, but it also involves aspects of art. Rather than latch onto an existing mental model, we need to create a new one for dealing with meta-mind-stuff. We start doing this by changing the words we use to describe what we do, why we do it, and for whom we do it. The current counter position to “Command and Control” project management is “Agile”. Unfortunately this creates dichotomous thinking when we’re really dealing with a continuous spectrum of management options.
But what I’ve heard, read, and experienced, Agile (hereby defined by me for the rest of this entry as incremental/iterative software development) has a better chance of working since it uses a different management model. Rather than working with single pass logic, agile methods advocate breaking a project in several pieces, completing each piece in a fixed period of time. This would change a single 12 month project into 12 one month projects. This provides the following advantages:
- The customer gets value every month, starting with the most valuable parts first.
- The team can review and learn from the previous month’s work prior to starting the current month’s work.
- Plans can be adjusted monthly as new information becomes available.
- The person in charge (customer, product owner, whatever name you like) can see how the project progresses.
The section “Loops All The Way Down” in A Multi-use Model contains a simplified model depicting this. You could expand the Daily Standup/Team combination into feedback loops as well, one for each team member. The loops center around:
- What did I do yesterday? (feedback)
- What’s blocking me? (environmental information)
- What will I do today? (set point for tomorrow’s stand up)
This helps answer everyone’s primary concern: What’s In It For Me (WIIFM)?
- Developers can focus on immediate tangible results.
- Customers know every iteration how well the team understood what the customer wanted.
- The person in charge has progress visibility unparalleled in Command and Control environments.
The words we choose to use when we propose changing will determine how successfully we create the new software development reality.