In my twenty-plus years as a software developer, I have seen the profession change greatly, both in the technologies we use and the practices we employ. Over the years, I’ve been involved with many projects, most successful, some not, and in this post I’ll discuss a few of the lessons I’ve learned that are broadly applicable to any business software project. None of these are new or original, but they are all worth repeating.
- Keep it Simple
- Start with Users
- Know the Quality Requirements
Keep it Simple
This one seems self-evident, yet I continue to see software written by folks who seem to equate complexity with cleverness. I believe the opposite is true; taking a complicated problem and creating a simple, clean solution shows true mastery. This applies to every facet of software development: architecture, code, and user experience.
Overly complex code and architecture wastes the time of every developer who comes after you. Think about the time wasted trying to untangle a web of deep abstraction or suss out the magic, invisible workings of undocumented conventions. Code is written once, perhaps refactored a handful of times, and read many, many times over. Don’t put an unnecessary burden on everyone who reads your code, and keep in mind, the person reading your code and trying to understand what you are thinking now might be you in a year’s time.
Complex UI wastes the time of every user who needs to guess at how to do something, or go through three steps when one would have sufficed. When a user makes a mistake, it is not the user’s fault; it is the fault of the software for allowing that mistake to happen in the first place. Don’t create interfaces that offer a bewildering array of options, or overwhelm the user with every piece of information you can think of; in short, do not throw the kitchen sink at them. Think of the goal the user is trying to accomplish and design an interface that helps them reach that goal as simply and quickly as possible.
Take the time to make your software a simple as possible. Clean, clear code, design and UI/UX will pay dividends over the software’s entire lifetime.
Start with Users
On more than one occasion I have heard end users dismissed by stakeholders higher up the food chain: “They’ll use whatever we give them.” Yet, when the software is delivered and the users rise up in rebellion screaming about how it doesn’t meet their needs, or that it makes them even less efficient, those same stakeholders quickly change their tune and guess who gets left holding the bag? Best case is you work through an uncomfortable negotiation to get paid for the impending re-work; worst case, the project dies and you end up in court. I have seen both and you really want to avoid this.
Treat users as first-class stakeholders and get them involved early. Having them involved throughout the development process ensures you are delivering what they need, and creates advocates in the user community.
Know the Quality Requirements
Quality attributes are most easily defined in relation to functional requirements. Functional requirements describe what the application must do and quality attributes are properties that determine how well the functional requirements are satisfied.
For example, let’s consider the following functional requirement for a web application:
- When the user presses the “Save” button, the order line item will be saved to the database and the order summary page will be displayed.
There are many quality attributes that apply here, but let’s consider performance. For this functional requirement, the performance requirement might be:
- The line item will be saved and the order summary page will be displayed within 1 second of the user pressing the “Save” button.
In reality, this particular requirement would more likely be specified as an application-wide requirement:
- The application will provide a response in less than 1 second for any action performed by the user, unless otherwise specified for a specific functional requirement.
In my experience, people focus on functionality, and quality attributes are not given the attention they deserve until the end of a project, when it becomes clear that in fact there are quality requirements, and they aren’t being met.
The following list of quality attributes comes from Software Architecture in Practice, which I highly recommend:
- Availability
- Interoperability
- Modifiability
- Performance
- Security
- Testability
- Usability
- Development Distributability
- Scalability