5 Things Your Software Developer Should Never Tell You

At their best, software developers are geniuses.

I know, because I work with a bunch of great ones. They can pretty much make a computer or smartphone do anything you could imagine. And while Worthwhile’s software developers are beyond awesome, it’s not like we have cornered the market on talented developers.

But as it turns out, talented software engineers don’t always have the best reputation when it comes to actually building the things that businesses can imagine, or at least for building them on time and on budget. It’s why there’s a need for studies like the annual Chaos Report that explain how 90% of large software projects each year struggle or flat-out fail.

Why is this?

One of the big reasons is the communication gap between software developers and business leaders. These groups often think differently about the goals of a project, and may define success using entirely different measures and KPI.

Thankfully, you can avoid falling into the traps of these communication gaps—if you know what you’re looking for. So let’s talk about five things you should never hear from your developer—and the conversations you need to have if you do hear them.

1. It can’t be done

Pretty much anything can be done via software development. So when a developer is skeptical about his or her ability to do something, what he or she is really saying is probably one of these two things:
1) I don’t know how to do this
2) It will be really expensive and time-consuming to do this

So when a developer says, “It can’t be done,” you need to dig deeper to find out what the root cause is. Then you can understand what next step you need to take.

If the developer doesn’t know how to do it, you may need to consider training or provide time for research so the developer can gain the skills and knowledge needed to do what you’re asking.

If the developer thinks it will take a long time to do it, you will need to find out how much time and money your project will take, and then re-evaluate the ROI given the needed investment.

And if it really can’t be done, you can decide on whether it’s worth investing time in product development so that it eventually can be done. But by eliminating the two things mentioned above, you’ll have a clearer view about how possible a potential project actually is.

2. I don’t know why it isn’t working

You build a software product, launch it with internal users or external customers, and then you realize it’s not working as it should. So you tell the developer, and he or she says it should be working.

Should is all well and good, but if it’s not actually working, then the developer needs to investigate.

So make sure your developers are the curious sort, so that when you call out a problem, they want to find the problem and figure out how to fix it.

Even more, you need developers who are actively trying to find and prevent errors, before they arise. They should be using tools like:
* Error reporting using tools like Sentry
* Unit tests
* Code reviews
* Pre-launch testing

If your developers aren’t doing this, encourage them to move toward these best practices—and ask them to find even more tools that will help.

3. I don’t know how long it will take

Unlike the first two statements, this statement may be a legitimate answer. The key is to make sure this is a conversation starter, not a conversation stopper.

If a developer does not know how long something will take, then encourage the developer to do the due diligence needed to figure it out. This may take days or even a couple of weeks, but that’s OK. It’s much better to know what you’re stepping into so you can prioritize this project versus other work that needs to be done.

4. I can ship it whenever you need it

This is the flip side of the previous statement. A developer who promises to deliver finished software whenever it’s needed is either naive, or is telling you what you want to hear. Chances are, if you hear this from a developer three or four times, you’ll end up being disappointed multiple times.

The reason is that setting ship dates first is doing things backward. The amount of effort needed to build software should determine the ship date, not the other way around.

Now, this should not excuse software developers from ever having to meet deadlines. It just means that the developer should work with you to create the first deadline. That will give you a realistic goal for which your developer can be held accountable.

5. Why are we building this?

This question may be the biggest warning sign of any of the five things a software developer could say—because it reveals a fundamental disconnect about the goals of a project.

This is a big problem, because it shows that the developer doesn’t understand the ways a software product should meet user needs or contribute to business objectives or generate ROI. Either the developer hasn’t listened well enough, or you haven’t done a good enough job communicating the larger goals.

Either way, you need to overcome this communication gap so that everyone in the organization is pulling in the same direction. If you don’t have this kind of alignment, your project is almost certain to miss the mark in the eyes of many of your customers and/or internal users.

In Conclusion

In order to unlock the genius of your software developers—whether you’re working with a team or an individual—you need to communicate well. Finding ways to work through these five things a developer should never tell you will put you on the path to the kind of communication you need.

So keep an ear out for these five things, and make sure you don’t get trapped by communication gaps.

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.