Category Archives: Uncategorized

The Cost of Modularity

Lego is such a great thing because it is made of simple components. When you build something out of it you can take it apart and build something different out of it. It is fun. If a piece breaks you can take the model apart, replace the broken piece and reassemble the whole thing. Great.

Of course this modularity comes at a price. Building the model of a fighter jet from Lego is much more difficult then building it from a plastic construction kit. Also the result of any Lego based attempt will look a little ‘bricky’. On the other hand, try to build a ship out of your fighter jet construction kit.

So there are benefits to modularity and there are benefits to sacrificing this modularity.

This is pretty obvious, isn’t it?

Yet in software development modularity is required almost every time, without considering the cost of modularity.

Also in software development modularity is sacrificed to budget and time pressure immediately, often before testing and documentation, also without considering modularity.

When is Elaborate Project Plannng Appropriate?

I got varying reactions on my last post. Some thought the story about making coffee using an extremely detailed plan was funny.  For example Fabio Akita wrote:

“Planning is the death of any project” Just an entertainment story, but fun nonetheless

I’m certainly proud to produce something that is considered fun. Yet my little story actually has some serious background. Of course the simple task of making coffee doesn’t justify elaborate project planning. But which task does? As we have seen, simple tasks don’t.

So how about complex tasks? Tasks that depend on circumstances in many ways, like e.g. balancing a stick on a finger, or playing table tennis. It would surely simplify the task, if we knew exactly when to make which movement. But we can’t plan this kind of thing, because the tiniest deviation from the intendend movement at some point in time will greatly change the required action some time later.

The coach teaching me project management had a great example of a project needing very accurate planning: When you build a nuclear reactor, the core will get encapsulated in a huge steel chamber. There are only very few cranes huge enough to move this thing. And they need a rail track to get to the building site, as well as a foundation for the crane to stand on. Rent of this crane is expensive as hell and you have to fix the dates years in advance. Everything that was needed for this crane and the needed structure, was planned with great care, to make sure everything was in place.

Few of us build nuclear reactors. For all others check these rules as a guide for the amount of planning justified:

  • How plannable is it anyway? Don’t try to plan the unplannable. Get it out of the way instead. This is what many agile approaches do, when they implement the most risky stuff first.
  • Do you have fixed dependencies between tasks? A plan becomes more helpfull, when you have many dependencies between tasks, possible with long ramp up or preperation time. As with the crane: The task of moving the steel shell wasn’t  very long, but the preperation had to start years ahead. Without a plan it gets easy to kill a deadline long before it comes into sight.
  • What is the damage done, when you don’t stick to the plan. In some projects, the only damage done is that somebody has to adjust all the plans. In that case, you might just as well scrap the plan.

You should Provide a Service, not a Defense

A row of cannon

Let’s assume you are manager (or just part of) a small department. The task of the department is to make sure that everybody in the company is using Grglwup for wumpeling and does so in the correct way. What do you do to achieve that?

The approach I see most of the times lets me wonder, if companies are run by Vogons. It looks like this.

A document is written describing the process for wumpeling by use of Grglwup in great detail. It gets published on a newly created website, which nobody knows about.

A 23 step process is put up defining how to get Grglwup, how to get a license for it and who is allowed to use it. It describes the 5 forms 7 signatures and 3 trainings you need, but it lacks any reason, why it is a good idea to us Grglwup instead of Open G which you could download and use for free and which is so easy to use, that anybody will be done with the task of wumpeling within 5 minutes.

Of course nobody adheres to that process. So an evaluation if wumpeling is needed and a 5 day consulting with the fixed result of advising to use Grglwup are made a required and expensive part of every project.

That was easy right? Now nobody can do any wumpeling without Grglwup as desired. At a side effect your department grew by a factor of 5 in order to handle all the consulting. Oh, and the cost of every project increased by about 10.000Euro for the consulting and getting through the whole process. Therefore people will hate you and your department.

I propose a different approach.

Find out why Grglwup must be used. If it is a valid reason, make sure everybody at least in your department understands it. If there aren’t valid reasons, fight the requirement.

Everything else is about making work with Grglwup a pleasure:

Write easy to use and fun to read documentation for it. Prefer a wiki as a platform so everybody can improve on it.

Make sure that that page shows up whenever anybody is searching for Grglwup, wumpeling or Open G on your intranet.

Offer free training for use of Grglwup.

Make the question: “What else can we do to make working with Grglwup easier?” part of every contact with a user.

Make sure that you reply to those that answer the question. Actually reply twice: First to confirm that you received the answer and then when you actually provide something.

You probably would like to have a single way uses address your team with questions about Grglwup. Still you should accept any way of communication: e-Mail, fax, phone or whatever. Don’t make them use your preferred tool. Of course you are free to funnel communication inside your department into a single tool.

Make sure everybody who might need to do some wumpeling, knows about you and your department.

If you succeed in this, everybody use Grglwup because it is the easy, the obvious thing to do.

Of course all this will cost money, just as the first approach. But you can’t charge the users for that. They aren’t the ones that want to use Grglwup. The company wants. So the company should pay for it.