Manuel Klimek

Mayhap the sea shines a dazzling blue the day you drown. Your arms get weaker with every struggling move, splashing salty spume into your burned face while the sun mercilessly grins down at your pathetic attempts to get a grip on the ever changing faces of the fluid. Fate played a little prank today, as you can easily see the shore not far away. If you only had learned to swim back at school. Those days are far away at this moment, while you stubbornly refuse to let go, frantically thrashing the water with your arms and legs. You hear a distant sound, barely recognizing it while your own heartbeat reverberates in your head and you cough up every hurried breath you take with the water that strives to fill your lungs and relieve you into a silent peace at last. Somebody at the shore seems to try to tell you something with a megaphone. And while you fight your body up to the surface time after time you somehow manage to make out some words: "... have to ... steady ... slow .... movements ...". Your last thought is whether those words somehow could have taught you how to swim.

You wake up drenched in sweat. Perhaps reading about agile software development isn't such an innocent way to spend your time after all. As your brain cells slowly take up speed under the ice cold morning shower you suddenly get the connection. This is exactly what you felt like when you read about "steady flow" and "fixed iteration cycles" in your extreme programming book while you somehow try to tie up all the loose ends in your project concurrently: like a drowning man being told how to swim.

Then you remember what it was like to learn swimming. The frustrating fear that just wouldn't let your body do what you knew works best to move through the water with minimal energy waste: Fixed and steady iteration cycles that give you a feeling of heartbeat while you do your laps. It takes a lot of time to learn swimming and it takes even longer to become a good swimmer. But it's really hard when you try to learn the process as an adult from a book. But what is the alternative? Relishing the ambivalent relieve of utter failure when you spent all your energy splashing? No! Get yourself a towel and a bathing suite and jump into the water.

From: dave.productmanager@yasco.com
To: karl.developer@yasco.com
Date: Fri, 13 Dec 2006 10:59:22 -0300
Subject: CustomerComany Inc.

Hey Karl,

we have a request from a customer that wants to place an order of some million dollars for our Xeepid. The customer now needs to know if it can fly. Can it?

Dave

-

From: karl.developer@yasco.com
To: dave.productmanager@yasco.com
Date: Fri, 13 Dec 2006 10:59:26 -0300
Subject: Re: CustomerComany Inc.

Of course it can fly.

-

From: greg.manager@bigcuco.com
To: fred.manager@yasco.com
Date: Mo, 7 Jan 2007 19:42:00 -0300
Subject: Xeepid

Dear Mr. Manager,

yesterday the first 2000 units of Xeepid arrived. Our development department started right away to integrate your Xeepid into our space ship. Unfortunately Xeepid didn't meet the requirements we asked for.
Mr. Productmanager told us that Xeepid could fly. IT CAN'T EVEN TAKE OFF! This is a serious fraud and we're going to sue you big time. Did you really think that you would get away with selling us an ordinary umbrella for our space ship project?

-

Emergency Meeting, Meeting Room 42:
[ Fred Manager, Dave Productmanager, Karl Developer ]

Fred: "Um, we have a little problem with one of our best customers. You all got a copy of this e-mail, right? So, Dave, what was going on?"

Dave: "Yea, right, I just did what I always do. The customer asked us if Xeepid could fly, so I asked Karl - and Karl told me that it could fly. Did you get that copy of the e-Mail, Fred?"

Fred: "Um, right. So, Karl, tell us, why did you tell Dave that Xeepid could fly. I mean, it's just an umbrella - how far would you say an umbrella can fly?"

Karl: "Of course it can fly. Anything can fly, it's just a question of how much energy you put into the task."

Dave: "Oh, great, you developers are bright guys, can't you just think about what the customer wants for a moment."

Karl: "Why should I do your job?"

Fred: "Hey guys, calm down. Let's try to concentrate on how can we blame all this on the customer..."

-

Today I tried to explain to my wife why requirements engineering is so hard. At first I just told her that you have to ask the customer what he wants. My wife said that it was obvious to her that you have to make sure you know what the customer wants. What is so difficult about asking the customer whether the product should fly?

