What Vampires Can Tell Us About The Success of a Software Project

To Rescue, or Not to Rescue, That is the Question (Photo by Kyle Anderson on Unsplash)

In life, also the business one, many things collide. Art, philosophy, craft, psychology, experience, passion, risk, and reward. It so happens that when it comes to rescuing software projects, all of the above collide at once.

Let me explain the struggle many project owners and stakeholders often face in their product’s life-cycle through the lens of philosophy and a brilliant thought experiment called the vampire problem.

This intellectual exercise wonderfully spreads to other areas, such as rescuing failed software projects and if you bear with me until the end of this article, you’ll be able to assess what you would do once at crossroads with your software project. Or whether you’d transition yourself into a vampire or not.

The Vampire Problem

Imagine that you have the chance to become a vampire. With one swift, painless bite, you’ll be permanently transformed into an elegant and fabulous creature of the night. As a member of the undead, your life will be completely different. You’ll experience a range of intense, revelatory new sense experiences, you’ll gain immortal strength, speed and power, and you’ll look fantastic in everything you wear. You’ll also need to drink blood and avoid sunlight.

Starts L.A. Paul her thought-provoking book titled “Transformative Experience”.

Let’s go deeper into this.

Suppose that all of your friends, people whose interests, views and lives were similar to yours, have already decided to become vampires. And all of them tell you that they love it. They describe their new lives with unbridled enthusiasm, and encourage you to become a vampire too. They assuage your fears and explain that modern vampires don’t kill humans; they drink the blood of cows and chickens. They say things like: “I’d never go back, even if I could. Life has meaning and a sense of purpose now that it never had when I was human. I understand Reality in a way I just couldn’t before. It’s amazing. But I can’t really explain it to you, a mere human—you have to be a vampire to know what it’s like. Suppose that you also know that if you pass up this opportunity, you’ll never have another chance.

Would you do it? Would you become a vampire in the hopes that the life of a bloodsucking, two-legged bat is somehow better than the one you live? Would you willingly abandon everything you are and stand for? Change your habits, daily schedules, diet? Leave the comfort zone of the known for the unknown, no matter how tempting?

To make a choice like this, you’d want to make the best decision you could. And that means you’d want to proceed as rationally as possible. Becoming a vampire would be big—really big. It obviously isn’t a decision to be undertaken lightly. You’d want to choose the smartest option, the option that would make your life as good as it could be after you’d made your choice. You wouldn’t want to pass up one of the most amazing experiences you could ever have. But you wouldn’t want to make a huge mistake either.

Explains L.A. Paul.

But here comes the kicker.

The trouble is, in this situation, how could you possibly make an informed choice? For, after all, you cannot know what it is like to be a vampire until you are one. And if you can’t know what it’s like to be a vampire without becoming one, you can’t compare the character of the lived experience of what it is like to be you, right now, a mere human, to the character of the lived experience of what it would be like to be a vampire. This means that, if you want to make this choice by considering what you want your lived experience to be like in the future, you can’t do it rationally.

Vampire Paradox in the Software Realm

Now, forget about the whole vampire thing for a minute and pretend to be a project owner, a CTO, a CEO of a startup, or anybody who is a stakeholder of a software that is at a crossroads (unless you really are one).

You may be facing a rapidly approaching runway. Maybe there’s a technological debt stacking furiously, making the project no longer scalable (at least without an effort, resources or funding, and surely not fast enough). Perhaps you’ve already launched but the market said violently “We don’t want your product, it sucks”. But there’s a light in the tunnel so buckle up and don’t give up just yet.

You, as a business, may still transform. Not into a vampire, hopefully, but into a profitable endeavour. No guarantee, though. It will still be a risk just like it always has been. But this time it will be an informed risk, if taken into the account all the pieces you have on the table, learnings from previous failures, adjusted market reality, and humbled mindset.

