I recently had a long conversation with one of my colleagues about what makes a good design. In other words, how do I know if a particular approach constitutes a good design or a bad design? For me this typically comes down to intuition and experience. Here are the guidelines that I use to determine.
- Learn from the best. If you always do everything your way then it will be always your way. Occasionally it might indeed be the best way. But your life and work experience is just a drop in the ocean of trillions of days of experience amongst millions of other people out there.
- Read books about software design, agile and development processes. I mean good quality books (i.e. not the “for dummies” types. A good start is to look at Addison-Wesley Signature Series).
- Watch sessions from conferences. The best girls and boys that you can find out there. The top conference speakers alone will have delivered more working software than you or your team will ever deliver.
- Focus your time on blogs from people who have written good books and have outstanding sessions at conferences instead of random blogs. Don’t get me wrong, my blog falls squarely in the latter category. Read articles that are edited and peer reviewed, much like articles in newspapers and magazines (again not some random blog)
- Read StackOverflow instead of random forums. StackOverflow is quite well edited by other users and admins.
- Know the basics: principles, patterns, and clean code rules. Learn to recognise tight coupling and code that goes against good architecture principles. For example, if you have a layered architecture where each layer calls all other layers, then it is more like layered spaghetti.
- Do not ever ignore code smells. Keeping smells in code is okay for maybe one day. Take the time to go back and fix it.
- Don’t fool yourself into believing that you can create the perfect design and then forget about it. A design is good when it is deployed and the cost of change is small so you can easily evolve it. It takes countless iterations and a lot of coding after each revision to create good design, so don’t settle for what you have. Make mistakes and correct them as quickly as you can.
- Don’t look to lay blame. When it comes to legacy code, no-one cares who wrote it or why it is the way it is. Focus on making things better.
- Learn from the community and teach others. We all have same the goal, quest for transcendent software, to make money, make the world better, and claim the fame 😀
Sebastian Belczyk is a Software Engineer at Olympic Software. He specializes in the areas of software craftsmanship, design and architectures. You can connect with him on LinkedIn or contact him at: firstname.lastname@example.org