The problem is: requirements engineering is not about the obvious questions. It's about asking the right questions to get requirements as unambiguous as possible. If a product should fly, you'd have to ask how far, at what speed, what type of fuel it should consume, how much fuel per mile it may use, or how it should be steered.

Every question leads to a myriad of new questions and all of them must be answered in the product. If a question is not asked, it may very well be perfectly what the customer wants - or not.

Asking the developers about features is a big challenge, since developers tend to think differently about the world than "normal" people. If you ask a developer how far an umbrella can fly, she will probably ask you how far you think you can throw it.

Today, the software development processes are a topic of heated discussion. The whole industry faces a stiff breeze from the agile faction that promises a new course on the quest for high quality software. The agile department on the other hand is confronted with FUD like not having processes at all.

So what are processes in a software development context? When we refer to processes we usually mean rules that specify when or how to do work. Of course we always follow some informal "process" when we work, but I'll refer to processes in the more formal sense of defined rules.

When I was a kid many of my friends had to finish their homework before they were allowed to play outside, while I was free to do my homework as long as I didn't get problems at school. The school thus imposed a when-process on me (I had to finish my homework for the next class) while my friend's parents created a process for their kids.

The school is also a nice example for how-processes. My eight year old nephew Marvin will learn how to do subtraction by hand this year. His teacher summoned all the parents and told them that this year a slightly different version of the borrowing algorithm will be taught instead of the method that pupils learned in German elementary schools for over five centuries (the difference is to "borrow" -1 from the minuend instead of +1 from the subtrahend if the digits can't be subtracted directly). This way the school defines how the children do their calculations - if they use a different way, they'll get bad marks.

So now that we know what processes really are, how do we find the best processes for a software development process? As always, this is a highly recursive problem. If processes help at the lowest level, they probably will help us to develop better processes. So we have to find processes to optimize the processes that optimize the processes. The good old fixed point problem - again.

Usually you try start a fixed point recursive problem with a trivial termination case. There's an easy recursive when-process.

When (not) to use processes.

If people always did the right thing, we would not need processes at all. In a software development environment we usually assume that all people work towards the same goal - delivering high quality software. But even if all team members had the same goals and were motivated to always do the best possible task for the company, they usually have different opinions on what is "best". Those different opinions may lead to childish fights about who should have done what and who's responsibility it was. Both parties think their solution is the best for the company and in this case a defined process can help to resolve conflicting goals.

And this is exactly the mother of all processes: Use processes (only) to enforce decisions when you're quite sure that no superior outcome can be achieved without defining processes. This is often hard to anticipate. At school I used to do my homework in the morning of the day I needed it, sometimes even during the breaks. But I always did all my homework myself. Some of my friends who were forced to finish their homework used to lie about finishing it, just to copy it at school. Those usually didn't do very well. Here the process obviously didn't help at all.

So let's try to get to the next step: what is the most obvious process that a software development team is willing to accept but wouldn't start on their own?

Use a process definition and optimization process.

Let the team figure out some processes for themselves. Let the team decide on the processes. Since the team usually has most experience in what runs smoothly and where to find the rough edges, the team should be able to identify processes that work for them. The team needs to buy into the processes anyway, and the biggest chance to get them to buy in is to have them decide it.

Of course not every team will discover processes like pair programming and test driven development for themselves. But they don't need to. It's no problem to present a fine set of processes, like XP or Scrum to the team for evaluation.

If the process definition and optimization process doesn't work, impose processes.

Let's face it: some teams just don't want to define processes or have anything to say about the way they work. They just want to get their paycheck and do as little as possible just so they don't get fired. And this is not a small part of the human species. In such a team you have to be weary because many good processes will fail, and you'll probably end up with a myriad of process definitions that are used as an excuse not to think.

But as long as you didn't try the process definition and optimization process you don't know for sure that it doesn't work. Software development is a highly creative process where motivation can cause a difference in productivity of an order of magnitude. Development processes are tightly coupled to a good work experience and thus to motivation. All this leads to the conclusion that software development processes are a very important aspect in software development.

Today, as a grown-up I'm mostly responsible for the processes I use myself. Nobody tells me when or what to learn, when to work out and what to eat. And I find that I learn more, work out harder and eat healthier. A coincidence?

Agile software development is a fixed point solution to a recursive problem.

When I was a little kid, my mother put me into the local chess club. It took me until today that I realize the impact the training had on me - other than spending my weekends with a bunch of geeks and not being able to get near girls (I don't count the chess playing ones).

As I learned later when I myself became a chess trainer, one of the difficult things in training young kids is to keep them interested in 'boring' things like playing chess. They usually start with a lot of enthusiasm, learning the rules, playing their first few games - until they recognize that there's a huge difference between knowing the rules and playing chess.

I remember when I was in that situation myself. It was just so hard to figure out which of the many options is the best move. I didn't spend another thought on what happened back than for years. But today I realize that Reinhard, our chess trainer, didn't just lecture us if we made a mistake. He just said: "What was the reason you made this move?".

It didn't matter if I found the best move during a game. It just mattered that I thought about the situation for some time and found the reason why I believed my move would be a match winner. For chess there's even an interesting rule that encourages thinking things through before making your move in a rush. It's called "the touched piece rule": if you touch a piece on the board you have to move it - even if it may crush your position.

One of the interesting things of games like chess is that they closely resemble life per se. Every moment of your life you've got a myriad of options to choose from. Every moment of your life you make a decision which move is best. Being a self-conscious human being makes this experience highly recursive and results in a fixed point solution: you may even choose the best way (to choose the best way)* to find the best move.

Many people try to sell you their silver bullets for software development just like a ninety-five percent non-smoking cure. Usually those methods are presented as professional sounding TLAs, lulling you into a mood of dedicated devotion. I try to sell one single piece of the great software equation today.

Adhere to the touched piece rule.

Which basically means: Think before you write code. This sounds obvious, doesn't it? You'll always think about whether the code you just rinse from your brain is correct in exactly the same way that a child learning to play chess asks herself if the move she wants to make is according to the rules, or if there are any current threats lurking from the other side of the board.

Correctly working code is not why you made the move. It's why you moved at all, why your fingers hammer on your keyboard. So the admittedly recursive question is: what is the right question to ask?

Ask yourself for every line of code why you write it exactly that way in this very position.

Just like some moves in a chess game that don't look too bad by themselves can draw a devilish grin in your opponents face, you can easily make the god of entropy smile smugly upon you with a few lines of correctly working code that are a little out of place. Introduce some dependencies here and there and let the butterfly effect do the rest.

This strong dependency on the initial condition in a highly dynamical process like software development gave birth to a methodology of heavy up-front architecture and design. So what's the problem if we can solve our architecture and design problems by thinking things through in the beginning? It's recursivity (again).

Design is code and code is design. If you design up-front you still have to watch every step. This design will not only influence all the design you do from this point on until the project dies or you retire, but it will also influence all the code. And because at the beginning of the project you don't have any experience with the problem domain you'll make a lot of bad moves.

This all culminates in a vicious circle of inexperience and bad design smells. This is the curse of software development: you'll always find a better way to solve the problem after you've solved it. Agile development practices counter this phenomenon by using small iterative cycles in development. Specify what you want - write a solution - refactor using the experience you just gained - redo from start.

This is often criticized as trial and error programming and taken as an excuse not to think about how you write software. But it is the opposite. It's about thinking how to write software before you write it, evaluating what you did after you made the move and then adjusting the code according to what you just learned.

A fixed point solution to a recursive problem.

A myriad of new virtual world communities besieges us to join the holy ranks of virtual knights or just lead a shiny new second life if you don't want to cope with the onerous exercise that reality imposes on us humble human beings any more.

Today I encountered a refreshingly new concept: Zweitgeist. The name of the service is a somewhat weird combination of words, literally meaning "second ghost", and at the same time a corny word transformation joke that is derived from the word "Zeitgeist", which seems to be a normal English word after all.

Zweitgeist is basically nothing more that the inverse function of Swarm which empowers the seeking web wanderer to find her hopefully like-minded information freak. Zeitgeist now utilizes the good old web as well established basis for it's virtual world - the web is the world, and you can meet people on web pages just like you would meet them at the bus stop or in your favorite movie theater. The virtual world experience is just another plug-in to your favorite web-browser that displays some cute little avatar pictures at the bottom of the pages you're visiting at the moment.

Normally all this would be filtered out by my "yet another noble business idea" low-pass pop-up-pop-down business filter. But if enough people manage to ignore the penetrating skirl of their George Orwell alarm this may become an interesting plug-in to your typical web experience. While I'd really like to know how they plan to scale up for a web site like google.com (a thousand little avatar pictures at the bottom of my web browser doesn't seem too appealing) perhaps meeting a few people on Joel On Software that share my obscure interest in good software might be a juicy change.

In the end the most interesting thing about this service will probably be if they manage to beat Metcalfe's Law, regardless of whether the specifics are right or wrong when you happily apply the law to Web 2.0 (I just couldn't resist) personality stripper networks.

