Another week of frustrating product design meetings left me thinking what can one do when faced with the equivalent of hit and run management applied to designing software. Generally a hit and run product designer will leave the design process to someone else, or a group of people, but will randomly interfere with ideas, insist on them, even if they turn the existing design upside-down, and leave for some time, until he is ready for another hit. I’ve had experience with several such cases, and I never feel I have the right solution for the problem.

Image courtesy of Jay Kinney

What makes a hit and run software designer

Generally hit and run product designers fall into two categories – chaotic and busy. The chaotic ones generally don’t have a complete, coherent idea about the design, they just have strong feeling about a specific features/screens/workflows (sometims even contradicting). The busy ones are good designers, that think that they have the entire design in their head, but are too busy or undisciplined to put that to writing. Although for different reasons, both types behave the same and seem to do equal damage.

Does this work, really?

Well, yes and no. It can work in the short run really well, if the person is motivated, energetic and charismatic leader. I have seen a case of a software built exactly like that – with almost no written specification, a single leader hit and run designing and managing directly every developer. If he knows very well what he is doing, and invests a lot of energy the result is a pretty fast time to market. Cutting off that 30% for design and planning makes it somewhat faster to get a first version out. At some point however, the result of the hit and run management and design surfaced. The product was successful and out there, when it turned out that the bug count was constant. The bug database always had about the same amount of bugs. There was no specification to turn to, so a lot of uninformed patching took place. Also, getting faster to market meant adding features to a buggy product, just the opposite of the zero-defect policy. For almost two years the bug count was constant. Developers felt as if they were beating a dead horse, since at some point it didn’t make any difference weather you worked your butt off, or spent the week browsing the internet – the bug count at the end of the day would be the same. Not that bugs were not fixed – they were. But every bug-fix either revealed, or caused another one. After years the dead horse was re-factored into a new, well designed and maintainable software.

We’ve seen hit and run management, its not that bad!

It is not. Hit and run management is not half as destructive as hit and run design. Hit and run managers will change priorities sometimes and make you re-arrange schedules, but at the end of the day they don’t have impact on the quality and maintainability of the code-base. Hit and run design however, results in a lot of redesign (in the early stages) or patches (in the later stages).

What to do then?

I don’t think I have a very creative answer to this yet, but I still have some useful advise.

For chaotic types, which are usually not from engineering background, but know the target field very well, you will just need a lot of extra effort in the design phase. Just lock yourself with them in a conference room, and start writing the specification as they speak their random thoughts. It is up to you to structure the document, which will be really hard. You have to be alert, since the random feature they are just talking about can be in a total conflict with what they talked yesterday. Keep in mind they cannot think of the system as a whole, they can concentrate on just one screen/feature/work-flow at a time. When they come up with a contradiction, you should scroll the document back, point to them what they said yesterday and make them decide how to do both.

This will be a lengthy, painful process. At the end of the day you walk of with a signed off specification, and use it as a shield against all later “great ideas” that will impact the design and void months of work.

For the busy type this does not work. You cannot lock yourself with them, since they are very busy. My usual reaction here is to turn into a real process Nazi, claiming it is impossible to proceed without a written, signed off specification down to the last detail. This really isn’t like me, since I prefer more relaxed and agile development process. Insisting on cumbersome, bureaucratic process is really bad for startup companies, which need to be quick and flexible. And startup companies are the place where you will find hit and run design most often. So this is just choosing the lesser of two evils, not really solving the problem.

If you are facing something like this, drop me a line or leave a comment, I think there has to be a better way :)