In other words, this time will be heavily de-risked. But in order for this to work out you must assure the transformation to be as smooth as possible, and as informed as achievable. How do you do this?

  1. Sound the alarm: Acknowledge that the project is in trouble and communicate the situation to all stakeholders.
  2. Analyze the problem: Identify the root cause of the problem and determine what needs to be done to fix it.
  3. Restructure the team: Reorganize the team to address the issues that led to the project’s failure. This may involve bringing in new team members or reassigning roles and responsibilities. Sometimes this means hiring an external team of experts.
  4. Redefine project goals: Revisit the project goals and adjust them as needed to reflect the current situation.
  5. Assess the current state of the project: Evaluate the project’s progress and determine what work has been completed and what still needs to be done.
  6. Prioritize fixes: Determine which issues need to be addressed first and focus on those.
  7. Consult: Seek advice from experts or other professionals who have experience in rescuing failing projects.
  8. Validate the remaining project: Determine whether the remaining work is still feasible and whether it aligns with the organization’s goals as well as resources or deadlines.
  9. Reconsider technology choices: Evaluate whether the technology choices made for the project are still appropriate and whether they need to be updated.
  10. Keep building trust: Maintain open communication with all stakeholders and build trust by delivering on commitments.

Even if you can pull off all of this, the end result remains unknown. You may still fail and be unhappy with who you became as a business or a product. Or you might be better off than ever before.

Just as would be the case with a vampire. So, would you still do it? Would you go through all that trouble not knowing what the world will look like once you are done transforming?

There is one slight difference in all this, when comparing it to the vampire problem. Firstly, your life most probably doesn’t end with a failed project. Your job may, along with some of your hopes and dreams. But not your life so there’s that small window you may use to go back to where you were and start over with new knowledge and self-awareness.

There’s also another difference. Remember when all your vampire friends were telling you how great it is to be a vampire? When it comes to rescuing failing software projects there are no other vampires. Nobody is on the other side waiting for you and luring you into a potential trap. Nobody is in your future shoes.

There are, however, agencies such as ours, that can help you strategize and consult on the transition so that it truly is an informed one. This is a real de-risking allowing for a softer landing, even if the journey ahead appears bumpy at first.

So, again, would you turn your failing project into a successful one without the knowledge of the outcome? I’ll tell you why I would and then never look back again. If you as much as considered a transformation in the first place, it most probably means that you weren’t happy with where you were and needed to change things.

That’s the human factor if you need one. From a business perspective, however, you could either act and do everything in your power to fix things, to make them better and to adjust or, quite contrary, passively observe the imminent demise of what once was a great idea. If you did nothing and watched that brain-child of yours die with no attempt to save it, how would that feel? Personally, it would be haunting me for years.

And for that matter, if nothing else, I’d go all-in on a rescue mission to save what’s left of that project. Who knows, maybe it would turn into a toothless, wine drinking vampire (I think I actually know the guy).

That’s the beauty of it, we simply don’t know the outcome and how it would make us feel. This uncertainty is what is supposed to drive us. It may feel counterintuitive but has been proven time after time. As Emerson realised:

People wish to be settled; only as far as they are unsettled is there any hope for them.

Rescuing failing software projects

Thankfully rescuing failing software projects is a lot more tamed. There are things that are common to most other projects of this sort, hence some best practices do exist, ensuring that rescue missions draw from experience rather than guessing. They emerge from battle-proven approaches, strategies and tactics. To give you an idea how manageable that process can be, at mente.io, we approach this in the following manner:

Step 1: Interview & Analysis

A. In-depth interview with the client (mostly a senior stakeholder like Founder, CEO, Product Manager, Product Owner along with their CTO). During this step we try to find out as much as possible from the client and project’s history, following certain, proven business logic:

  1. Initial business and technical goals; the level of their achievement at the time of the conversation,
  2. The project’s progress, achievements, ownership and constraints from a business and technical perspective:
  • The client’s business team – who and how manages the product or the project,
  • The client’s technical team involved in the project (internal or from another supplier), their technical competencies such as knowledge of specific technologies, operational competencies such as software development processes (e.g., level of implementation of CI/CD processes, etc.),
  • The technology used and why it was chosen, how it performs, etc.,
  • Known software issues (e.g., slow performance, crashes, etc.) and team-related issues (such as failure to deliver business-expected features on time, poor communication, low availability, failure to meet deadlines, appearing disengaged or demotivated, etc.),
  • Known project risks (e.g., limited budget, competition, internal risks such as disengaged management, etc.)