While I didn't get a laptop I'm happy to share my experience with using Windows Vista for two months as main development platform at work.

The first feature that I really like about Vista is:

I can finally work as non-root user!

This is a feature that the Unix world knows for a few decades. So why did it take Microsoft until 2006 to make it possible to use a normal user account in Windows? Probably it's backward compatibility. They finally solved it in Windows Vista with a very tricky solution: if a legacy application writes to a system directory Vista transparently redirects the system calls to a file that belongs to the current user. This is one nice example for the old saying: try to get it right the first time!

The next change I noticed was the integrated desktop search. You can press the Windows button on your keyboard and the search line is focused (Microsoft rediscovers the shell). Now when you enter the first few letters of a word the menu gets dynamically updated and shows only programs (and emails) that match your search. While this feature is well known from KDE (alt-F2) and is probably available for Windows XP as an extension program, I really like this feature and use it more and more to search my emails and start programs.

The desktop search is not restricted to the search bar. The Windows Explorer now features a nice little search input line on the upper right side (just like a web browser) which you can use to perform a quick full text search on your files.

Now let me count. I discovered two (2) new features in Windows Vista that I really use. But I have to admit that those two features are exactly the concepts I missed in Windows for a long time now (since I knew them from Unix) and I don't regret switching to Vista as work environment (yet).

