Who Is to Blame for Bad Software?
By: Matt Angerer
A true story: An entrepreneur had an idea for a great product. He hired a couple of developers to work on it. He gave them exact specifications, down to numeric values for colors and pixel dimensions. The developers made good progress, producing working code and prototypes.
The prototypes were never shown to customers. He didn’t even show them to the company they shared an office building with that showed continuing interest. He declared that “the customer is always wrong.” The result was predictable: No venture capitalist would touch him. Before long, he ran out of money and shut down without a deliverable product.
This is an extreme case, but it shows two of the biggest reasons for bad software. Approaching the project with inadequate resources, hoping to compete against companies with large development teams. Tragically, he even assumed to know exactly what the product should be without ever consulting a prospective user.
People who assume they know users’ needs
When software developers forge ahead with a project but assume they already know exactly what it needs, their chances of success are slim. Software may meet all its functional requirements, but that doesn’t mean it’s fit for its claimed purpose. Let’s look at some of the ways it can go wrong.
- It can lack essential features. Until users try it out, it might not be apparent that it needs to do certain things.
- It can be bloated with unnecessary features. Too many useless features will get in the way of what the software has to do and make it hard to learn.
- It can be clumsy to use. It might have all the right features, but in a way that’s painful to interact with. Common actions might take too many steps, menus might be illogically grouped, or controls might be placed so that a slip of the finger will cause a bad mistake.
- It can use the wrong terminology for the audience. Software for a specialized audience should use its jargon correctly. Software for a general audience should avoid jargon.
People who don’t communicate
Finding out the users’ needs is half of the communication requirement. The other half is letting them know what the developers are producing. Functional specifications aren’t enough; it’s necessary to see the software in action to tell whether it’s right.
Early prototypes won’t do everything, and managers are sometimes reluctant to let users see them because they’re so minimal. However, they show the direction the software is taking, and customers need to see it in order to know as early as possible whether it’s the right direction.
When customers give feedback, the developers have to know about it. If sales people just give reassurances and don’t tell the development team what the customers like and dislike, the project will stagnate in it’s current position. If headed in the wrong direction, a lack of communication will prevent improvements from happening soon enough. Work will go to waste.
People who don’t understand the scope
Great ideas can be stated in simple terms. An innovative software concept can sound self-evident once it’s put into words. Unfortunately, this doesn’t mean great concepts are simple to implement. If they were, someone would have done it already.
Thomas Edison said, “I see a worthwhile need to be met and I make trial after trial until it comes. What it boils down to is one per cent inspiration and ninety-nine per cent perspiration.” A business that underestimates the perspiration a usable product needs won’t succeed, no matter how good its initial idea is.”
This doesn’t mean a small team can’t compete against giants. If they’re really good and really dedicated, a handful of developers can beat a large operation with poor organization and skills. They need to have the right skill set, work well as a team, use the best development techniques, and avoid reinventing what’s already available to build on. Even so, there are limits on how much they can accomplish without more resources.
People who neglect testing
Bad software is never tested properly. Remember, Â developers are never their own best testers; they make assumptions about their code and forget to check the circumstances outside their boundaries.
If testing waits until there’s a release candidate, it’s not going to be thorough enough. Each component needs to be tested separately, with both good and bad data. The code needs to work correctly with valid data and fail gracefully with invalid input. Without this level of testing, user-level tests won’t discover all potential problems. The code will fail at unexpected times and in embarrassing ways.
People who constantly switch priorities
Try to do too much, and you won’t get anything done. People are never as good at multitasking as they — or their managers — think they are. Pulling developers off a project to deal with something else doesn’t just take time away from the project, it disrupts their flow of thought. When they come back to the project, they’ll need to remember what they were doing and why.
Forcing developers to switch tasks disrupts the team as well. While they’re addressing some other emergency, they’re unable to answer questions from other team members, jeopardizing essential pieces of the group project.
Sometimes a manager can’t be bothered to address an issue that needs a decision and tells developers to put the task on hold. The delay drags on and on. Sometimes developers find themselves with nothing they can work on, because they’re being stalled by so many lingering management decisions.
Remember that “hours worked” isn’t a useful measure of productivity. Developers who constantly have to change direction can’t build up any momentum, and they lose valuable time to poor coordination.
Achieving good software
A well-run software development product avoids these mistakes. It starts by learning what the code needs to do to meet its purpose, not just to satisfy a document. It assembles a team that’s capable of doing the job on schedule. As it progresses, users get to see the progress and give feedback, which the developers use to tailor the software for their needs. The team stays focused on the project at hand, with as few distractions as possible, until it’s ready for use.
ResultsPositive’s custom development service understands what it takes to develop and test reliable software and avoid the mistakes that make so many projects fail. Contact us, and a customer service representative will quickly address your concerns.
Subscribe for the latest RP Blog Updates:
