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.