currently I'm researching the "Model Driven" approaches to software development. Yesterday I discovered some groups on xing discussing model driven architecture and model driven design. After browsing through some of the entries I discovered that the common understanding of model driven approaches seams to be "generate code from some diagram" or "introduce a new domain programming language". In my eyes this boils down to using a new programming language. And yes, I consider diagrams that generate code as yet another programming language.

I usually don't rely on forum discussions as primary source of information, so I wanted to find out more. If you do a google search on "model driven" you get the wikipedia page on model driven architecture and the usual suspects: information from companies that want to sell you their brand new model driven tools. As MDA seems to be a major topic on OO conferences you'll probably agree with me that this may be mostly due to some big bucks behind the movement.

But the concepts behind MDA are not really new. The wiki-page sums up the central statement of the model driven approach as:

One of the main aims of the MDA is to separate design from architecture and realization technologies (...)

This is old stuff. And I don't yet see how using UML models as programming language will solve any issues. The domain language approach is interesting, though. But let me explain my view on this whole architecture thing...

Separating the design from architecture and realization technologies is one of the main concerns of good software design for some time now. Eric Evans for example proposes the "Domain Driven Design" concept, which basically means to take the programming language of your choice (state of the art: object oriented) and create a set of objects with which you can build up a domain language that still follows the implementation rules of the underlying language.

The bad thing is that even on the domain level you are still dependent on the underlying language. But I know from experience that you can even code 95% of your C++ project in a technology agnostic way. This is the real challenge of software architecture: build or buy a technology layer that hides your underlying hardware architecture away and create an easy to access domain layer that nonetheless captures your domain logic.

The good thing about not introducing a new language, be it an UML model or a new domain language, is that, well, you don't need a new language... The key question is: why is UML or a new domain language better suited to the task of describing a domain logic than <pick your favorite OO language>?

Let's consider the options: What about using UML as a programming language? One of the first comments in the xing forum about MDA I found was about "hey, our programmers don't like the clumsy way to express all the complex logic in a UML diagram - can I create one by using a textual description? this would especially make diffing much easier...". This says a lot.

