The Management Delusion

A good friend of mine sent me this:

Subject: New Stroustrup quote

"The companies are complaining because they are hurting. They can't
produce quality products as cheaply, as reliably, and as quickly as they
would like. They correctly see a shortage of good developers as a part
of the problem. What they generally don't see is that inserting a good
developer into a culture designed to constrain semi-skilled programmers
from doing harm is pointless because the rules/culture will constrain
the new developer from doing anything significantly new and better."

Those companies are in a bed of their own making. They want software written on a schedule which means hiring warm bodies who have the minimum training, enough to run a compiler, and can crank out code on a consistent basis; consistently low quality and in a consistently long time. When the pain of low quality software finally registers through their management-induced fog, they look for answers. What keeps these "Leaders" from admitting their own contribution to the problem?

Leadership sometimes means making hard choices, almost guaranteed to make someone unhappy. Leadership sometimes means suspending self-doubt to enable making those hard choices without the burden of guilt. Consider car company executives contemplating closing a factory - let all the employees down through bankruptcy or let a smaller set of employees down through a layoff? The best example of this would be President Truman's decision to use the A-bomb on Japan. Good luck trying get them to second-guess themselves - to do so would mean letting self-doubt out of the tiny box in which they hide it. Now, for the leader of the free world, we can understand why self-doubt is a luxury they can't afford.

What about the corporate world? Well, the upper-level executives may catch a break when they have to make truly gut-wrenching decisions like the car company example above. Middle and line-level managers do not have those reasons to hide behind so what's their story? Even without earth-shattering, bet-the-company decisions to make, a manager faces the same dilemma, how to isolate their own sense of self-worth from being damaged by potentially bad decisions. One way of doing this is by never looking back, never re-examining prior decisions, not entertaining the idea that they made a bad choice which is, by the way, popular with leaders at any level.

This may keep them from being paralyzed with self-doubt or wracked with guilt but is also makes them oblivious to their own short-comings. It takes a strong leader to learn from their mistakes, to emerge from self-examination stronger because they own up to their mistakes and learn from them.

Here then is the key. Allow me to extend the quote to the next logical step. Companies that are complaining about the lack of good developers are in a state of denial. What they are really complaining about is how few good developers want to work for them. There can be many reasons from an environment that accepts mediocrity to the unwillingness to pay the good ones what they're worth. In the first case it could be the red-tape just to get their development workstation setup, "What do you mean I have to get each Eclipse plugin on the approved software list!?!?" In the second case it could be failing to attract good talent; after all its only fair for a programmer that is 10x better than average to get paid 10x the average, right? Describing your workplace as "We have reasonable development policies and reasonably good salaries" you should not be surprised that you have reasonably talented programmers. To deny this is effectively admitting to self-delusion.

So, when your boss complains about the lack of good developers, they are really trying to deny their own reality and shift the blame away from themselves.

This reminds me of a story about 10 hiring managers who all insist they hire only the top 10% but I'll save that for next time.

Process Paranoia

Is your manager part of the problem or the solution and how can you tell?

Allow me to tell a story.

You are a developer on a large project that involves a large portion of the IT department not to mention multiple external stakeholders and has lots of moving parts and many upstream project dependencies. There are a large cadre of contractors working on a bug-list that keeps growing. The test environment is so complex that features can't be tested outside of certain windows due to the difficulties in getting all the moving parts built and installed correctly (no disrespect here, I mean it's that complex of a beast). The powers-that-be freeze check-ins to the development environment to reduce the number of moving parts during a weekly (yes, not daily) build/package/deploy to test. We won't get into the easy ways to handle this like tagging or snapshots, the management, which includes the technical leads, of the project have been working extra hours for weeks and don't have mental bandwidth to discuss theories. The large influx of developers who are supposed to help fix bugs only further tax the original developers with requests to help setup dev environments, understand the database, or request additional access to various resources.

This is not new, Brooks wrote about it decades ago so why am I writing about it now? With a project like the one that I've described, change management becomes a key tool in maintaining sanity and enabling success. By predefining a process and a set of criteria by which change requests will be evaluated, management has the power to be in control of the project schedule. One such example would be "Once the project has begun User Acceptance Testing, no more change requests will be accepted without approval by the CIO." The level of approval needed would of course vary by the priority of the project. There can be many such rules so that the threshold for permitting a change request rises as the project gets further into the development cycle.

If 'Analysis Paralysis' is the tendancy to continue to analyze past the point of diminishing returns, 'Process Paranoia' is the tendancy to reject efforts to define processes from a misguided attempt to forstall Analysis Paralysis. How is this connected to my tale of development woe? One of the upstream projects wants to provide a function for their customers which otherwise would require said customer to log into a second system to perform a query and then use the results in the upstream system. Normally this type of integration is commendable and encouraged. Why not now? When the managers allow change requests to be considered on an ad-hoc basis, it becomes highly probable that some request will trigger a fire drill of effort in order to evaluate the feasibility or ramifications when that decision should have been simply a matter of saying "According to our change management process, no change requests are accepted even for evaluation once we enter the testing phase without CIO approval." End of story. To do otherwise is almost guaranteeing that a project that was chugging down the tracks will eventually become a large trainwreck waiting to happen.

