Geeks With Blogs

Dev.Hell Harrowing the tech business like it's 1999


Slight change of plan; I'll get back to the topic I offered last time--"Smarter/stupider UI"--after this one. I think this needs to come first.

This is my attempt at a  quick, no-bullshit set of principles that determine what makes a good design. None of this is headline news, but I learned this stuff the hard way and I am continually surprised by how many people do not consider thse issues at all. 

1/ Control Dependencies
Every module or subsystem should be as independent as possible. Build upwards, not across--each unit is build on top of more basic units, but dependencies to its peers should be carefully and systematically managed. Certainly, they should not ever depend on functionality from layers of code that lie above their own.

For example, a server is dependent on a database. Logical entities that exists inside the server inherit this dependency--but the relationship between those entities must adhere to strict rules. The stricter those rules the easier it is to create the entities and the easier it is to maintain or replace them. The server should also allow clients to connect and communicate with it, but giving the server detailed knowledge of those clients will lead to lunacy, despair and death.

2/ Inheritance vs Genericity
Know when to inherit and when to be generic; know what's an interface, what's an ancestor, and what's an aggregate.

Any base class that exists to unite two otherwise distinct hierarchies is probably a mistake--there are better options. Perhaps some  this class owns both objects and controls how they interact directly? Perhaps the features you want to enforce should be encapsulated into an interface? Perhaps you can build a a generic, type-independent object that can add the functionality to class belonging to any hierarchy? (Yes, that means 'templates').  Perhaps an adaptor class is required to wrap conforming behaviour around a specific class (The ever popular 'adapter pattern')

3/ Design Patterns Do Not Maketh A Design
Having read DESIGN PATTERNS does not make you a good architect. Mere use of design patterns does not make a product well designed. If the object model is incorrect, no design pattern is appropriate--develop the hierarchy first and then determine which patterns are useful to the system.

If you find yourself in Mad Scientist terrirtory trying to crossbreed two distinct design patterns you are probably barking up the wrong tree. Clean the whiteboard, get a haircut and think again.

4/ Occam's Razor
Write as tight as you can: no hobbyhorse coding, no playpen libraries. More code = more dev time + more bugs + more QA. That adds up to a greater possibility of failure. Plan for the future, but don't build what isn't necessary. The simpler solution is better.

The cliche about 'premature optimization' belongs here--code needs to be correct before you worry about how fast it is. Counting CPU cycles is pointless if the system doesn't work. A cleaner, slimmer design will perform better than a fatter, more complex one; it really is that simple.

5/ Magic Happens

There's no getting around it, sometimes 'magic' is necessary. The programmer waves his wand and the soup congeals into catfood.  Sometimes you discover a hole in the design, or there's a corner case you didn't expect, or the pieces just don't fit the way you thought they would, and you just have to hack (excuse me, 'magic') them together to make a deadline.

As the Amazing Jonothan says, "Sometimes magic sounds like tape." Duct tape, to be precise.

There's no avoiding it, but if your design calls for magic from the outset it's not really a design--it's not a cauldron of  soup, it's a crock of the same old shit.

-- JF

Posted on Tuesday, September 2, 2008 1:51 PM | Back to top


Comments on this post: Design.Principles

No comments posted yet.
Your comment:
 (will show your gravatar)


Copyright © Jason Franks | Powered by: GeeksWithBlogs.net