B. Current goals (e.g., meeting the market launch deadline, obligations towards investors or pre-sale customers, etc.),

C. Limitations (e.g., time constraints – two months to market launch, budgetary constraints (i.e. 2/3 of the budget already spent on the project),

D. What the client’s team has done so far internally to address the challenges and with what results,

E. Other stakeholders involved, such as investors, other suppliers (whose satisfaction needs to be ensured),

F. Everything else that may play a huge role such as the business model, specific solutions that quickly come to mind, which may have been considered – if so, whether they were implemented, why not, etc.

Step 2: Presenting possibilities

  1. We prepare an offer for an audit of the situation based on the provided software, data from monitoring tools (if connected) and based on the interview and analysis.
  2. The result of an audit will eventually come in a form of a report that usually contains:
  • The overall summary of the existing situation,
  • Identifying perceived risks,
  • The most visible problems and their implications,
  • Possible recommended approaches with different levels of priority along with their consequences, time required for implementation, cost (not providing an exact estimate, but a magnitude comparison of the costs of different solutions).

Depending on the project size, the analysis takes 1-2 working weeks, sometimes less for smaller projects, although they can be very complicated.

3. We discuss the offer with the client and often fine-tune it based on new information (often a critical moment).

Step 3: Conducting the audit and preparing the report

After obtaining access to the client’s code, repository, systems and interacting with the client’s team, we examine everything thoroughly, looking for opportunities and dangers. Once the audit is conducted, we prepare a report and discuss it with the client.

Step 4: Planning and contract sign off

The client usually realises that they cannot handle the challenges outlined in the report on their own and with the current team’s limitations. We determine what they can do themselves and what they cannot. We prepare an offer for implementing a rescue project, specifying:

  1. Project goals,
  2. The scope of the involvement (client’s vs. ours),
  3. Billing model.


  1. We sign the agreement,
  2. Plan the scope of work,
  3. Set up a project management system such as Jira (ours or the client’s)
  4. Project’s kick-off.

Step 5: Rescue mission

The actions we take during a rescue mission include, among others:

  1. Deepening project knowledge through team discussions, documentation analysis, and software analysis,
  2. Reviewing and designing new system architectures (e.g., from monolith to microservices),
  3. Code repair, writing new code,
  4. Patching various vulnerabilities,
  5. Implementing/improving CI/CD processes,
  6. Optimising infrastructure (clients often don’t see how money slips away),
  7. Mentoring often young or otherwise long-established teams,
  8. Bringing in new competencies,
  9. Consulting with Founders, PM, CTO, etc. (education and mentoring at every business-technical level),
  10. We strive to solve pressing problems, deliver tangible results.

At this stage, we strive to solve urgent problems and deliver tangible results (such as infrastructure optimization, missing features, etc.). All of this is done in close collaboration with the client, which is a prerequisite for starting (key stakeholders must be available, and all system access is essential). We continuously review the level of achievement of the client’s goals, sometimes modifying them during the process (hello, flexibility).

Psychologically, we gradually build trust among decision-makers and the team, who initially may be reluctant to share knowledge or disclose information due to fear of layoffs. However, over time, they recognize our good intentions (we don’t want anyone to be fired – we rather help them maintain their jobs), how willingly we share knowledge, and how we invest attention in these individuals and their problems. As a result, they begin to trust us. This builds their new commitment, and sometimes entirely new energy emerges to achieve the goal together.


Closing in, I’ll gladly give voice to L.A. Paul once again as she so perfectly summarises her own vampire paradox, shedding a light on her personal preference, too.

In many ways, large and small, as we live our lives, we find ourselves confronted with a brute fact about how little we can know about our futures, just when it is most important to us that we do know. For many big life choices, we only learn what we need to know after we’ve done it, and we change ourselves in the process of doing it. I’ll argue that, in the end, the best response to this situation is to choose based on whether we want to discover who we’ll become.

The question should be, then, not whether to transform or not but rather, “Hey mente, when can you start your rescue mission and how much will it cost us”.

Recommended reading & sources:

You might also like

Related case studies