So the question is, does your management believe/understand/support proper change management processes or just pay them lip service? The answer to this last question goes a long way to answering the initial question of this post.

The Tale of Two Managers

Is the company you work for serious about software development? How can you tell whether your manager is susceptible to the "Death March" management style you ask? Let's discuss a negative case and go from there.

I have a new definition of 'Chaos Theory'. Those who don't understand how to develop software will never free themselves from the chaos caused by operating in constant crisis mode.

Have you ever worked for a boss who liked to give direction and expected their group to start running around doing anything because action == progress regardless of direction? Did we do stuff we didn't need to? So what, at least we're doing _something_. is their mantra. Imagine what would happen if we let modern skyscrapers be built this way. The financial backers would revolt because they'd have to write the check for all the re-work; the engineering team would go AWOL because their carefully evaluated design wasn't being followed; the workers would go on strike because of the unsafe work environment caused by the activity-for-activities-sake. If your manager never wants to discuss process (current or future) they might be trying to manage the chaos by dictating constant activity. My theory is those managers feel like they are having to flail like the dickens just to keep their heads above water because they don't want their team to know just how out of control they feel.
Let's call this manager "Suzy Spur" for her penchant for 'spurring' her team to action; her idea of effective management is making sure her cattle-prod has freshly charged batteries.

Now, let's switch gears to a large development project that has it's head on straight. While Eclipse is also a tool that Java developers use to create applications, it also has sprouted a mature project management template for coordinating large-scale (in number of apps involved) software releases.

The Eclipse organization has created a process that is rational, consistent, and repeatable. By thinking through the process beforehand, they do not have to make things up as they go. They release on-time and with high-quality even if that means leaving features behind. Here is a quote from the site

Ganymede is about improving the productivity of the developers working on top of Eclipse frameworks by providing a more transparent and predictable development cycle; Ganymede is about developers helping developers serve the whole Eclipse community

When the executives are clamoring for results, what they really are asking for is predictability. They want to know when they can plan on the next version of their application will be ready for release so they can plan their trip to Jackson Hole (for those without spouses) or Orlando (for those with families). What they don't want is a make-it-up-as-you-go process, of which Suzy Spur is so fond, that will send them to Las Vegas in August with no AC.

In comes "Craig Calm". He acts deliberately, instead of by reflex. He surveys the road ahead and lays out a route which will get him to his destination with a minimum of fuss instead of bouncing over each hill unable to see over the next rise. He prepares the project foundation so the flurry of change means asking different interior designers for their ideas on the finishing touches instead of tearing out walls because they were put up before the wiring and pumbing were installed. He is respected because his team can plan time off because his projects are always on-time or any delays are expiditiously relayed to the proper governance group; instead of reviled due to the ever-cracking whip and constantly worrying about being fired right before a family vacation because the project is always behind the eight ball -- the deadline never moving regardless of the increased workload.

When a deadline doesn't move even though the work increases, that is a classic sign of inadequate risk management. If you (project) manager is not insane, a sliding schedules would be a simple result of project math: Workload divided by resources = timeline. Of course I'm over simplifying but let me use an analogy here. You are in charge of building a dam and one of the project assumptions is the area will get no more rain than the largest amount in the last 100 years. If halfway through the site gets deluged with twice the 100-year-record amount, you do not go to your team, at the waterlogged site, and say "Guys, just work harder" or my favorite "Work Smarter". What the sane project manager does is go to the sponser and say, "We didn't plan on this, we're going to have to start over." It is not the fault of the team or of the project plan when the sponser approved the assumptions and then came up short. The book "Waltzing With Bears" is a fantastic resource on the subject of proper risk management and how it can restore sanity to your project.

So, for whom would you rather work? The insane activity-for-its-own-sake pile-driver or the methodical, consisent, and goes-home-by-five software development veteran?

Who Is Your Mother-In-Law?

If you were to describe the dependencies of your application, would they look like a family tree? Do you know all the services on which you depend and if so, to what depth?

Have you ever had your application fail because a service it uses is unavailable? Sure, but what about if that service uses a service that goes down? We've always done a poor job of tracking who owns which app, not to mention which apps depend on which other apps or services.

If we used make tools like nmake or ANT, we could describe each component as a target and include each targets dependencies and then let the tool tell use the extended family tree.

As a bonus the support of this distributed environment becomes much easier. If we update a given component, we can let the tool figure out which apps need to be notified of the outage/upgrade/etc.


Your better half (the UI) has it's mother-in-law come for a visit ( a legacy app wrapped as a service). Does that make indirect services into cousins?

Stalking a Serial Thinker

