Fragmented projects and overcommitted people

In 2010 I wrote two articles on Burn-Out and exhaustion in software teams. Since then there were more and more articles of this kind printed in the major german press. Psychologists warn companies and individuals that we are doing “too much”. I agree with them. We have increased our daily speed by lots, and I believe the results are not better at all. We produce the same results as ever, just with more stress. Anyway, the Burn-Out hypothesis is supported by the current “Stress report” which is published by the german government. While stress is not “bad” by default, it is clear that something changes in our working world.

For example: in the past two years I have met a couple of employees (permanent contracts) who respond to my e-mails even on sunday evening or late at night. While I think it happens that freelancers like me work on Sundays, I also think it should be very unusual to get hold of somebody with permanent contract outside his agreed working time. Thanks to our new mobile world, it is even possible to write a few sentences when going to the toilet. Software like Siri helps to not even touch the screen - perfect to dictate e-mails when cooking for dinner.

Overcommitted

I am very much committed to the success of my customer when I am accepting a freelance job. I am a working machine, counting a lot of hours each week. I am one of these guys from whom you can get e-mails at unusual times. Am I overcommitted? Is the 40-hours employee overcommitted, when she writes only a couple of e-mails at saturday night? What is the difference between the geek-freelancer and the reliable-employee-kind?

I believe it is the way of working. As a freelancer I can arrange my working times as I need them. From time to time I take a day off or have a nap at lunch time. Or I am going out with my family early afternoon. Yes, I am back to work on the evening, but I have the good times when I needed them. If there is something personal I need to deal with, I am not working 60 hours, I am just making 30. I am flexible, and as I wrote in The 10 Rules of a Zen Programmer, I can sleep when I am tired.

As permanent employee I don’t have such a freedom. I need to make my forty hours, no matter what. Sure I have holidays and such; but the constant number of 40 hours + overtime is always there. In many cases you can’t go to a rest room and take a nap. When you get a phone call that your kid has become sick, you cannot simply drive home: often we work in a distant, far away from where our actual life happens. The old model of 9 to 5 or 40-hours did work much better when there was no mobile technology. When you went home, you were gone. But now you have 40-hours, some overtime AND you are always connected to work with the shiny iPad you recently got from your Boss.

On the one hand fixed “core business times” on the other hand “always-online” - this doesn’t scale well.

A good bunch of people I have worked with are now very proud with the tons of e-mail they have managed to work through, with the specs they rewrote and the great service they provided, when they discussed a new feature with the customer - on sunday early morning. The new metric for a successful day seems to be the level of exhaustion.

Imagine: monday morning, door is opening. You colleague comes in and says: “I had such a great weekend. I slept the whole saturday, had a long breakfast on sunday and went of for swimming on sunday”. No Blackberry? Not learned any new great technology? What a lazy guy! What if he would come in with red eyes, tired and say:”hectic weekend. I needed an emergency call with the customer on weekend. Have you had the time to look into feature B? I promised that to him…” Heroic! This mate sacrificed his weekend for the company and finally your job. Shouldn’t you look into feature B this evening at home?

Overfragmentation

Why is the level of exhaustion so important to us? Our software projects are huge these days - is it related to that? When you craft something with your own hands, you can see the result and can be proud of it. You can show it to others.

Clean up your code for a week on the other hand. It doesn’t add new features, nobody comes to your desk and congratulates you for such a brilliant clean-up. Instead, work of weeks sometimes is described with “it is just one button who sends a report”. Building a product is the work of many people. Sometimes you just write code on a specific part nobody ever will see. The whole product is nothing you alone made. So more people, so less the chance that you can be proud of it. You need to measure your involvement differently, like: I made 100 commits, wrote 100 e-mails and had 10 meetings for this software version.

In ideal world, our software architecture includes well composed artifacts which are then handcrafted by small teams who can be proud of what they do. Even better, if the composed artifacts would become visible to others. You are suffering from fragmentation if you have 20 developers and just one component to build: nobody can identify with this whole mess of a code, people have fragmented responsibility.

The risks of Scrum

The agile world has got a hammer which makes every problem a nail: Scrum. Scrum is a perfect optimization of your workflow in many cases, seen from the project management point of view. From the developers point of view it is also good: one gets his things done. But Scrum has its risks when the team does not pay attention to the human factor. As humans we simply cannot put 40 hours workload in a 40 hours week. We need time to reflect our work. We need to perform minor refactorings. We need to read through code which we have looked. Sometimes we need to think! And we cannot estimate the time we need to think. We don’t know how much we need to think; do we need to rethink the whole model? Do we have our full-thinking-competence today or are we tired, because we dreamed badly? We need to accept: we are humans. We cannot break us down into numbers.

Scrum lets you look at your tasks with a clock in back. It is tempting to just work through everything until you are done. But hey, it is software development. Things change while we look at them, like the Heisenberg-thing. And be it only if we are to tired to work efficient on tuesday. Things like that happen. Deal with it when you do Scrum planning: don’t forget the humans behind the Scrum-roles. If you understand that, your estimations are ways better.

Creativity - how does it work?

I wonder how Van Goghs pictures would look like when he would have applied Scrum on his work. Guess we wouldn’t know his name today. Creativity under pressure - I simply don’t believe it does work (exceptions are confirming this rule). From my own experience as a hobby musician: I cannot compose anything when I am loaded with work. I need time to dream, to relax and think unusual thoughts.

Software is crafted with the mind. It is a creative work, even when we apply other creative works like ready-to-use design patterns. Sometimes we work on low/no-brainers, that’s true. But as we all know, we software people should constantly look at the code in the neighborhood and identify bug patterns or other things which would make our software more reliable and understandable. The art of software often is the art of minimizing your code. You can’t do that when are constantly under time pressure and delivering an endless stream of features.

The solution

It is simple: if you can’t stop focusing on work tasks, look at your family, prime time etc as a task. Plan it, do it, enjoy it as good as you can. Calculate the human factor into your Scrum sprint. Don’t measure your success on your overtime and switch off your mobile on weekend. You’ll be ways more productive on monday.

If you work on a system of which is to huge to be proud of, change it. Software systems should not only be maintainable, extensible or reliable - they must be enjoyable! A good system is one we love to work with - if we are proud that we could contribute a little to it, it can’t be so wrong. The best gardeners are those who enjoy to take a walk through the garden.

If you have come so far, you might also want to read “The 10 rules of a Zen programmer”.