Mouth-To-Mouth Design

Agile and pragmatism are very buzz-words nowadays. Everyone seems to argue doing it all the time (hey, I do it too!), some use more or less classic or modern methods to do it. But:

One of the biggest misinterpretations seams to be the complete elimination of any visible, replicable design activities from the development process. It never really depends on the size of your enterprise or your team, when you fall in overdoing the pragmatism through ridiculous mouth-to-mouth design.

You are asking yourself what it is - the mouth-to-mouth design?

Well, first of all, it is making design decisions during coffee breaks, spreading them over the heads of those who are more or less by accident there with you, and never writing those decisions down later in a form which someone else could also read. Why write, when the people who should know this are all collected together in the kitchen? Bullshit! What about those, who come later or are far away doing other projects? You want to coach them the design later? Are you sure, you still remember everything? Isn't it absolutely ridiculously simple what you are working on if you really remember everything? Are you sure you can coach well? Aren't you afraid that this would work like a terrible telephone? Are you sure, you are forever there? (even if you seem to try hard to be, when you do the mouth-to-mouth design) Personally, I wouldn't be. Collective knowledge is good, but also when it gets spread correctly to those who come after you.

Second, mouth-to-mouth design is protocolling design decisions by email or in the bug tracker. It cannot be right to spread the knowledge over tons of different sources instead of having it collected in one central place. Even having an own Wiki the knowledge doesn't often find its way there from the many bug tracker entries and discussion emails. Oh, you say the code is the ultimate truth? Yes, it is, when it comes to the runtime. Before that, it never scales to have design decisions only in heads and in textual, misplaced molecules.

Third, it is when you just call someone to make this and that for you without even having any protocol of this. Even if it's bad to have the knowledge spread over the bug tracker issues, but this is at least some protocol. Calling over to someone to make a basic thing for you, and you both never write a word about it is the road to death. Doing that all together is collective suicide. Maybe not for you, but for those who will follow you, and there is always someone following you.

I can't stand mouth-to-mouth design. It never works well and has nothing to do with our profession. Instead, it's absolutely unprofessional, dangerous and you need then mouth-to-mouth insufflation because this always falls apart. Sooner or later.

Manifesto for Cloud Computing

I am proud to be part of this great Manifesto for Cloud Computing. This manifesto is supposed to revolutionize the modern IT world in the same way as the Cloud Computing itself sure would. The value pairs as well as the principles which we have defined are as clear and progressive as the Cloud Computing itself. We are sure or at least we hope that the community of those who will commit to the fellowship will grow every day. Use your chance today and tell us more about your own principles of Cloud Computing.