Some people think using groups of lists (1 dimensional) , others can think in grids (2 dimensional). I ran across this phenomenon when I was in a requirements gathering session for a complex revenue accounting system. Many of the components of the system had several attributes in common. The example I'll use is a family of four (Mom, Dad, little Gary, little Jan) and their bicycles. One way to describe the bikes is list each of the separately by the owner and then their attributes. For a serial thinker (let's call them Serial Sue), it looks like this:

Bike1
Owner: Mom
Type: Touring
Gears: 15
Size: 26-inch
Color: blue
Make: Trek
Model: Super-Safe Sidewalk
Wheels: street
Accessories: water bottle

Bike2
Owner: Dad
Type: Hybrid
Gears: 18
Size: 28-inch
Color: black
Make: Specialized
Model: Trail-aways
Wheels: knobby
Accessories: speedometer

Bike3
Owner: Gary
Type: Mountain
Gears: 24
Size: 26-inch
Color: red
Make: Specialized
Model: Porche
Wheels: knobby
Accessories: rear view mirror

Bike4
Owner: Jan
Type: learning
Gears: 0
Size: 16-inch
Color: yellow
Make: Murray
Model: Princess
Wheels: street
Accessories: handlebar tassels


Notice how each bike repeated all the attribute names? No big deal right? What if you now need to add 2 more attributes to each bike, or 4, or 10? You would have a lot of editing in your future.

Don't get ahead of me here but another way to organize this data is with a grid (aka a spreadsheet) which could look like this:

	Bike4	Bike3	Bike2	Bike1
Owner	Jan	Gary	Dad	Mom
Type	learning	Mountain	Hybrid	Touring
Gears	0	24	18	15
Size	16-inch	26-inch	28-inch	26-inch
Color	yellow	black	red	blue
Make	Murray	Specialized	Specialized	Trek
Model	Princess	Peaks-r-us	Trail-aways	Super-Safe Sidewalk
Wheels	street	knobby	knobby	street
Accessories	handlebar tassels	none	speedometer	water bottle

In this form it becomes easy to add categories and/or bikes; thus maintaining the list in an efficient manner. The problem? Describing this method to a Serial-Sue will confuse them. They'll ask, "Why go to the trouble of creating a grid, all I want is a list?" You might think that it is a simple matter of just do it they way your boss wants. That is fair but there is more to the story. When dealing with a large list of semi-related things, using categories to subdivide the items can be an enormous help in simplifying the organization and can help bring order out of the chaos.

Another clue you are dealing with a serial thinker is if you show her a grid and then have to explain it. It takes a different sort of brain. Much like how some people can't read maps well, go figure. Watch for symptoms of frustration when showing or explaining a grid of data to someone, it could be that you've botched your data, but it could also be a sign of serial thinking.

So, do you work for/with a Serial-Sue?

Intolerance of Vision

I've always been the type who likes to look far ahead on whatever trail I find myself. When I can see some obstacle, it only seems logical to report back to whomever is in command so they can make appropriate plans. What I've discovered is that some commanders are allergic to news portraying events beyond their mental horizon. "It's not going to happen for a week/month/year, why do you want me to worry about it?" That's a fair argument when you're in the heat of battle but rings empty when you're safe at home, eating dinner in front of the fireplace or when the battle-stations alarm is constantly clanging in your ear because everything is a crisis.

To ignore what lies ahead takes one of two types of people. The first is constantly in battle-mode and never feels like the have the luxury of looking down the road. There are managers who take this to the extreme by operating in this mode all the time and make management-by-crisis their modus operandi. If it doesn't get immediate results, they're not interested. It doesn't matter if doing things the easy way now will create 10 times more work later, the mantra is "why is it taking so long and when can we be done?" Quality, safety, sanity, all take a back seat to expediancy. The second type of person has a devil-may-care attitude and lives with their head in the sand. Worring about what might happen is for those wet-blanket types who keep telling me what to do like "wear your seatbelt" or "quit smoking". Nag nag nag, that's all they do. Can't they stop whining and live a little? While the latter is a case of simple denial, the former is clearly one of short-sightedness.

This brings me to tolerance. Imagine if General Custer had had a scout who kept him informed on the location of the belligerent Indian tribes but Custer got so annoyed by the constant reminders of upcoming trouble that he fired the scout. Having such a low tolerance for long-range vision (of both good and bad news) becomes a grim mistake. Having kept said scout and charging ahead anyway is completely within a commanders decision-making authority. It would not prevent the upcoming catastrophe but puts the mantle of blame solely on the commander. The scout's responsibility is to report what he sees and would be derelict in his duty to stay silent. The commander will be responsible for whatever happens regardless but ignoring information snatches from his grip the haven of excuses and tightens the noose of history around the neck of his legacy.

The deluded commanders ignore harbingers of bad news while deranged commander shoots them. The pragmatic one listens but takes his own counsel. At the very least, having another warm body around means one more person you can hand a weapon when you've circled the wagons and are faced with a relentless oncoming horde.

Do you know someone with a low tolerance of Vision? It'll take more than a visit to the eye-doctor to take off the blinders and open their eyes. Let me know if you discover an effective vaccine for this particularly nasty disease.