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?