I have been writing computer programs for more than 20 years now. I thought it’s about time to gather some of my experiences and write some advice on building better computer programs.
1. Solve the right problem
It is all too often that one tries solving something before understanding the problem at hand. We have a certain understanding of what the issue is, write something to solve it, but it turns out that we wrote the wrong solution because we misunderstood the problem. Do some research, read some articles, talk to people and read some books before attempting to solve a problem.
2. Don’t rewrite the wheel
You need a web server? Use an off-the-shelf one. It’ll be supported, it will be stable and it will implement the whole specification. Developers all too often think they can just write an XML parser overnight. Maybe for a simple one, but have you considered all the edge cases? How about UTF-16 character encoding in big endian mode? Are you prepared to support this code for the next 10 years?
3. Think about who, where, and where will use the system
Who is likely to use this system? How will their understanding of the system shape their usage? With what intent will they approach the system? Will they be forced to use it? Will they be trained? How can you train/help them? Will it be used for short periods of time only? You may need to make the interface very simple then — you can’t have deep menus and 20 configuration parameters. Will it be used by professionals? They might easily accommodate (and need) hundreds of settings.
4. Create simple prototype(s) and keep iterating
Try creating something simple that can do the job. If it doesn’t fully address the issue yet, you can now gain a better understanding of how the product works when it’s plugged into the processes of the people it’s supposed to help. Observe and fix what seems to be missing. Remember, if it aint’t broke, don’t fix it.
5. Focus on the customer experience
The classic example is that people will be happier if you can accurately tell them that there are 10 minutes left to finish a task rather than not showing them anything but finishing in only 5 minutes. Never forget what purpose the software is supposed to fulfil. Customer experience is paramount.
6. Design the system for change
There is only one thing that is constant about any project I’ve ever worked on: change. Requirements change, our understanding of the processes change, the underlying hardware and software environment changes, the legal and social framework the system is operated in changes. If you want to build for success, you have to make sure the system can accommodate these changes over time. Building rigid systems essentially sets you up for failure.
6. Don’t do everything that every customer wants
Tactics without strategy is the noise before defeat. Have a long-term strategy in mind where you want your system to go. Without such a strategy in place, it will be hard to know which customer demands should be fulfilled.
7. Don’t just fix bugs. Fix the specification.
The specification should be part of your test suite. If there is a bug it means that your specification was incomplete or wrong. The hardest bugs are rarely technological. They are almost always a bug in the specification. Fix the specification by adding the missing tests and make sure the specification is just as agile as your software development. Your specification must change, so your test suites, tools, and environments must be easy to maintain and change.
8. Enjoy doing what you do
Enjoying what you do, and making sure everyone on the team enjoys it too, makes not only for a fun time, but will also make people on the project committed to its success. Every project experiences ups and downs. In order to wither these storms and keep people around with deep knowledge and understanding of both the product and its environment (human, technological, process, legal, social), you have to make sure that everyone in the team is enjoying working on the project. Remember: it’s the people who build, maintain, and sell the system.