Partly done – root of evil

Now, I’m not religious, but if I thought there would be a devil in software development his name would be Partley Don Woork. Do you know him? Shining on the surface? Nice smile? Cute outfit? But completely worthless when it comes to some serious work. And when there’s a problem, he just starts babbling and you have no idea of what he’s talking about. Don’t invite that S.O.B in your house!

A bad manager does not recognize Partley, or he think’s he’s a rather nice guy. Good to bring with him to customers for demonstrations and sales discussions. But all who have to work with the client after the sale is completed knows that the customers soon recognize Partley too. And they don’t like him either.

A good manager knows that Partley is not worth the applauds on a sales demonstration. He knows that even if he can get two Partley’s for the same price as one Completely Don Work, he knows there is a reason for Completely being so expensive in the beginning. He saves the cost by just cutting away all those expensive meetings where the behavior of all those Partley’s are being discussed.

The management for our software development department is now successfully working against all those Partley’s, and it shows. Not only does it show in the quality of the software, it shows in the actual value being produced. And perhaps most importantly; it shows in the pride of the people at the department. Having to work with Partley’s is bad for workman’s pride. And manager’s helping teams fight Partley boosts the productivity! Try it: there is a world with less Partley’s if we all work against him.

Project Management – the root of technical debt?

I’m currently labeled Project Manager. According to Wikipedia, that is defined as:

A project manager is a professional in the field of project management. Project managers can have the responsibility of the planning, execution, and closing of any project, typically relating to construction industry, architecture, computer networking, telecommunications or software development.

If you read that definition, you can see that the project manager is responsible for the project. The guardian of the project. Responsible for the project being finished on time, on budget and with the right features.

Many companies are conducting their development in project management style. When introducing a new big feature to the IT environment, a project is formed and a project manager assigned. So far, so good. The introduction of project management is often a huge step forward for organisations previously just using ad hoc system development, but there are also big risks to be taken into consideration. It’s not for nothing that the agile software development movement has risen. Projects are over budget, late and include the wrong features. But even if we overcome those problems, there is still other problems with project management and that is project management guard the project, not the complete system environment. In the definition it does not say that one should look at the whole system of an organisation. And the same picture can also be found in the literature I’ve covered in my class in project management. You could bring it down to the following: make sure YOUR project is successful.

So, what does this mean. This is an example I’ve seen to often. A project is started and when the time is running out, it becomes clear that a current feature can not remain as it is when the project is completed and has to be remade. The project manager thinks this is not part of the project and refuse to include the changes on his budget, since that feature has nothing to do with his project. So, the other feature just stops working or a poor developer makes a quick fix, which works poorly.

Another example can be that a project is carried out and a new process is introduced. This can be automated, but this is more expensive. The project manager does not want this on his budget so the process is manual. Then a new project is introduced and the same process is to be used. Since the first project uses the manual process, the project manager thinks this is ok in this case too. The operations (for they are all too often the ones to carry out the manual step) starts complaining that this takes too much time and that there are room for so many errors. But the project manager thinks that automating that process should not fall on his budget.

Yet another example is when time is running out, the developers fight hard to meet the deadline. So, bugs are introduced and technical debt is built through the using of in the long run poor quick fixes. The project is completed, the final report is written. But then after a month or two, the incidents start to build up. The project was successful in itself, but the effects on the whole was a failure.

This is not acceptable. Perhaps these stories are not as common as I believe, but I keep hearing them all the time. Project management can be the root of sub optimizing and there are few tools within the project management field to cope with these questions.

If you boil these issues down, I see them as technical debt. You are harming the system as a whole to make sure a new feature is working. And this is OK if all the other systems are useless or worth less. But we all know that this is not the case. The project manager might think so, but…

I have some statements I would like to add to the role of a project manager. I’m fully aware that this can make the title misguided, but I think the issues are more important than the title.

• We consider the deployment environment is to be considered as holy ground.
  A project manager should tread carefully on the deployment environment and guard it like it was sacred. We guard the environment to make it safer whenever this is possible
   
• We don’t cause harm to current functionality
  We don’t introduce code which is worse than the one which was there! We don’t make things worse for operations!

I’ll probably get back to this subject, if I’m not killed as a traitor by some other project manager.