Skip to content

Design Constraints

Reading Time: 1

I’ve spent the better part this week trying to hammer out an architecture for a new application I’m developing. Most of my time was wasted in a problem space too large for solutions. I had a list of all the functions, a list of all the data, and profile of all the users and the roles they would take. But none of this was getting me any closer to a solid architecture design.

What I did instead was put an arbitrary constraint on the system. I simply chose to base the interface on del.icio.us and bang, that was all I needed to move forward. One constraint on the system and I was able to start putting the whole thing together.

This then reminded me of Bob Colwell’s article from the March 2005 issue ofComputer. (Bob Colwell is an amazing writer who’s blends great story-telling ability with engineering principles, his column is the first thing I read in Computer each month.) In this article he talks about hardware engineers compared to software engineers when it comes to design. Hardware engineers have real-world physical constraints (e.g. speed of light, Ohm’s law, etc) where software engineers are free to think up any hair-brained system they want. While software engineers don’t have to deal with the laws of physics, we do put constraints on systems in the form of languages, interfaces, architectures, etc. It is through these human-created constraints that we software engineers are able to “focus the mind” as Mr. Colwell says and develop working code.

Post a Comment

Your email is never published nor shared. Required fields are marked *
*
*