To make sure software goals are accomplished the right way, it’s helpful to address what could be going wrong. We’ve helped troubleshoot for a number of clients and in our experience, we’ve seen three primary ways the software delivery process can get roadblocked. Let’s walk through the potential issues and what signs to look out for, so you can achieve software success, sooner.
One of the biggest mistakes we see is over-engineering. This typically happens when a younger or less experienced developer creates too much code while trying to reach the goal.
Essentially, this newer developer is like a kid building a treehouse with 1,000 boards and a plethora of nails. Realistically, that many boards are unnecessary. An experienced framer can create the same treehouse with a fraction of the boards and materials – and in less time.
The software delivery process is no different. An experienced developer can use less code and hours to sculpt a higher quality (and easier to maintain) end product.
Another common mistake is judging and selecting a team based solely on the hourly rate. One developer or team may charge $30 an hour, but this does not mean they are cheaper. Unfortunately, speed and quality are not accounted for in hourly-based pricing.
Even if an hourly rate sounds low, if the project takes hundreds of hours, it’s not going to be cost-effective. An adept, proven developer may sound more expensive up front, but the massive quantity of hours created by low-hourly developers can cost you even more.
Instead of choosing a team based on hourly rate, select a team that will give you flat rate pricing per project. This will give you a better idea of the final price, and often, level of quality.
You may have an in-house team or contractor that discovers the situation has gone over their head. They may not have the right knowledge or experience to tackle the problem, so progress is hindered.
To be candid, someone in this position does not always admit they can’t handle the work. There are a few red flags that someone is drowning in the code – and needs outside help:
If you ask what the problem is and hear a response like, “You wouldn’t understand” or “It’s too technical to explain,” take note. This is a likely sign things have gone up and over their head, and they don’t know how to explain it themselves. As Albert Einstein said, “If you can’t explain it simply, you don’t understand it well enough.”
A developer who understands the problem and solution will be able to make measurable progress in a reasonable amount of time. If you continually aren’t seeing progress, it could indicate that the developer doesn’t know what to do.
We recommend asking this specific question: “How would you feel if we had a third party come in and do a code review?” The response and openness to seeking help may be telling of how your current developer or team feels about their own work.
Some developers may feel threatened by an external team coming on to pick up the slack. That’s why it’s important to reassure your team that a third party would be there to complement and assist in the software delivery process, rather than expose any shortcomings.
If the signals above sound all too familiar, find out if getting outside help with a third party review is the right fit. To get started, book a complimentary consultation with us today.