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?