When I wanted to learn UML, I asked my colleges if anybody knew a good introduction into the topic. Andreas than got me some UML reference and handbooks. 1500 pages explaining how to use UML. But that wasn't what I was looking for. I was looking for an explanation of how to use UML in a way that it's actually generating business value. I didn't read those manuals but found "Domain Driven Design" by Eric Evans. Now this is technically not really about UML, but it introduces some very interesting practices regarding it's use.

Eric Evans states that a diagram should be used to communicate a concept. He argues that trying to stuff all the information into a diagram tends to render them useless. This exactly matches my experience. And this is why I don't think UML diagrams (or any graphical representation, for that matter) is a good choice as a programming language.

Now for the domain language. A domain language is a new programming language that enables you to write domain logic in a way that matches the way rules are usually expressed in the problem domain. In my opinion this is often a very good idea. It is used widely since a long time now (perl and the posix shell language started as domain languages) and there are myriads of calculator sized scripting interpreters used in commercial applications. You can probably think of some more...

But there is also some choice with regards to general purpose languages. When implementing a domain language (like php, which was originally developed to be used for dynamic web services) often the feature requests make the language a general purpose language over time (perl, php, bash, just to name a few). At that moment you have a new general purpose language on the market and have to ask yourself if it wouldn't have been easier to use an already stable language in the first place.

