Spoils of Peopleware

So,
I read this black bible of technology workers satisfaction. Or perhaps programmers satisfaction. Or perhaps even skilled programmers satisfaction. It is said that this book should be kept secret from any management spy which happen to hoover over your desk. This because it is said to contain revolutionary ideas and truths about productivity, contrary to management theory and practice. So what is it all about?

Projects are failing to meet deadlines, to implement the specifications, to specify what the costumer really needs. The book claim that there are often no technological issues to explain this, but rather political and sosiological issues.

"Development is different from production". It's not a process that can be tuned and kept in a steady state, but instead a dynamic organism that should be nourished and kept happy. It's about creating value through ingenuity, not by running the motor at full throttle. One hour of overtime (at which you seldom can work at 100%) may cost an hour of undertime (where you recover and clean up after last nights desperate moves). Deadlines are not always absolute. Sometimes it's acceptable and even sensible to delay a deadline to fulfill quality requirements. I wish we could have both. "Quality is free, but only to those who are willing to pay heavily for it".

Then there's this part about the office environment. Cubicles and uniform environments are strongly discouraged. As opposed to factory workers, programmers are said to be intellect workers, and there are different rules that make them perform better. Cramped and noisy quarters can be a killer to productivity. Personalization enhances smartness. Interruptions steals a whole lot more of time than their duration, due to interruption of flow. You need at least 20 uninterrupted minutes to start working efficiently, and you need at least one hour to produce efficient results. Thus, behold of the E-factor: uninterrupted hours per working hours. Try measuring them by yourself. It's suggested that your will achieve a factor between 0.1 and 0.4. The number alone tells no story, but try to calculate it prior to and after a change, like moving to another office space, tearing down the office walls, putting up walls, switching offices and so on.

The right people is another keyword. A short formula for success: get the right people, make them happy so they won't leave, turn them loose.

The first clause is about hiring. Have an audition. Make the candidated program. Accept those that your collegues think highly of. Measure the cost of turnover. It can easily be as much as 5 months of lost work. Consider them people instead of workers. Most people leave because 1) they're just passing by, 2) they are feeling disposable or 3) they are not loyal because they are being threated as workers.

It's all about putting a kick-ass team together. There's this concept called jelling, which is rather difficult to quantify. It happens when people are professionally happy with each other, they feel identity and ownership and eliteness. Don't change a winning team. Spend some money on jelling acitivties, like teambuilding. A few hundred hours can easily be spent, or what?

So, this was a quick and superficial summary of the epic. Mostly written down to serve as my own mindmap for remembering things. Everything favors the developer, and I guess any manager would have loads of counter arguments to any of the claims. I agree with the majority of claims, and then I guess the rest is not applicable to my situation. It seems as if the paradise of developers is a small company owned by the developers themselves. Growth implies overhead, and the overhead eats up the advantage.

But then there's some advantages of working in a production environment as well. Your schedule is predictable. Your hours are predictable.

Your duties are predictable. Your requred skills are predictable. And then sometimes they're not, but then it's no longer a stable and optimised production process, is it?