The Difference Between Good and Bad Software
March 22nd, 2008
I’ve been working on a really cool new feature for our website management system, Conductor. Initially, I drafted up the database tables I was going to need. I poured over them, making sure that I wasn’t forgetting anything. The whiteboard with the database tables is pictured below. Once I was satisfied with how I was going to store the data, I dove into the code and started implementing the whiteboard drawing I had created.
Bad Start
About three or four hours in, I realized that things weren’t going the way I wanted and that it was going to take a lot longer than expected to implement. The solution that I had come up with felt complex and was going to require a big rewrite to our theme system. Anytime something feels complex, I go back to the whiteboard because it usually means I haven’t fully thought it through. A bit frustrated, I went back to the whiteboard. This time instead of starting with how I would store the data, I focused on how I wanted to present the data (the interface that the end user would see). Again, you can see my scratching below.
Good Start
As I framed in the interface on the board, the problem started to seem simple and I came up with a new way of doing it that would require no alteration to our theme system or any other existing part of Conductor. Also, this new way makes more sense.
Conclusion
So what am I trying to get at? I think this has taught me the difference between good software and bad software. Bad software starts with the developer thinking how they are going to store the data and technically make it work. Good software starts with the end user. It firsts figures out what will be the easiest way for the user to learn and use the feature and then figures out technically how to do it. I don’t think this is a revelation or that I’ve never built anything in this manner. I am sure, though, that I wasn’t as aware of this before when building applications.
Don’t start technical and force implementation. Start with the interface and let things come naturally.
Subscribe
As much as it seems obvious, I’ve noticed that this isn’t the way things are done since moving to development at my job. You’re exactly right though- most often we scramble to get a bunch of code done, and then beat our heads against the wall with the UI. Luckily, I am in totally agreement with you and this article and am trying to engrain this idea in our methodologies. Nice article!