Always keep the user in mind
For years, German cars were less reliable than Japanese cars, even though German engineering is supposed to be the best (the proverbial German thoroughness). How is it possible that Japanese cars turn out to be more reliable?
People that work with people from both countries have an opinion about that, for example on this Quora post. Depaul reasons that German engineering is performed towards a different objective from Japanese engineering. Where German engineers design every part of a car to be reliable in specified conditions, Japanese engineers design products with the usage of the customer in mind.
Read more: Always keep the user in mindUser first
I think there is a deeper lesson hidden in this story. When designing a product, service, software or whatever else, if you want it to be reliable, start with the user in mind. Think yourself in the position of the user of your piece of software, even before you start developing it. How would you operate it? Which circumstances are realistic? Which information would you want to enter (and which not) and in which way? How can the software be simple and understandable for the user in those scenarios?
But don’t do this on your own. Go out and find the possible users, then ask what they need. In my experience, their answers will often surprise you. There may be things you thought were indispensable for the sure, but it turns out that the user can live without. On the other hand, the user might come up with use cases that you never thought of, and those scenarios can easily ruin your plans if you know them only afterwards.
Consequences
If you start designing with the user in mind, then this will have some consequences.
First, the chance that the user enjoys working with your software increases tremendously, since you validated beforehand what needs to be made.
Second, you can often make things a lot simpler, just by ensuring that you understand the actual needs. It might be possible to drop features that otherwise would dominate the software design, so that your design can be greatly simplified and you can deliver faster.
Digging further
But there is more. This principle of putting the user first does not only apply to the software itself, or to customers of your business. It also applies to the modules within the software.
For example, suppose you need to create a module to some complex computation. Instead of thinking about what you might want to do with the module, start with designing how client code would access the module. You should make it real easy for the client code to use the module and get it to work.
Since there are usually multiple clients, making life easy for the clients will save effort in the long run. Especially for the most demanding client that is the unit test. I hope you write that one first, because if that works, you will have covered most cases.
Even more
But also within modules, it helps to think from the standpoint of the client first. The other day, I was designing a set of functions that clients needed to combine in different combinations; a lot of flexibility was required here. Also, the functions themselves turned out to be rather complex, functions that returned functions and the like. I still wanted the API to be easy to use, yet allow clients to mix and match functions as they needed.
It helped a lot to start from the client side. I started with one piece of client code and thought: “What would the perfect way of using the library look like?” And then I wrote the code down that way, even though none of the API calls did yet exist. The next step was to implement the new functions. Working this way guaranteed that the API is useful.