Find the right speed of software development

There are many important considerations when you’re starting a software project in your company:
* Cost
* Features and Functionality
* Stakeholders
* User Needs
* Launch Date

But one underrated aspect of a software project is finding the right pace of work. Go too fast, and you run the risk of shoddy code and incomplete requirements-gathering. Go too slow, and you will fail to recognize ROI from the project in a way that truly benefits your company.

Source

The speed of development matters. To help see why, just think about it in terms traveling on the highway.

If you’re going 105 miles per hour, you’re in danger of an accident or a massive speeding ticket or another major issue, because you don’t have time to react if there’s a problem. Most of all, you could create a massive accident with wide-reaching impact.

If you’re going 35 miles per hour, you won’t get where you’re going anytime soon, and even more, you may be keeping other travelers from efficiently navigating what they need to do. Most of all, you could create a massive accident with wide-reaching impact.

Software development works in a similar way. Moving too fast can cause you to miss key details and end up in a messy accident. Going too slow can clog up not only your project but other parts of your business as well, and can also end up in a messy accident.

As on the highway, there is a sweet spot when it comes to speed of software development. On the interstate, this is likely at or slightly above the speed limit. (If you’re a highway patrolman reading this, I meant at the speed limit, not above.)

Likewise, there is a right speed for software development. And we want to help you find it. So let’s talk about what it looks like to go different speeds in your business application projects, and why you should find the ideal speed.

MOVING TOO FAST

Moving too fast is rarely a developer’s default. Instead, it’s often driven by a commitment to an impossible timeline. This may happen when a software development company is trying to win business, or it may happen when company leadership makes a deadline decree that is not based on the realities of the scope of work to be completed.

No matter the cause, here are some damaging effects of moving too fast:
1. You start building software before you know the requirements, resulting in costly missteps and reworks. The attempt at speed will actually end up slowing you down in the long run.
2. You don’t take time to test your code and launch a buggy product. In other words, you meet your delivery date, but at the cost of quality. Then you spend weeks or months making fixes and trying to win back users—when a bit of extra time on the front end would have saved you a ton of headaches.
3. You release software in chunks that aren’t viable. As a result, your system doesn’t make sense to users, or doesn’t provide enough value, and users leave in droves. Then you have to spend time and money getting people to try your app again—when a good experience from the beginning would have increased user buy-in.
4. You ignore user experience in favor of functionality, and launch a product that works but is frustrating to use. Again, this causes users to leave, and forces you to invest in winning them back.
5. You assign multiple developers to a project, hoping to accelerate progress. Instead, you end up with mismatched system because of different visions of the different team members.

MOVING TOO SLOW

Moving too slow may be caused by a lack of resources, whether it’s CapEx budget line items or internal developers. It can also be caused by a lack of focus or by a lack of a plan. If developers have to figure things out as they go along, or if they end up chasing rabbit trails that end up with significant chunks of rework, you will end up moving at a pace even a snail would mock.

Here are some effects of moving too slow:
1. Your release cycle is so slow that the business changes around you, making the features you release obsolete before anyone can actually use them.
2. You experience turnover during the project, whether out of normal attrition or out of developer frustration about accomplishing so little at work. That forces you to take more time getting new developers onboard, resulting in further delays.
3. You spend significant money before going live, meaning you have a long lag time before starting to realize any ROI.
4. New technology is released during your development cycle, leading to significant rework or an out-of-date user experience by the time you release your project. Think of slow development cycles during the rise of mobile devices, for example, and imagine how wearables and virtual reality and other innovations could drastically affect your current project.
5. The longer things take, the more things stakeholders try to tack onto the project, leading to scope creep that drives up costs and slows things down even more.

THE RIGHT PACE

The right pace of software should be:
* Sustainable, both in terms of developer workload and stakeholder testing
* Appropriately aggressive, so that momentum builds instead of wanes
* Designed to meet business goals, not arbitrary deadlines

Basically, we have found the right pace to be the speed that allows delivery at the earliest realistic moment. It is a pace that is urgent but not hectic.

So what does this look like in the real world? Let’s give you some examples from our experience at Worthwhile.

At Worthwhile we seek to move from concept to clarity in six weeks. This timetable helps us maintain an appropriate level of urgency needed to answer questions efficiently and then get a project underway.

Likewise, we typically try to size project releases so they can be accomplished within 3-6 months of development. Our most successful projects run at this speed. There a few reasons for this:
1. This allows us to keep 2-3 developers working on a project. Keeping the project team compact makes it easier to ensure that everyone is on the same page strategically and in terms of best practices.
2. This allows our clients to test everything well, and to understand exactly what they’re getting. At a bigger size, it’s easier for things to be missed, which can lead to unpleasant surprises down the road.
3. Generally, our clients don’t make major strategic pivots in their business within a quarter or two. So being able to complete projects in 6 months or less means that the software we build is far more likely to deliver business value as planned.

Of course, some clients need bigger projects. But in these cases, we still try to time releases of sections within this 3-6 month window, so we can keep a good pace and show stakeholders and users real progress.

IN CONCLUSION

Don’t determine the speed of your project by an arbitrary delivery date, whether that date is penciled on the calendar by an exec or determined out of an abundance of caution.

If your delivery date has a reason, then build your project plan toward that date. But otherwise, design your project plan to allow you to find the right speed of development.

That will give your company the best chance to end up with software that is strategic, well-tested, and ready to deliver ROI for your business.

About Worthwhile Storyteller

We'll never tell you a lie, but we might tell you a success story that protects the intellectual property of our clients and partners. Our Worthwhile Storyteller is an amalgamation of all of our thoughts, experience, and expertise brought together to give you the facts about our relentless improvement in the software development space.