Patterns and the Peter Principle - The positive effects of recognizing good application design

Old developers don't die... Sometimes they move up.  Think about it.  Have you ever met a manager who was a stellar Assembly developer once.  How about RPG?  (When I first entered management, the team could point to one time in my past when I wrote EasyTrieve code... if you can call EasyTrieve "code").  I can't count the number of dev managers or dev leads that I know who once wrote code in Visual Basic 3.0.

The problem is that design moves on, even if a dev manager doesn't.  This isn't wrong.  In fact, it is perfectly normal.  Our managers rely on smart teams to keep up, and they do their best.  No, the lack of advanced design skills in management is not a problem.

The lack of design skills in the design team... that's a problem, and the fact that most managers can't tell that their design teams stink because their design skills are not exactly "cutting edge"... That's the flip side of the same problem.

The Peter Principle says "A person will be promoted through the ranks of a corporation until they reach a position where they are utterly incompetent, and there they will stay."  In some corporations, this means that nearly all of management is essentially incompetent.  (At Microsoft, we reorganize management so frequently that incompetence tends to show up and filter out... but sometimes good ones leave as well.  That's another blog post altogether).

The Peter Principle in design says that excellent application design will go unrecognized, and poor application design will go unpunished as long as the manager was promoted before he or she learned how to design anything.  In some IT shops where I worked in the past, this was the primary rule.

Design was delegated to the ranks of the hero.  The system could not support the building of excellent design skills, or require excellent design artifacts, or even reward excellent design expressions, because the group manager was utterly incompetent in the skill of "recognizing and rewarding good design."

Therefore, developers who cared would first learn good design, then try to force their team mates to use good design, and then, after mountains of frustration, would leave.

If this is you, I have good news: you do not have to simply suffer in silence.  You can get off the merry-go-round.  Your first task is to learn how to EVALUATE good design, and then teach others (especially your manager) how to do the same. 

If you have a hard time convincing your manager to learn good design, then set up a competition in your company, with open submissions and a judging panel (made up of good designers) who will evaluate submissions and give a quarterly prize.  Hang a poster next to the elevator or the water cooler announcing the winner.  Pitch in $20 for a 'desk trophy' that the winner gets.  (I spend more than that schmoozing with internal customers on a monthly basis).

Once your team begins to recognize what good design looks like, it will be much easier to convince people to spend time and effort on improving the overall process so that good design becomes normal, and not the product of heros.

Everybody wins.  And who knows... maybe you will be the one they recognize next...