Is your project doomed? Maybe, have you seen the following signs...

Even with the most thought through plans of action - projects can still fail. Whether that’s through the ill intent of malicious employees, tired and forlorn middle management or just the enthusiasm of a new project crumbling under the harsh reality of deadlines. It happens. 

Here at Developer Death March we’ve talked to many people who have experienced this calamity and came up with a few tell-tale signs that your project may be going towards the fail side of the force. As a disclaimer, many seasoned developers and managers may know these signs already - may have read about them in books such as the devOps handbook or phoenix project. Having said that, if your eyes are still willing to go through the movements, maybe what we’ve heard and seen below won’t catch you unawares from some missed page you glossed over.

Religion

I’m not talking about Christianity, Buddhism, Yggdrasil or some of the other ancient practices. I’m talking about the holy hammer by which a developer or manager has decided all projects shall be forged. 

This hammer has served the individual for years whether we are just starting a new project or in the middle of one that seems to be lagging behind. Many think the individual a prodigy or savant in this skill and the individual sees that practice almost as an extra limb. Without it, the project would be lost.

Agile, waterfall, python, rust, puppet, AWS…

All of these languages/practices, which “can” help to solve problems can also be a crux. To give a better scenario, let’s look at puppet unit testing. In this scenario, the amount of time it takes to unit test a new puppet module costs the developer, 10–20 minutes the first run (grabbing a vagrant image) and every subsequent run around 2–3 minutes waiting for vagrant to boot up or load the modified unit test. 

Another developer has noticed this and has decided to use docker instead of vagrant which results in around a 1 minute pull time and a few second unit test time. However, the senior on the team has stated that because vagrant is the defacto way to run puppet tests this time savings is inconsequential and do please refrain from doing work in the future without getting the work planned.

This sort of altercation most likely won’t even be noticed by a manager unless mentioned by the chastised individual. However its a very toxic behavior - the ability to adapt to a new process, which clearly improves the turnaround time on everyday tasks is fundamental in improving success across the board.

Solution: Use metrics to determine if an approach is working.

Celebration

For folks doing work or planning work, it is important to take time, as a team and recognize when things are going well. It’s another thing to applaud basic standards of practice or skill over and over throughout a development life-cycle. Not everyone in a team is motivated by celebration, or the need to celebrate milestones within a project. They may only care that production is going to be ready when the project goes live, they really couldn’t be bothered by the web front-end finally working with the back-end database on the development environment. 

These people aren’t going to care about others meeting burn downs if every day they come into a stack full of tickets around errors the application is emitting. In fact, celebrating a broken product going from development into QA or into Stage can sometimes cause the opposite reaction. To them you are celebrating future failure.

Based on interviews at Developer Death March, this experience just isn’t that unique. It comes from the forcing employees of silo’s across multiple teams rather than having cohesive teams that work together on a daily basis. If for example, you’re like Alex P. who works primarily with storage, your litmus for success in a project is seeing proper backups occurring and no file system errors from the pure storage blades you’ve had installed. That email in the middle of the day informing you like a child that MongoDB was setup via chef properly and that we are going out to celebrate just isn’t going to be consequential.

Solution: Save the celebration - instead focus on accolades in daily stand-ups, it will feel more organic coming from people who are around you and can understand/care about what you have working on. 

Being A Detective

Depending on the overall experience level of your team/company, as well as size, being a detective is one of the best skills any individual could have within an organization. To the opposite not having team members with this skill can only be an indication that a project is destined to fail.

As a developer being unable to figure out where in your microservice ecosystem things are failing is bad. As a manager being unable to figure out where the pain points are in your SDLC life cycle is bad. As a CEO being unable to locate where your IT budget has gone, is bad.

Being able to better analyze where failures occur and quickly acting to implement remediation actions are a great way to ensure success as a business/project.

How many people in your organization can read a stack trace? The answer should be greater than 90% from your folks doing the programming. Even better if they can quickly tell you where in the code-base that code is and when it was last deployed. The idea being, that when an issue occurs people can have some grasp on remediation, otherwise only the same few folks in the NOK, SRE or application engineers will have knowledge of how to fix the issue (which may never get fixed).

Solution: Ensure that everyone in a dept. can be their own detective. That doesn’t mean finger-pointing, it means investigating and fixing the issues that are draining the life out of your project.

Communication

From interviews we’ve seen that folks barely communicate the reasons why things are falling apart. They are emailing defensively or using public chat rooms as a way to slam a coworker into a virtual wall. Toxic/overworked people can find an easy venue through communication to find excuses why a project is breaking down. 

People constantly blame communication between departments or between people as the reason they can’t get their job done. But from what we’ve seen is that communication is fine when it’s civil. Communication is fine when we remove emotion and passive implications from it. Communication is fine when its used in a project to call out plans which are actionable.

Solution: Keep communication civil and simple. Not everyone needs to steer the ship but if you see water be able to communicate that effectively without bias. Even if you see a teammate pointing the canon downwards - maybe help them tilt it right-side up.

Self Motivation

It goes without saying that working more than forty hours a week, for most folks, is outside the realm of whats comfortable - especially considering many of us are salary employees. However, some of us have trouble letting the workday end and it’s not unusual to be pouring even more hours out of work into passion projects. 

Where do you draw the line with really motivated people though? Considering some people just seem to work more than others as it comes down to an individuals work ethic. Even if that work ethic puts a strain on themselves and coworkers feelings of inadequacy.

Personally, seeing a fellow worker striving to attain a new skill whether it’s in programming or not - I enjoy seeing them grow outside of work. What gets me is when they take that new talent and try to force it into the project without working with other coworkers to refine or share that talent. Converting a Postgres database into Cassandra may produce some really interesting metrics and may even be beneficial to a project- but if buy in from the team doesn’t occur, then the pureness of the act may be seen as sinister.

I mentioned above do not take religion or current norms of a project into absolute context, i.e. becoming a nonconformist over the course of a project. However being able to take the work of passionate individuals and adopting their passions can be a huge boon. Just make sure its done in a way that allows that person to have some ownership, whether that’s a brown bag lunch or directly taking over a feature of a project that is interesting to the individual.

If I want to spend all Friday night working on an idea that should be allowed. If I want to fall asleep right after I get home that should be allowed too. A code-base or company is the involvement of many peoples passion and lifeblood. It should be just as forgiving to every type of manager, developer or CEO.

TL;DR

Is your project doomed?

1) Are you being too strict and not adapting to changes over the lifespan of the project?

2) Are you over celebrating all the small achievements but none of the bigger hurdles?

3) Can everyone help find problems during the course of a project?

4) Can you communicate with everyone without derailing focus?

5) Are high performers being given outlets to embiggen the group?

Thinking about these questions is a great start to turning the ship around and conquering all the different aspects/personalities in most projects. Or if you can at least provide some mind exercises in which to compare your past projects that you can vent below.

We at Developer Death March exist to hear the war stories of folks in the software industry. Have you experienced any of the above abuses? Have you seen other signs of failing projects? What’s your opinion?

Let us know in the comments