At Inverted Software we get many requests from customers that invested in projects, but didn’t get the results they have hoped for.
Maybe your project is running late, over budget or maybe it doesn’t meet your quality expectations and is riddled with bugs.
In any case, if you feel something needs to be done in order to bring your product back on track and into the market, keep reading on.
The cost of a failed project
Last week a personal friend of mine, called me for advice. I invited him over to my house to see how I can help.
He has spent over a quarter of a million dollars in the span of the last two years on a new website, which is designed to bring together companies from a specific industry.
“I can’t go live with my system Gal, because it seems half done. Most of the functionality doesn’t work and the things that do work are buggy.
What’s even worst is that when the team fixes a bug, they create two new bugs in the process.
A quarter of a million dollars is a lot of money for me. I don’t know what to do.
Should I put good money after bad? Should I cut my losses? Help! “.
Hiring a development company along with a team of developers, he was proudly telling me how he only pays an X amount of money per hour for a developer.
If they are so cheap, I asked, how did you manage to spend so much money and get an unusable product in return?
He did not have an answer, but, I think that at that moment, he learned a valuable lesson.
Analyzing the reasons for the project’s state
The reasons for a failed project can always be traced down by simply asking why:
Why did it fail?
The team could not deliver on time.
Why did the team could not deliver on time?
They had too many bugs.
Why did they have too many bugs?
The code was not architected correctly.
Why was the code not architected correctly?
The development company was trying to submit the cheapest bid.
And so on.
Once we are able to get to the root of the issue and answer “why” we can begin trying to fix the process.
Knowing when to shift direction
ALM (Application Lifecycle Management) is a process in which writing the software plays a small part.
Looking into every aspect of the lifecycle can give us a good indication whether a shift or a correction is needed and to the size of the correction.
For example: looking at a burn rate chart can give is a good indication to the performance of each developer, the amount of lines of code they wrote along with the amount of bugs they fixed.
If the amount of new bugs created exceeds 20 percent of the bugs they fixed, this could indicate an issue with the code.
Another example is the PRD (Project Requirement Documents): If a PRD has a long list of changes that is spanning well into the development cycle, developers may have back tracked into existing code in order to change it, which in turn, created delays.
So when do we shift?
When do we decide to end the current development?
Maybe salvage some components and shelve the rest or maybe perform a complete rewrite?
Code and requirements review
The first step is a gap analysis between where we are and where we need to be.
At inverted Software we perform a thorough review of the requirements, then we code review the entire code base.
We evaluate how the code satisfies the current requirements, standard coding patterns and the overall state of the system.
After our evaluation, we usually come back with two types of recommendations:
Salvage vs throw away
In a salvage project, we continue the course of existing development while we modify parts of the system to be more modular and flexible, eliminating the parts that are the biggest bugs’ producers and pain points along with performing a parallel “touch up” of the base architecture in order to stabilize it.
We make sure to patch up any systems that need it and we try to bring the product to market as soon as possible and with the understanding that the majority of the budget was already spent on the original development team.
If the code is in such a state that we cannot continue the current development we might recommend salvaging it.
In a Salvage project, we save the parts of the project that are salvageable.
This can be parts of the UI, Database or some of the business logic.
Parts that are isolated from the rest of the system and that can be reused in a rewrite.
Saving those parts can save us time as we incorporate them into a new system.
The rewrite will take place only when we established the mistakes of the old system and devised plan to avoid them.
A rewrite will often include heavy involvement from the customer as after all, they would like to see the project succeed.
Back on Track: Goals and timelines
When putting a project back on track, we need to factor in the unknown.
Digging into the code of a poor quality system, requires a margin of error and performing “surgery” on a “sick” codebase is delicate work.
Aggressive timelines might yield another poor quality product.
We find the balance between cost and quality and our architects and developers stabilize the system in order for development to continue.
If your project is of a need of a rescue, Inverted Software will be happy to evaluate it and see how we can put it back on track.
Contact us at: