This is why we still build Bad Software

Software projects require a careful balance of interests. Even the smallest projects involve a magnitude of stakeholders which all need to be kept happy with the project’s progress and outcome. Building software isn’t easy, but it’s not rocket science either. The process can be compared to that of constructing a physical building, although it’s much more abstract for the most of us.

In the past decade, we have made huge progress by introducing more iterative processes. Yet there are still projects that do not live up to their potential. We–as an industry–still flush loads of money down the drain. That is money that could have been spent on making the software better.

There is no silver bullet for building better software, although there are several aspects many projects can improve on. We like to believe that most of our issues are technical, but in my experience, most of these issues stem from problems within the software development process.

Please hire an interaction designer

All roads lead to Rome. Some are just a lot less user-friendly. You can hand a specification to a software engineer, but unless you provide sufficient guidance on how a user should interact with a system, every form will come out the same.

Surprise, surprise, few customers actually know what they need. Don’t make the mistake of letting the customer come up with solutions; let them describe the problem. When the problem is clear, the interaction designer and technical architect can come up with the solution. Note that this should be a joint-effort between these two disciplines.

Educate your stakeholders

Building software is an opaque process for those less familiar. People who don’t deal with building software regularly have a hard time grasping the implications of certain decisions. They will be unable to judge the effort required for a feature. This requires you to help them out.

Unless you have carte blanche, there will be times when you will not be able to convince your customer. My advice would be to carefully outline the pros and cons of each option, state your preference and agree to disagree if necessary. Pick your battles wisely.

Require full customer buy-in

Many software shops have successfully adopted agile development processes, yet fail to truly integrate the customers within the process. A bi-weekly demo is not involving your customer. When a company sets out to have software developed they should have someone available to represents its interests–whenever needed.

Continuously have a customer test new features in a staging environment is another critical aspect that helps to improve efficiency. This–again–means that a stakeholder has to dedicate a few hours each week to go through the software and check for possible misinterpretations.

Maximize end-user value

"Sounds (like) a great idea/massive pain to implement" is an unfortunate but often heard combination of words when developing software. When deciding on what features to implement, always try to add as much value as possible, with little effort. You can only make these decisions when you understand the end-user as well as the technical and design implications of a feature.

When you feel that certain features don’t serve the end-user: challenge your customer. Consult with actual users and drop features that don’t make sense, while developing features that do add value. Again, pick your battles wisely.

Ultimately building better software is about better communication with the customer and better understanding between stakeholders. Don’t make assumptions and try to really understand a problem, well before you start building solutions.