Recently I had a short talk with a colleague from a friendly company about how to challenge, please and get the best out of your top software engineers. He came out with the idea of a secret garden where the top engineers shall be shielded from the outside world to produce brilliant ideas undisturbed by people like average engineers or even worse people owning the requirements (i.e. customers). Feeling somehow uncomfortable I had the increasing wish to comment about this.

Somehow the whole idea felt very known to me – wasn’t it the way how in the good old ninetees (and even before) hundreds of IT integration companies separated their ‘top developers’ into a shielded group to write an incredibly ingenious application framework which the rest of the company should use to implement customer projects in zero time? All efforts I have seen in this way more or less failed and I guess so did the efforts I didn’t see…

Clearly a secret garden seems at the first glimpse as a very cool cure for the common symptom of seeing your geniuses drowning in (constantly changing) requirements. But this adresses not the root cause of the symptoms… Organize your requirements better and you will immediately ease the pain (different story, anyway…)

From my point of view the whole idea of a secret garden fails for various aspects:

1. It parts engineers into class A developers and class B developers. Why is this bad? It provides the base for envy and misunderstanding. And it just not works because class A developers have to fix broken code from class B developers anyway
2. It also implicitely assumes that there are class A and class B engineering problems. I strongly believe that there are no class B engineering problems. I have often seen this attitude when it comes to GUI programming, even to things like a company web site. I found this a particularly misdirected kind of thinking. Good (long term maintainable) GUIs are complex. And for no reason I want to put things like my <em>company web site</em> into the hands of average people!
3. It shields the secret garden from the real life. You are in danger to transform your young geniuses into divas! I think it is well known where this ends.

So what to do:

1. Don’t hire class B engineers even if they are cheap. This may seem painful at times but it rescues your engineering in the long term.
2. Organize the work environment inside your engineering but let your engineers directly face the requirements. If they are frightened then probably you have to organize the requirements better
3. Support your engineers to understand all problems as class A problems and give them freedom to work on problems with this attitude.

This for sure sounds like an ideal world but the whole discussion is about choosing good ideals

Hello there outside, why are we adding to all our spreadshirt blogs http://blog.spreadshirt.net/ just another one? Because they all don’t adress the engineering perspective of Spreadshirt which is a – ahemm – a quite central one. To say it this way: the IT platform is at the core of Spreadshirts business model. If you are reading all the spreadshirt blogs you know that customized apparel is a hot and amazing thing! But this is a blog from engineers mainly for engineers and it will more tell about the equally amazing perspective if you look at the technical inner workings of Spreadshirt and eCommerce in general. Have fun and tell us your comments!