Regis' blog

Why corporate motivation systems are counter-effective

2008-10-11T21:44:00.000+02:00

Although they appear under different names, the basic principle is similar: you are obliged to set up a set of goals at the year beginning and your achievements are assessed at the year end. So why is it so bad to "motivate" people that way?

1. First of all, there is no need for such artificial "motivation". If you do use it, the assumption is that otherwise people would never get their job done or at least they would be considerably less efficient. Software developers usually like their job and such an assumption can be offensive to them. My stance is that treating intelligent and responsible people like children who have to promise something in the presence of an aunt or they will not keep it, actually is demotivating.

2. How can you possibly plan a year ahead? Very often the goals set up at the beginning of the year are well obsolete at the time of the assessment. I have heard that this set of goals is a living document and can be updated during the year. But who really does it? Would it not be a sign of weakness (or even cheating) to change a goal because you are not able to achieve it? I think that sticking to the outdated goals can sometimes do more evil than doing nothing.

3. You are assessed against an arbitrary set of goals instead of your day-by-day hard and high quality work. Those goals are usually an addition to your daily work. Otherwise what value would they add and what challenge would they present? As a result, no matter how brilliant code you were writing throughout the year, you get UNSATISFACTORY because you did not provide one report on time. You cannot rationally consider this motivating.

Thorough recruitment is essential

2008-08-04T21:34:00.007+02:00

I guess many of self-respecting software companies would like to acquire and retain outstanding programmers. What do outstanding programmers need to feel appreciated? High salary and freedom to solve problems their own way. So why are companies reluctant to give such freedom to developers (why they are allergic to high salaries is as obvious as short-sighted)? Because they simply do not trust their employees. How could you possibly trust a developer, who is one of the every other on the street capable of passing your superficial recruitment process, that his/her next delivery will not wreak havoc in your production systems? That is why such companies rely on process, not people and their skills. The Holy Process seems to be the silver bullet that will keep the systems healthy regardless of who develops and maintains them. To some extent it may help, true. On the other hand, it also prevents innovation and kills creativity. That is why outstanding programmers try to keep away from companies where they cannot make exceptions to the process. Do you want your company to be one of that kind? Instead, maybe it is a good idea to refine the recruitment process to make it much more thorough, so that you can really trust the people who pass it and take advantage of their expertise and creativity? It is not going to be easy, no doubt. It is much harder to gather a team consisting of really good people and it takes much longer. However, I believe the results will be far better than when a strict process is the only guarantee of the software quality, preventing any innovation at the same time.

It is so easy to criticise an existing solution...

2008-07-19T23:09:00.000+02:00

You have been analysing a solution and you have found a flaw in it. What a crap! And the author - what an idiot! Quite often have I observed such a too quick reaction. But wait, not so fast... Maybe there are reasons for it looks thus, not otherwise?

1. You are in a luxurious situation: you can verify the solution in present circumstances. The author did not have such full data. Perhaps he/she was not a fortuneteller and did not foresee exactly what you are facing now. Perhaps the solution was optimal for those past conditions. True, the solution should be prepared for future changes. But in my opinion some changes are so unlikely, and certain types of flexibility are so hard to achieve, that it makes them impractical to implement. Anyway, I find it extremely hard to assess, seeing present conditions make the solution suboptimal, whether I would have predicted this at the time the solution was being constructed.

2. Despite the apparent flaw maybe this is still an optimal solution. Suppose you have decided to get rid of that flaw. So your starting point is the corresponding part of the design, without the flaw. While continuing, you have come across a difficulty, and to overcome it you have to weaken your initial assumption. Chances are you will end up with a solution very similar to the original one. Obviously, this scenario is not inevitable, but not impossible either, and it can contradict the premature assessment of the original solution.

3. A present solution is usually a result of an initial design and its evolution in response to new/changing requirements and gradually gained knowledge. It sometimes can happen that the initial design was unsuitable for what the solution has eventually become. This is probably the least justifiable reason of the three for apparently suboptimal solutions. Yet software is usually developed by humans and it is in human nature not to leave once chosen path as long as practical. It takes a very questioning attitude to realise that it is time to start from scratch or at least thouroughly redesign a solution after a considerable time of accidentally directed evolution. Or there was simply no money to do that.

It may be premature to assess a solution as crap before considering the above three scenarios.

Excessive communication considered harmful

2008-05-17T23:11:00.001+02:00

Communication is one of the core Agile principles. It is supposed to replace documentation to some extent and to foster knowledge sharing between team members. I guess it serves well both purposes. But...

I wish we focused more on programming and less on communication. To code a solution to a non-trivial problem a developer needs to concentrate and think. At least I do. When continuously involved in communication with different people, especially in communication not initiated by me, so concerning another topic than what I am just working on, it is impossible to concentrate and get the work eventually done. I am not saying we should not communicate at all. I only think there should be a way to avoid communication for a time period needed to solve a particularly difficult problem.

Modern office arrangements (open spaces) force everybody to communicate with everybody else, whether they want and need it or not. It is reasonable to put the whole team in one room. But not the whole development shop! And also there should be places in the office that allow for periodic work in solitude.

Knowledge sharing between experienced and novice team members is definitely a valuable thing. But it is not granted that a novice team member will ever get experienced that way. Since it is so easy to ask a more experienced team member, there is no motivation to become more independent. As a result, the novice team member can easily get into a habit of first asking and then potentially thinking, and never become experienced (him/her)self.

I believe companies should promote communication, but purposeful and managed, rather than thoughtless and unlimited.