At the time of this writing, there are many general purpose languages that target different domain audiences. There are the functional programming languages that express mathematical concepts (while high performance maths is still done in fortran), the logic programming languages that target, well, logics and a bunch of object oriented languages that target web server development, web client scripting, web browser extensibility or just try to provide fine building blocks for object oriented domain frameworks and domain design (like java and C#).

So what should you do if you are an architect. My advice is to look for a nice general purpose language first. If your choice is one of those diagram compilers, than fine. Just make sure programming in this language fits your needs. If you find a framework for your chosen language that makes developing the domain logic easier, use it. Mind that I don't argue against using UML diagram compilers or frameworks or your own little language that you always wanted to implement. But I don't believe UML diagram compilers really enhance your productivity in all but a small limited set of applications. The same goes for elaborate frameworks or the use of awkward domain language wannabes like Gupta.

Most of your domain language needs can be met by today's general purpose languages.

The art is to use the language concepts to implicitly express your domain language. This can be done with every general purpose programming language I know (even with perl - which was built as domain language for string manipulation and "grew" into a full-fledged swiss army knife object oriented programming language and - in my opinion - often into a maintenance nightmare).

So what remains of the "model driven" hype? If you take away the fuss about expensive programming tools you get what Eric Evans calls "Domain Driven Design": Use diagrams that really enhance understanding. Use diagrams only to show few concepts at a time. Use your design skills to make your general purpose programming language feel like a domain language. And finally introduce a new domain language where it really makes sense. Most of all, come down from your ivory tower and get your hands dirty on the project.

The book in one sentence

A short, modest and dryly written book with some brilliant new concepts and a lot of too easy solutions which is worth reading because of the brilliant ideas.

Preceding events

How did it come about that I read a book about software metrics? I will have to digress somewhat before answering the question. There is a strong common believe in software engineering that software metrics are a dangerous tool, especially in the hand of Joel's bright young management consultant. But sharp tools that you can use to harm people can often be used to get things done.

What if our pre-pre-pre-(...)-pre-ancestors had condemned the use of a knife just because some of their brethren ran around slitting up other peoples throats? So I wanted to find out more about software metrics to decide for myself if they provide a new, sharp tool, or just a deadly weapon to be utilized by management consultants. But even with a lot of google magic I couldn't find a good critical introduction to software metrics anywhere on the web.

Then a few weeks ago an IT consultant asked about software metrics in a forum about software quality assurance at xing. I answered by reiterating the "dangerous tool" conception, emphasizing that software metrics alone can't be used as a quality assessment, which obviously didn't satisfy our questioner. Another member recommended "Object-Oriented Metrics In Practice", praising especially the solution oriented style of the book. So I figured that I should educate myself on the topic before broadcasting my opinion.

Reading...

The first good point the book makes is that software metrics can show only structural points of interest, but not design problems (unless you find a metric that can measure the semantical aspects of variable and class names, of course). Therefore a software metric can be used to find conspicuous code fragments that must be analyzed by hand to get substantial information. If Joel's consultant had read this book and had understood this concept we wouldn't need to be afraid of him any more.

The brilliant part of this book is the part about metrics visualization. If you ever ran cccc over a > 200kloc project, you know that visualization of metric results is hard. When I used cccc at work to assess our C++ project (before reading this book) I didn't find anything new or exciting in the results. The metrics showed me two or three structural problems that I was already aware of without using any metrics and quite a lot of false positives. After reading the book I came to the conclusion that it was not the metrics that were useless, but the simple brute force manner in which they were applied.

The idea of Lanza and Marinescu is to combine metrics in a way that answers specific questions about the code and visualize the results in a way that makes it easy for human beings to browse through the structure and especially to visualize the structure in combination with the metric results. If you want to learn more about how you can utilize metrics efficiently and how much work you have to invest to be able to use metrics at all, I highly recommend this book to you.

In the remainder of the book the authors try to give examples what metrics combinations should be used to detect specific structural problems and what refactoring should be used to solve a specific metric result. Those answers are often way to easy. If you're a fan of domain driven design, you are probably trying to base your design on the structure of the domain. So you can't just mechanically apply standard solution patterns to your problem, but you have to find the right kind of design for your problem domain.

Conclusion

For me this book was definitely worth reading. I'll try the tools mentioned in the book and see how the visualization techniques can be applied in real life. Since even the authors admit that metrics are most useful to get a starting point to assess legacy code, I don't think this book helps me a lot in my current work environment where I am still able to overlook the complete project. But the book helps you to view code and code metrics from a new angle, broadening your understanding.

My wife and I are visiting our families at Christmas. This morning I sat down at my mother-in-law's computer in order to check my daily spam when the mouse broke. OK, it didn't really break in the sense of the word - I just had to explain my mother-in-law that you have to charge rechargeable batteries before using them in your wireless mouse.

So I put the batteries into the recharger and realized that while the batteries were powering up I had no mouse. Since not using the computer for a full day (my god) was no option, I had to figure out how to use Windows with nothing but a keyboard. The principle was not new to me, as I already controlled my Unix flavored operating systems (like emacs) with keyboard FSAs and never really missed anything. But on a Windows XP box this turned out to be a whole new experience.

First I remembered the "Windows Key". I just realize that I don't know what to do if you don't have a Windows and a context key (first one left of the right control key) on your keyboard. Fortunately my keyboard got them. Anyway, the Windows key helped me to get Thunderbird and Firefox up and running. Thunderbird is really nice to control via keyboard. It's intuitive, and while it's not quite as comfortable as using your mouse, the basic task of classifying the spam mails into the spam folder was no problem.

Then I tried to use Firefox. At first this was rather awkward. Since the only keyboard control key I knew was the tab key, I tabbed endlessly through the user interface before I was able to extract the basic key combinations from various sources on the web:

1. F6: Change frame
2. Ctrl-L: Address box
3. Ctrl-K: Search box
4. Ctrl-W: Close current tab
5. Ctrl-PageUp/PageDown Previous/Next frame

Equipped with my new knowledge I entered my Wordpress administration page and tried to start a blog entry. Don't try this. It simply doesn't work. I nearly tabbed my brain out of my head. So I needed a Firefox plug-in to save my day.

Searching for "keyboard" on the Firefox plug-in page revealed the NumberFox extension, which I couldn't get to work, and the Hit-A-Hint extension. Hit-A-Hint worked great for me and I was able to do some serious browsing now. After a few minutes I stumbled across Mouseless Browsing. I couldn't find this one at first, because you usually search for "keyboard" and not "mouse" if you actually lack a mouse.

All of the solutions above share the same common principle. For every link, button and edit field on a web page a number is shown. If you enter this number in a special finite automaton mode you can directly browse there without tabbing to death.

For full blown keyboard control Mouseless Browsing is better suited. You can use it from within edit fields and it has a consistent interface for switching between tabs. It even supports to select a link instead of following it, which makes Firefox show the link target in it's status bar. But it feels a log more sluggish than Hit-A-Hint.

Hit-A-Hint is a quick and small solution, but you have to reenable it on every web page and the default configuration features the "h" as start key for your finite automaton, which is quite inconvenient if you want to enter "hello" into a text field.

While searching for firefox extensions that make my mousless life easier, I found the English and German dictionaries to get inline spell checking support in Firefox. I hope my blog entries will gain some quality with regards to spelling...

Hey, I wrote quite a lot today. This shows that with the right combinations of tools it's easy to blog, search the web and use dictionaries all at once without a mouse. Praise the inventor of finite automaton theory!

If you're in charge of an overly motivated programming team that meets all deadlines and produces high quality code you may recognize that they don't really need you. Here are 10 tips how to regain control.

10. Set up impossible deadlines!
    Repeated failure demotivates even the most undeviating member of your team. If you don't meet deadlines and are not trying to do something about it (like improving your software process) every new deadline will be a farce. You can be sure that in this case your team members will see every time estimation as a torture, randomly guessing some numbers, hoping that this time everything will work out. But of course they'll know that it can't work (you set an impossible deadline, remember), so they will be demotivated enough to get a nice vicious circle started.
9. Let them work overtime!
   I wrote let them instead of make them intentionally. Often software developers actually like to program. To make sure that they will introduce a lot of errors, which will eventually demotivate them, you just have to let them work. And work. And work. After some hours they will get tired (but will not recognize this state themselves) and will just check in some messed up code. Time works for you on this issue. If they don't work overtimes for fun, just make them (see 2 for a more humane way to achieve this).
8. Don't allow breaks!
   This is tightly coupled to 9. If your employee works overtime but makes a lot of breaks you gain nothing. The geeky brain has surprisingly quick regeneration capabilities (especially if a lot of caffeine is involved). So you basically have to combine 8 and 9 to get the pack tired enough. This way you maximize the error rate which will eventually yield the demotivation you aimed for.
7. Place a ban on laughing!
   You can use this tip not only for programming teams. If you want creative workers to produce nothing useful, don't allow them to laugh or even better: don't allow them to talk. When they're quiet and unhappy you can be sure that you will not be able to write code.
6. Break the coffee machine!
   Programmer (n): An organism that can turn caffeine into code.
5. Don't shield them from the dirty daily business
   Even the brains of programmers have limited capabilities. So one easy way to demotivate your software developer is to challenge him with tasks he hates. Tasks that have nothing to do with software development work best here. Make the developer lie to the customer about schedules, or make your team hold the customers hand when they don't want to learn the basics to integrate your product into a complex environment. Often you get a nice demotivation by forwarding angry mails from other company's CEOs to your development team or let them handle wobbly feature requests.
4. Don't challenge them!
   Most developers are motivated when they can work on a real challenge. So don't let them. Of course with software development being a challenge per se, this will inevitably lead to 5. But if you try to implement tip number 5, you have to remember not to give them tasks that challenge too much.
3. Underpay them!
   While paying more than your programmer is worth will usually not gain any additional productivity, you can easily get a good demotivation by paying less. The important thing is that the developer knows that he's underpayed - this maximizes the negative impact on his overall performance. You can easily drop the productivity by a factor of two or three depending on the basic motivation level of your employee.
2. Bribe them!
   And do so generously! Promise them a lot of money if they meet some utterly impossible deadlines (see 10). You can be sure that this will motivate your programmer - to mess up. She will work overtimes (see 9), sitting in front of her computer without a break (see 8), not accepting any interruptions by coworkers that want to cheer her up (see 7) or take her to the coffee machine (see 6). She will be concerned about the figures all the time to make sure that everything is all right (see 5).
1. Infiltrate a team member who is demotivated anyway!
   If you don't want to use 1 to 9 for ethical reasons, you can always find those people who are demotivated anyway. These are mostly people that don't really want to develop software and just do it for the money. Since it's mostly easy to make everything look bad, this is usually what they're really good at. And since they don't want to work, they'll pull everybody around them down into their little black hole of demotivation.