As any developer will attest, most software projects have a tendency to take longer than originally expected.
The common joke that the last 10% takes 90% of the time, but the reality isn’t that far off the mark. What starts as a small a 2 day user interface feature in Javascript can balloon into 2 weeks. A Unity game written in C# that is meant to take 4 months takes over a year, and so on. A CRM implementation shipping 2 years late. At the comically extreme end, a document creation software famously shipped over 50 years late (incredible but true)
Why does this happen?
There are a number of reasons which can be summarized down to two general cases.
- Spec is good but underestimated the workload vs the resources
In this case the requirements is not the problem, but the understanding of the work needed vs the people available is off the mark – leading to an underestimation of the time involved. This often happens with junior engineers or product managers who don’t anticipate the time needed to handle corner cases, scaling, redundancy and usability and of course debug the issues that will come up.
- Spec changes and development cycles are wasted
In the second case, the team and resources are in place but the spec for the software ends up changing over time, leading to significant wastage and delays.
In a large-scale study, more than 80% of developers admitted they spend half or more of their time on reworks, translating to time taken blowing up to 2-3 times or more the actual work needed.
What causes the spec to change? In custom client projects this is often due to insufficient documentation and scope creep.
However in startups or other new software projects, the most common reason for delays and reworks is a lack of understanding of the real customer needs.
This is unavoidable but can be greatly reduced through customer development and getting real product and needs feedback early on in the process.
Finding out what the user really needs, faster
Let’s take a typical example.
A company comes up with a new piece of software, let’s say a social restaurant recommendation app. They conceive it, design and develop it and put it into the app store. Weeks or months later they only have a few hundred downloads, tepid usage and a handful of ratings or reviews: the app hasn’t taken off. Why?
At that point, the developer doesn’t have much learning to make the app better (or conclude it’s not ever going to be successful). They don’t have actionable mobile-user feedback nor customer contact details they can contact to find out why. Perhaps they tried a survey monkey form or alternative with some alpha users, which no one filled out.
polljoy offers an alternative, by letting iOS and Android app and Unity game developers find out instantly what the users are thinking, and their feedback on your product through embedded surveys. These in-app polls are native, and with a mobile-first user experience.
This way, the restaurant app can find out why their users needs are not being met, and indeed what they were looking for in the first place.
Cutting down the time
With faster learning and feedback, the iteration cycle can be both faster and more accurate, which translates into far less work into features that don’t hit the customer needs.
Less wasted work means faster projects and saving time on coding – which every developer wants to achieve.
