Have you ever worked with, maintained, explored a system which looked and felt really great in one area, but was really awkward and clumsy in another one? That was an instance of an elephant on the crutches.

This often happens, when design specification was not consistent in the level of detail for different parts of the system. And here is how this may happen.

When you design a system, it is never going to be plain and the same wherever you look at. If you have a database and a user interface - those two parts are already different enough. Such diversity naturally leads to the fact that there are some parts that you enjoy working on more than others (after all we never like doing everything that we do).

What happens next is that you spend much more time thinking about parts you like (because there you use new fancy technology, or neat engineering approach, or who knows why). Therefore you add more details to design of those subsystems that you really like. The outcome of all of this typically would be a specification that is an elephant with crutches instead of hind legs, because elephant's butt was never you favorite part of the system and design of this "subsystem" never was detailed enough to make sure it is consistent with the front.

Ideally, your design should be like Google Maps: you should be able to zoom in and zoom out on any part you need. It does not make sense to have a map, which shows each and every tree in your neighborhood, but gives you only a vague idea about how to get to grocery store 5 miles away.

When developing and documenting design you should gradually and consistently increase level of detail in your specification. Ideally, difference in granularity of descriptions of different parts between any two parts of the system should never be more than one level. One possible way of zooming in would be to describe

• System + external interfaces, then
• Services and components, then
• Add their interfaces, then
• Add interaction (Sequence diagrams) and edge classes, then
• Components' structure and internal interactions, then
• Class-level specification for key requirements (functional and non-functional)

This is not the only possible way to zoom. However, when you have class diagram with methods and their parameters, but do not have stored procedures defined for your database, you are doing something wrong (or, hopefully, your design specification is not complete yet).

Design specification is only useful when it can help you answer questions you get during development. This essentially means that you should be able to navigate it and find things - which is zooming in and out and seeing enough to make the right turn.

Recently the food superstore I usually visit to buy food for my family introduced new size of parcels that they sell at the check out. Generally it is a good idea to offer smaller (and thus cheaper) parcels for those who do not need large ones. But let's look at this new offer from another point of view. Earlier the dialog at the check out started with

— Do you need a parcel? — Yes, thank you. (or No, thank you.)

And now it goes as

— Do you need a parcel? — Yes. (or No, thank you. And that is ok.) — Large or small one? — Hm... Well... I guess, large one.

You see, now selling a parcel takes at least twice as much time as it did before. And the new offer that was aimed at increasing customer satisfaction those on the line are really irritated by the process of parcel selection.

In fact, the process is more than two times slower. The reason is that first question does not really require a decision from you. You kind of know beforehand whether you need the parcel. But the second question gives you choice and asks to decide. And that is where one really needs to take his time and think.

Generally speaking, choice is good when it adds real alternatives. And in that case the choice should be supported by effective decision making process so that overall efficiency is not affected.

Every observation you make in day-to-day life can draw useful analogies to your professional activities. Today while I was serviced by the girl at the cash register at the super store I noticed that she wanted to optimize the process of scanning product codes. She grouped units of the same products to scan their code only once and correct quantities in the register. Theoretically this should have taken less time than scanning code of each product unit. In fact, because of this “optimization” I had to stay at the register longer that it would without optimization. Grouping of the units the same products took her very long. So although the cashier made fewer operations the whole process took longer. The main lesson from this observation is that you should optimize the whole system (end to end sequence of steps) not separate steps or parts of process. Theory of constraints tells us that every process (or system) has a bottleneck and it is this bottleneck that should be addressed by optimization. So be sure to measure and keep an eye on performance of the whole system while optimizing.