How Do You Know If You Are in a Software Hostage Situation?

A software hostage situation is the term Tizbi coined for an unfortunately common software development roadblock. A hostage situation arises when a technological project stalls as a result of a developer's actions.

This may happen for a variety of reasons, but it is often a result of poor communication and might be a sign that your software engineer is in over their head. 

This can lead to many treacherous outcomes including wasted resources like time and money. It also leads to tension across parties in a company, and lastly, it may lead to your software project never getting finished, forever lost in the purgatory of software ransom.

Avoid getting stuck in this treacherous process if you can, and if you find yourself in trouble already, then don’t lose hope! There is still a way to save your company and your future software.

Perhaps you are experiencing trouble in your software development projects but are unsure whether you are in a software hostage situation yourself. 

To be a software development hostage is to know true frustration in your projects; the symptoms are extreme, and the consequences of allowing the situation to continue are painful.

Here are several signs you might need a rescue team for your software project:

• Constant delays: A software project that is constantly stalled, where progress feels treacherously slow might be in trouble. If a developer repeatedly fails to meet deadlines this is a sign that something is wrong.
• Irresponsible budget allocation - Sometimes it might feel that you continue to invest funds into a software project without any real signs of progress. With a reliable software project, your company should be getting its money’s worth.
• Poor communication - Communication remains one of the most important parts of any project. Your software team should prioritize strong communication, and be able to explain to you in plain terms what is going on in the development side. If communication is lacking, you have a right to become suspicious of the development process.
• Sloppy performance - When you hire an expert you are entitled to a professional working process. Insufficient technical, strategic, and interpersonal skills can result in unfulfilled promises.
• On the job learning - If your software developer seems to be learning on the site, this is a sign that they do not have the adequate skill set to drive your project to completion.
• Misconstruing project scope - After committing to an insufficient budget and schedule the software project might start to feel completely impossible. If a programmer is in over their head they might continue dragging out deadlines and wasting time and money.
• Lack of project leadership - If no one takes ownership of the project then it becomes that much harder to reach project milestones. Having a clear project manager is vital to smooth operations, without one the project is likely to fail.
• Unnecessary secrecy -  When you lack access to the development team and associated data, this is another sign that your programmer might be misleading you.
• Bad integration - Bad integration of components means someone messed up along the way. Likely this is due to a misunderstanding of client requirements by the developer.

Mistakes and miscommunications can happen in any sort of work process, however when the sins and muck ups start to pile up, frustration and resentments also increase — This might lock your development project in a stalemate, manifesting the dreaded software hostage situation.

Software hostage situations occur when a developer negatively impacts the success of a software development project. Often, this is a result of one or more of the “three deadly sins” of software development: laziness, incompetence, and greed.

If your developer commits one of the three deadly sins of software development, you might experience the following symptoms:

Laziness

• Regular failure to provide accurate and detailed updates on a project or task
• Failure to keep up with tasks, resulting in a growing backlog of work that never seems to get done
• Small technical tasks take too long for the developer to complete
• Long delays in development (often with subsequent higher bills) with little or no explanation

Incompetence

• Lack of transparency on what work is actually being done on the project
• Refusal to fix existing bugs in your system; and refusal to accept outside help
• Refusal to update to more modern technologies, even though it is obvious that the new technologies are optimal
• Your system is glitchy, and no amount of work ever seems to fix it correctly
• Resistance to your ideas for the project, and insistence on implementing features that are not important to you or your business

Greed

• Your technical staff is not allowed to see the code or participate in development in any way
• The developer owns the code and refuses to release it to you for review
• Unexpected increase in cost on a project without accounting for expenses or hours
• Consistent denial of accessing your own development environment for use without real reason or explanation
• Demanding more money to work on a new feature, but refusing to provide what has already been completed and paid for

This list of symptoms is neither complete nor exclusive. There are many more ways that a bad developer can negatively impact a company. You must always think critically when asking the question, “Am I in a software hostage situation?” 

Probably the greatest indicator that there may be a problem for you is if upon communicating to the developer that something is not going well, they act offended and refuse to acknowledge the problem. 

Depending on the severity of the issue, and to what extent alternative solutions are available, the developer’s response is a good measure of whether or not you need outside help.

Coming to terms with the fact that you are experiencing a problem in the software development process is not the easiest thing to do. Usually, by the time that company resources and developer hours are heavily invested in the project there is a working relationship between you and the developer.

In custom software development there must be a level of trust that the developer is the expert and that they will be able to complete a project to fit your needs.

It is generally not a comfortable experience to question this relationship and confront the developer, especially when the subject matter is outside of your own expertise.

When your developer refuses to fix problems, adequately explain repeated delays, or provide you access to your own staging environment, there is a good chance that your developer may need outside help to complete your project they way your business needs it, within a reasonable time-frame.

The question at this point is: Do you let the project continue the way it is in hope that things get better, or do you contact outside help to get the project back on track?

Assuming your answer to the question above is that development has stagnated, and things need to change, the next course of action is to assess your options. 

The worst case scenario for you is that your developer or development team was both unqualified and malicious in draining your company’s resources so that as of now:

