This is a series of articles which discuss about the situation where a developer can find himself in his work. The earlier topic on work issue is:
Introduction
There are numerous articles and “soft Skill” literature which help a developer to excel in his or her career. They talk about numerous practical and sometimes unreal steps, which would help in the career. Those are perfect guide but it is with an assumption that the developer needs to move compared to his peers or else he is one of the nameless faces in the crowd. They teach how to be the cream of the lot and stand out from rest.
But there are few situations where the developer has already dug himself in a deep hole in a project and just needs to come out unscathed before he can think about excelling in his career. This article is going to deal with the concept of “How to survive” so as to bring oneselves to a level playing field.
I will be taking up few real life scenarios I have seen and experienced to elaborate, how each person can come out and what is the lesson learnt.
Background
I started my career 15 years back and have seen many ups and downs. I have met extraordinary individuals to really clueless ones. Both instances gave a valuable lesson on how to handle myself in a dynamic industry. There have been numerous instances where careers have been destroyed because people were not able to come out of the hole they dig themselves.
The “stories” mentioned are inspired from true events but have been sanitized as well.
What is Project Deep Hole?
Anyone who has worked on a complex project or any other work would easily recognize the “deep hole”. He may call it with some other more “suitable” names but the bottom line (no pun intended) is that it is that stage of the project where we don’t see any solution or a deadline or a path to recovery. It seems like the project is going in circles and nobody knows how to move up or heck to any direction at all. The whole team looks for some divine help or someone to guide the project towards some decency. In few instances, the whole project is scrapped or someone is fired or a dire consequence befalls on the individual person.
Deep hole is not a rare event and it’s actually very common in many projects. But there is one concept I would like to point out. The “deep hole” or abyss for any project consists of 3 stages. They are:
- Path into deep hole
- Deep hole
- Recovery from deep hole
In general, people don’t distinguish themselves in the above stages. For them, it’s just a big deep hell hole. But I would like to distinguish each stage and explain a bit about the same. During fire-fighting, everyone is in hypermode and this tends to escalate the problem further. So we should really try to take a few simple but important steps to recover.
Path into Deep Hole
In reality, all projects get into roadblocks and each of those instances have the potential to get into a downward spiral. It’s the various check and balance and of course the capability of individual concerned which prevents it from becoming a disaster.
Never lie to others and to yourself.
We were working on a telecom billing system which consists of 3 modules: the core engine, user Interface and database module. The “engine” was the main brain of the software which did the calculation based on the input from the UI. “Engine” was an algorithm sans any validation of inputs values. Meaning, it was the job of UI to validate the input from users. The “engine” assumption was that the data it received was correct and valid and in bound. During our regular weekly meeting, each developer was supposed to give his status. The UI developer always presented an inflated status saying his task is on schedule or completed. Unfortunately, he was lying hoping he can catch up with the slack later. So eventually, his lies got caught during the first partial roll out of the software and the whole project was a disaster and went into abyss.
His sloppy reporting may have been for any number of reasons aka new technology, fear of ridicule or plain laziness to do work. If he had been truthful from day one, then he would have got help from others or better guidance. He was deceiving himself that he could complete the task in time. It doesn't make sense to give an incorrect status to the peer and upper management. It may look prudent in the short run but nothing good comes from it.
Look beyond your module
Developers are generally smart people and can solve complex issues, but sometimes they are tunnel visioned. It always makes sense to see what’s happening in the overall project and not just concentrate in his module alone. It is always useful if the technical person has an outside view who can figure out an impeding issue before it blows up in our face.
In the same project mentioned above, many developers worked on the “engine” part. One of the requirements was the use of “String” data type. Whether it was NULL terminated or not was not mentioned. As it happens, some of them assumed it as “NULL” terminated and worked with that data type. It was just discovered in time when the UI developer (replaced one) pointed out the folly after reading the report from one of the earlier Peer reviews out of his curiosity. The team had enough time to rework on the new algorithm and saved some valuable time.
One problem with us as developers is that we treat our work as our personal domain and do not like others to look into it. There are pros and cons with this approach but I personally feel, a second set of eyes never hurt very much.
Deep Hole
Whatever efforts we take, there may be few cases where the project really falls into a hell hole. This is the situation where everyone is on their seats' edge and has a nervous look. The normal process of the software development goes out of the window and people just work hard to bring back the project to a level ground. There are few things to consider when you are in the fire-fighting mode.
A day consists of 8-10 hours
During this stage, everybody gives his best to recover the project. The management throws out the regular deadline/milestone and comes with shorter goals and targets. All the issues plaguing the project are listed out and asked for new deadline. A word of caution to all developers, this is the situation where they have extra sets of eyes watching over them and they are under tremendous pressure to deliver and shine. So with that in mind, they give an estimate assuming they are going to work 24 hours a day which is physically impossible. If the task needs 20 hours, please be realistic and say the same in clear words that it would take at least 2 days to finish it because you are assuming 1 day as 10 hours. Round the clock coding works if it lasts for a day or you are near the solution. In reality, a developer has to work for days or weeks to recover the project. It would be physically impossible to work like 20-22 hours a day for weeks. It would lead to a burn out. Always assume you are running a marathon and do the sprint only when you can see the finish line.
Estimation in days vs hours.
As mentioned before, during crisis, couple extra management come into the party and monitor the situation. When they ask what is the time needed to complete “X” task, developers need to determine what unit of times are generally followed in this scenario. A 16 hour long task in reality should be treated as 2 days rather than 1 day (of 24 hours). I had on few occasions said I will complete the task in 2 person days which in reality was 40 hours, but interpretation of 2 person days was wrong between stakeholders. So always make sure all are on the same page with respect to new deadline. I have personally seen where managers come from different schools of thoughts. Some like hours and few like person days and some just want the End date.
My personal choice is always to talk in hours but give the absolute end date as it tends to give a clear picture of effort needed to complete a task and a clear deadline.
The talk
The assumption
The above scenarios happen a lot of times even in regular project discussion but we have enough time to rectify it but during fire-fighting, small details are often missed and lead to further problem.
No shame in asking for help.
In one of the projects involving T-SQL, couple of members left the company in the middle of the critical phase. As an emergency stop gap arrangement, whoever mentioned “SQL” in his job application or profile was put into this project to bring it back to normalcy. A colleague of mine in her profile had written SQL as one of her strengths but in reality she was just a newbie. She kept quiet due to fear of humiliation, but worked hard to learn the tricks. When she was stuck, she did not ask anybody for help and instead told me her frustration. Luckily, I was able to ask one the guys to help her and the story goes on. In my opinion, there is no shame in accepting you are stuck and want help. Fellow colleagues may not be our best friends but they do help in times of need. There is no point in making the project and yourself in bigger hole when already water is above the head.
Recovery from Deep Hole
This is the time where everyone has put in his best efforts and brought the project back into the recovery mode. People could see the progress and realize they are inching towards normalcy. It’s a much better place than being in a developmental hell. The mood is more positive and people start thinking how to move accelerate towards normalcy. This is also the stage where people start worrying about the aftershocks of project disaster. Some people have to face the consequences and that’s the nature of the beast. But couple of steps can be taken to make this as fruitful as possible and reduce further heartburn.
Relax but don't slack.
This is not the time to slack off and lose focus on the task in hand. The project is not yet out of the woods and this is the worst moment to slack. The positive energy and the effort should snowball into a faster recovery rather going back and losing the goodwill. One of the main reasons for slacking is sometimes burn out and that's the reason developer has to decide this development deep hole is a marathon or a sprint.
I have seen many instances where project goes in cyclic motion of recovery and resets due to lack of focus.
No finger pointing just focusing on lesson Learnt.
Everyone has to remember that the project is not yet completed and need to maintain the decorum in the team. There is no point of finger pointing on others for failure or any mishaps. As the famous saying goes:
Quote:
Praise in public and criticize in private
always make sure you don’t make any accusation in public. The aim is to list out what went wrong and how to learn from the past mistake, so that project doesn’t go into downward spiral again. You don’t want to risk mass exodus of people from the project due to hostile attitude from “Genius” developer.
Conclusion and a Word of Caution
The above discussion is nothing new and it should be followed in all scenarios. But in normal development stages, there are enough checks to take care of any mishaps. During project deep hole, developers tend to do the task in hypermode and miss some basic but obvious development steps. It's also true that normal SDLC works during developmental deep hole in an established organization. In many medium to small enterprises, we are forced to work "on the fly" to resolve the issues.
History
- July 13, 2015 - First publication
