in Development

Don’t Blame the Devs: What If Your Process Is What’s Flawed?


Product development delays are huge talk in the programming community. They are the subject of intense academic papers and a cornerstone content topic for development blogs. Everyone wants to know—why does it take so long to build software? Why is it so hard to stick to a timetable? And in their haste to assign blame for missed deadlines, clients often look to the developers who are building the product code. After all, that’s commonly the area that clients least understand—and we’re all programmed to suspect what we don’t understand.

But stop for a moment and consider—what if it’s not actually your developers who are causing product delays? Let’s take a look at other common culprits that may be contributing to delays in your product’s development cycle:

Unclear Goals

Any programmer will tell you that the development of every product starts with a goal. There is a target audience, a need prevalent to that target audience, and a reason for that need. The company defines their goals using this simple Mad Lib:

“I’m a ______, and I want _______ so that I can ______.”

That’s it. That’s goal setting for software clients in its most basic form. Fill in the blanks, both for your overall product and for every feature that you want your overall product to include. Sounds easy, doesn’t it? Yet, you would be shocked by how many clients aren’t able to define the goals or requirements of the product they want to build.

For the coders you’ve hired, starting a project without set requirements is a lot like starting a road trip without a map or even a destination in mind. It’s like you’ve told them “Let’s go to California! Or, maybe Florida,” and expected them to start moving. They can drive if you really want them to, but they’re probably not going to get where you want to go.

Here’s a harsh truth: it’s not your developers’ job to decide what your product should be. That’s your job. Until you do your job, your developers can’t do theirs, and production will be stalled.

Changing Requirements

Despite their lack of clear goals in place, eager clients frequently seem to believe the myth that the sooner they get started, the better. So they haphazardly set preliminary requirements, fully expecting to make changes as they better determine their product goals later on.

Unfortunately for those clients, product development isn’t a “figure it out as we go” kind of sport. If you set your requirements and then change them, you can’t expect to maintain the original timetable. As if they were driving in the wrong direction, your developers have likely completed many hours of work that will now be scrapped. And your new timetable will have to account not only for all of those lost hours, but also additional time for developers to acclimate themselves to the new requirements.

Bug Fixes

In a detailed arena like programming, fast work is sloppy work. So, as pressure increases from clients and managers to code faster and deliver products sooner, it’s inevitable that developers will make more and more mistakes, and software bugs will arise. Often, when managers measure the time to product delivery—they forget to include the additional time spent developing and releasing fixes to a product that is of substandard quality at its initial release.

The simpler it has become to create and distribute “updates” when a software release is riddled with problems, the less we as an industry seem to care about getting it right the first time. Perhaps if we all slowed down, set reasonable expectations for our developers, and gave them the tools and time they need to nail down every detail of an excellent quality product—we’d actually be saving time, not to mention the reputation of our product, and company, in the long run.

Image courtesy of Kabren.