• Your project is not launched and there are unexplained delays for individual features.
• The project lacks the necessary features and the developer refuses to implement them.
• You do not control development and the developer refuses to give you access to the source code without explanation.
• And your developer increases the budget without a clear explanation and even withholds project releases until they are paid more money.

Not all hostage situations are this dire, and the vast majority of developers that cause hostage situations are not malicious; they merely need outside support to get the job done.

In any case, you will need to set a goal to move your project to a place where progress is possible and you can once again be in control of the development process. 

Your key options are as follows:

• Communication: Solving almost any problem begins with talking to the developer.

  There is always a chance that miscommunications were the source of your problems. Clearing the air might just be the optimal solution for getting things back on track.

  Clearly explain what you like and don’t like, asking all the questions you have as well. Together with the developer, you make a new plan of action to reboot the development process.​ 

• Focus software development: Sometimes the problem with the project occurs when there is a disagreement about what is essential. The solution to such a disagreement is to get a minimum viable product as soon as possible.

  By excluding all of the features that are not necessary to the software at the present moment, you and the developer can focus on putting together a workable product.

  If your current project is blocked because there is a disagreement on what is important, stop adding new features immediately and finish the necessary functionality first. 

• Implement new technologies: Sometimes the issue can be a result of the developer using an incorrect language or library.

  This problem is a little more complex to solve. Your best bet is to talk to someone not related to the project and find out what is out there on the market and what the best practices are for development on projects like yours.

  Oftentimes this option requires reaching out to a different development company or outside developer for a second opinion. In most cases, it is not the best idea to code everything from scratch, but if your project is written in a language that is the software equivalent of an ancient archeological text, it is likely your only option.

  Rewrites are the best way to get rid of old database management systems and ancient languages that are not supported anymore.

• Build a new software team: When at an impasse with your current developer or development team, sometimes there is no cost-effective way to move forward.

  Whether there is a dispute over budget, features, or technologies implemented, you DO have the option to hire a new team. A new development team can offer fresh perspective and be ready to complete a struggling project that the previous developer could not or would not finish.

  If you find out that the technologies originally chosen for your project are out-of-date or ill-fitting for the purpose of the project, find a team that can convert everything to more optimum technologies.

After you decide which option or multiple options you will pursue, plan everything. Follow best practices in development operations (Dev Ops) to bring the project under your control, maximize efficiency, and promote beneficial communication. 

Talk to your project manager and discuss the steps needed to move forward. If you are refocusing the project with the same developer, prioritize development into phases. Everyone should know the start/end dates for each job and understand what features and functionality each release should contain. 

Along with your project manager, assign a responsible person for each job, stage, and phase. If you or your developer do not have an issue tracking system, seriously consider investing in one. They allow you to track progress and see all up-to-date info about the project, including what work was done during which time period.

When you have a plan, record it and stick to it.

If your plan is not recorded, the project is more likely to revert to the methods and behaviors that led to the software hostage situation in the first place. Life is not perfect, and almost every step will require minor readjustments; however, your plan should give you the framework you need to manage what is expected with every major release. 

Remember that small changes are acceptable to get the project moving again and dig yourself out of the software hostage situation.

When your plan is recorded, it is a good time to write a specification that will contain all of the details about the project. If you already have a good spec, make sure that your plan reflects the details accurately so there is no confusion or dispute later. 

One of the most important purposes of the spec outside of defining the features of the end product, is to manage everyone’s expectations and get everyone on the same page from the onset.

If you need to write a new spec for your development project, try to find someone with technical experience. It is appropriate to involve the developer or an outside consultant. 

Regardless of who writes the spec, the final step is to make sure that you and the developer agree on it before continuing with development.

If you decide that a change in developer is the best way to move forward, choose a developer that is qualified to do the job. 

It sounds like an obvious distinction to make, but developers usually have specializations as to which technologies and features they work with. A senior developer in one technology might not know anything about another technology. Be diligent in asking about the credentials of your new team.

Furthermore, it is important to make sure that every member of your team understands the project’s goal, your priorities, and the value of their input on the project. 

If every detail is clear to all parties working on the project, including yourself, a software hostage situation moving forward will be nigh impossible.

By being involved in the development of your project, and by following the above methods for communicating and delegating to capable team members, you automatically exclude software hostage situations that could arise from misunderstandings or miscommunication. 

Once your project is lifted from stagnation and there is once again visible progress toward completion, remember to maintain good practices in Dev Ops to prevent backsliding into bad habits. 

The most important aspects of development for you to uphold moving forward are good communication, a steady development pace, and control of the project.

If you have found yourself in a software hostage situation, desperate for some relief, but with no idea how to proceed, do not sweat it. Tizbi is a trusted and experienced software development partner, and we offer several approaches to help get your project moving again.

Tizbi’s Project Rescue Teams can offer help at various stages of your software development process:

• Consultancy – If you require a second opinion for the troubles you are experiencing in your software development project, you can speak with a Tizbi software development expert to get the right advice.
• Taking Over – If you are ready to turn over a new leaf and pass the reigns over to a different developer, than you can count on the Tizbi teams to provide a professional and open software development process.
• Salvage Existing Code – Our experts can approach the current project and work in tandem with your existing developers to try and salvage the code and put the development process back on track.

Get in contact with Tizbi experts today to figure out the best course of action for your company and stalled software development project.