Yes project managers. Don’t we love them?
We tell ourself that they are important to the project but still we find it kinda hard to work with them. Why is that? My personal theory is that they are people employed to break the developers “flow” every half an hour and at the end of the week ask the mandatory question “Is it done yet?”. This is the time when we have to display a Jedi like self-control. But still we like them. Why is it that we can’t seem to work with them? Why do we constantly argue with them or just turn around and do their biding? Why I ask you?
And the answer is simple. They are the lesser evil. Most developers do not care about the business side of their work. We just want to write good code! We just want to come to work sit behind our keyboards and turn coffee into code! So we created the project manager to manage us! Take care of our basic need to not care about all the stuff that is not code. But lately I see that the PMs have developed self awareness and are trying to think. This is dangerous. Do not get me wrong not all PMs are evil. Some were developers before they were twisted and warped into PMs (pore souls). No the real enemy is the 30 year old graduate of a business school that is trying to manage the team and has no interest in the work or the product. He just wants reports and epilepsy inducing charts!
So what can we do about it? Well I see two options:
- Get read of the management and code like its 1996
- We learn to work with them
Sadly option 1 is not a option. Why? Because I am afraid that a platform debate would kill 80% of the development community and visual basic would win. And we cant allow that!
So we are stuck with option 2. But how do we do this? Simple we will apply the same technique that biologist used to study new species! We just have to do the following steps:
- Learn the basic information – in our case this means we will gather all the information we can about them. Goggle and Wikipedia are your friends
- Observe! – because we work with them it will not be hard to observe them in their natural habitat. So keep your eyes pealed and notebooks ready at work
- Look for nests after breeding season – OK this is just wrong and well gladly skip this part
- Go online and the library – already done that in step one. But a recheck could do no harm
- Ask the experts – because this is a new observation and not much literature exists on this subject finding valuable experts could prove a bit of a challenge
- Keep learning – the nature of our business is to learn new things so this should not be a problem
There is a PHD somewhere in there.
But alas we have not the time do this. So we have to take some shortcuts. Basically we will call on our immense deducticall faculties to give some pointers on how to get it right.
First we have to learn how to communicate with them. The main problem being that we use a language of abstractions and mathematical formulas and they use a language of pie charts and excel sheets. I lovingly call their language piesheet. So how do we start a conversation without an universal communicator? We should try to find the lowest common delimiter. In our case this is the project. We all work for it and we all want to see it get done if for nothing else then for the sake of getting reed of the monster so we can start work on a new one. Each on the team has to know what the project is about and what its purpose is. This part was easy, because most of it is dependent on the customer or target audience.
Now comes the first major tripping stone in the communication, “estimates”. They call them estimates I like to call them wild guesses. Well not even a guess because its easier to guess the lottery number than to give an accurate estimate. Lets take the following conversation:
PM: Bob, the customer wants an extension on the billing system. How long do we need for that?
DEV: What kind of extension?
PM: Oh nothing big (my development senses are tingling) they just want to be able to add an additional billing type.
DEV: OK?! What kind of billing type?
PM: They would like to have the possibility to split the payment between a cash payment and a credit card debit.
(This would be a perfect time to ask the all important question WHY? But for the sake of keeping it short we just assume)
DEV: So basically they would like to split the payment between two debiting stations?
PM: I guess. So how long would that take?
DEV: I would say no more that five days.
PM: Great. I will speak with the customer right-away.
So lets take a look at what each of them have taken from this conversation:
PM: OK the change will take no more than 5 person days and the cost will be 5 x 700$ = 3500$ to that we will ad 20% of risk management and 20% for quality control. So the final price will be 3500$ + 20% = 4200$ + 20% = 5040$. So the change will cost no more than 5040$.
DEV: How the freaking hell did they come up with that? What were they thinking when they ordered this stuff. Well OK we have 5 days and me and my team will make it in five days. So the calculation goes something like this:
3 developers working for five days at an average rate of 10 hours a day (when was the last time you left the company after eight hours?). 5 * ( 3 * 120$) = 1800$. But wait this is not as innocent as it seems. We have to take into account that the daily “business cost” of a developer is 700$ and so this little endeavor will take on a whole new dimension: 5 * ( 3 * 700) = 10500$ .
So we come to the situation that the change has cost twice as much as originally estimated. Why is that? For once the communication is just plain broken. The other one is that we are expected to make estimates on the fly. And don’t give me this meetings bullshit. You can not expect a single person to have the whole application structure in his head. A good estimation takes time. Time that is just not given. Then we could deliver a better estimation but not an accurate one. So basically we are screwed. But I know that estimates are crucial. What I can’t understand is that our misguided estimates are then presented to the customer as de facto.
Example time: When your car breaks and you go to your local car repair shop to get it fixed you first ask for an estimate. And that is what you get. You get an estimate of what it could cost. You decide based on that estimate, and then after the car is fixed you get the bill with a number that usually differs from the estimate. So why in the name of all that is holly do we do it the other way around? Still waiting for the answer to that one!
The second part of the communication issue is the need to explain things. This is shown in two ways:
- You explain everything multiple times
- You have to explain low level development stuff in piesheet (reference to language above)
From my experience most PMs are not interested in the technical stuff until they have to explain it to someone (a big salute at this point to my current team). So they just set up meetings and do not appear to them or show no interest in the development process that will produce the product he is managing.
So it happens that first you talk to the customer for 2 hours then you come to the office and just want to work. But no! You can take a chair and explain everything again to the PM. And after you hammer the knowledge into him you can go off and write the meeting minutes. So a two hour meeting will take anything from 4 to 6 hours of your 8 hour day. And then you are expected to do 6 hours of work on top of that. Do the math and tell me whats wrong here.
The other one is when the PM suddenly develops an interest in the implementation. Now you have to find a way to explain the code structure and other code specific things. This is just wrong. We operate at different levels of abstraction. Do you ask your surgeon if he will use a #5 or #9 scalpel? I don’t! Usually my only question is: “Will it hurt?”. Thats all the information I need. And to be honest I do not want to know how he will do his job. I just want it to be done.
And there is the question of how will you explain your “hack” you had to do to get the application to print on toilet paper? Do you really want to go through that traumatic experience again?
But enough about that lets take a look at another problem we have to solve, documentation.
Documentation is a big part of the software development process. Humans forget, document don’t! So we get the point of documentation. But every thing has its limits. It usually happens that there is to much documentation produced by the team and no one reads it. When you write a 5 page essay about a half hour meeting you cant expect us to read it. We were there for crying out loud. Sometimes documentation is written just for the sake of documentation. To have something to put into the document management system and point at it when you can’t answer a question. This is kinda counterproductive. If I want a given fact I do not want to read through pages upon pages of documentation to find out that the application background should be blue with green starts. Which brings us to the documentation format.
In my opinion word is a place where information goes to die. After a document is written it takes enormous effort to keep it up to date. And when it takes effort you have to force a developer to do it. Developers have a live up to date documentation of the system. We like to call it source code. It’s a shame that no one else in the world can read it. So what do we do about it? I like the idea of the project wiki. An informal place where information can be stored, and changed effortlessly. Some documentation in the form of document have to be created and maintained. But not all! I do not want to fill out a 5 page form just to get a refactoring done. And after I take my time and fill out the form I still have to justify my purpose in-front of a board of PMs. So whats the point of it?
Basically I have the felling that all the documentation is there so that someone could theoretically track all decisions the team had made in the project. And now I ask you. What would cause that to happen? Nothing! Even if people die they ask the developers and they can then tell them. No one goes through the million of pages of documentation.
So let keep the documentation at an manageable level.
What is that you ask? I do not know about you but the majority of developers I have talked to and worked with are men. And men are notoriously lousy at multitasking. That basically means that we can do one thing at a time. Like dos or windows 3.11. So we are happily coding away in the “flow” and then comes a question from across the room. You try to ignore it the firs time but your flow is broken. So you turn around to answer to a question that has absolutely nothing to do with your current work. Because your are a man you have to unload your current work context and load the question context, this can take a minute or two. Then you answer the question, which is in the most case’s a simple yes or no question. After the question is answered you turn around and try to figure out where you left out. It’s like if you are reading a book and suddenly have to sneeze. It will take some time to find the exact word you left of. Same happens here. Just that the process takes everything from 1 to 15 minutes. Not a big deal but if you add all of those minutes end to end they add up to a couple of days in the project where you just try to figure out where you left off.
The funny thing about context switching is that it is not broken if you stand up from the computer and do something that does not include your brain like drinking a coffee, take a smoke or just get rid of some extra weight in your bowels.
The human concentration is a funny thing.
The final verdict
Freaking hell you know I don’t have any! This is like the newer-ending story. There is just no end. All you can do is to work with your current situation. Or get read of your PM and pledge for temporary insanity.
I must say that I am one of the luck ones. Where I have a PM that cares for the people in the team and not just for the charts and excel sheets. I am really one of the luck ones. Not to say that there are not some rough edges in our team to. But we can manage.
If nothing else I hope you had a little laugh reading this. And if you one of the select few then I hope you have seen some trough in my silly little rant!
Thanks for reading and don’t forget to offer me a job 🙂