How to undestand you ride a dead horse

Finally, it’s my turn to write about the dead projects. Mostly because I am taking part in more than one now. I collected my observations during the last months and am ready to share them. Let’s start from the most important thing – how to realize that you are working in the zombie project. Zombie – because you can’t say, it’s dead – sometimes a huge team is working on it and you can swear you hear it’s breathing. But it can be only the sound of wind in the tubes.

How to find out that your project is a zombie

1. Smell

Yes, that simple. Just ask the team. They usually know, that the project is dead. During the retrospective ask every member one good question: “Do you believe we would reach the project goals?” Sometimes they can even ask you “What are the project goals?”. It most of the team says “No” – you are in trouble. They are fighting for something they don’t even think is possible to gain.

Too often the timing plan is to tough, managers just push us to accept it. Using threats, using “but you are a professional! senior developer. I know senior developer can do that!”, bonuses, etc. Team says “yes”, but is not believing it is possible. Also the problem can be in technologies – you are using some old ones, which have restrictions, so the goal is not possible to reach. Budget is the same as time. If you hear “It is a high competitive environment, we had to provide a discount to win this deal!” – the budget is not possible to fit. Naive promises are made too often.

The reliable sign of the problem project also can be the lack of staff or resources. If you come and see that the complex project(after you read the project info you imagine smth like a year of development) is developed by 2 developers – middle and junior one – you are definitely in trouble) Especially if they say “They don’t allow us to hire QAs, as they think we should write the code without bugs, not waste time on testing.” Run, just run. Your life is too short.

2. It is not moving or moving slowly

It takes ages to implement new feature. Business guys are furious.

When the team says “But we need to do a refactoring to implement it and not to ruin everything” the answer is “I need that on Monday! I don’t want to hear about the programming details, I just need it!”. Continue doing that and once you’ll get the dead code.

Let’s look at the lifecycle of the dead code projects:

1. Planning is to tough. Team does not have time to set the proper processes – they just need to start coding. Don’t ask, code!
2. Refactoring? Code reviews? “You know, only the companies with enough budget can afford that. We are young, but ambitious company! We need to create product!”(for product company) or “Our customers won’t allow that” (for outsourcing company). Don’t think, code! Faster!
3. Why so slow? You tell me we need a week to add this minor feature? “Let’s add more developers! “(for non-Ukrainian projects) Let’ fire the developers and find new ones! (For the Ukrainian local projects).

Every touch can ruin the “so-called” stable system. Managers are talking a lot about “stability”. Code inside is a mess. If you take a decision to rewrite the project – go to 1, if you are going to “refactor it all” – go to 2.

3. It is controlled by the superpower

You are looking at your zombie and see that it makes some irrational movements, decisions seem to be made somewhere else, not in his dead brains? Definitely, it is politics.

I think it the most dangerous thing for the projects – politics. You think such problems can be found in the projects which company develops internally? No, even in outsourcing you can come across that. When there is more than 1 person involved – politics can appear and ruin everything. My projects, which I used as an example for study, had the worse case – they had investors who ruled the product’s development. And I was surprised to see that it looked like they didn’t want to have the successful products – a lot of decisions were irrational and strange to me. But definitely there was some reasons (I believe nothing happens just by itself, there should be a reason 🙂 I am sure “politics” took place. Especially after my colleagues started mentioning “Oh, doesn’t be surprised, it’s all politics” (Oh, you thought that I was so smart to get it by myself? 🙂

How to cope with the dead project? Use electricity, so it will move during the release demo. Deliver it to the production server and forget about it. *sarcasm* Next time I will write my thoughts on what to do with zombie or zombie – like projects.

This time I will only give an advice (personal opinion) how not to get in a zombie project. So, there are some words or facts which can rise a flag for you during the interview:

•  The classic phrase (it is common for Ukrainian companies) – “We are international fast growing company, a leader in its segment…” Just no.
• No documentation or it is far not up to date.\
• Company does not support developers to study during the working hours. “You are a professional, you should know everything you need already – you should work 8 hours, not read books!”
• Project is old (4+ years). One this fact can’t tell you that the project is a disaster. But in addition to others should make you think twice before joining the project. One of the benefits of the old project is that it is successful/profitable enough to live so long.
• There are some “core” developers in the team, who work there a long time and management thinks they “can’t be replaced” professionals. Especially if they are on the same position as they they joined the team.
• “Yes, we have certain problems, but we would like to have a “fresh blood” for our project. So we are going to hire you to raise and develop the project.” Especially is the person who says it has the tears in his eyes.
• Non-technical PM who rules the development. I am not against the non-tech PMs, as it is not really the managers part. But usually in our country non technical managers are allowed to make even technical decisions!
• Smell of politics. The easiest case can be “Our investor was so generous to provide us such a good specialist to manage our project – his daughter. She studied in Harvard!”
• No business plan. Product manager does not know how they would see the product.
• Ask what is the average time of been in the project for the developer. And look how they lie to you. Sometimes it can be even less than 2 months (for very hardcore projects).
• There is no one to protect team from “business guys”. I even saw teams where business guys (not product owners) gave the tasks directly to the developers (even no team leader).
• “Be tolerate to the code created by the other developers” as the requirements. Possibly it’s very difficult to stay calm when you see the code created by their developers.