Future-Proofing A Design

re: Future-Proofing A Design

Phylyp — Tue, 20 Jan 2009 12:22:11 GMT

Great post Eric, and an excellent comment from Darren Clark

re: Future-Proofing A Design

Jose — Mon, 19 Jan 2009 23:05:19 GMT

All these is good advise but could seem a little too much diluted.

It all comes down to using and knowing when/how to use design patterns.

Future-Proofing A Design means writing the code in such a way that is easy to modify/change in the future, this is covered very well in the "Open Close Principle" (Open to extension but close to modification) also having a good understnading of Encapsulation, ecapsulation of data is good but encapsulating behavior is even better(Ex: encapsulate responsibility using the strategy pattern, or encapsulate creation using the factory pattern), because that way the specific behavior can be isloated to one area, less redundant and easier to change in the future.

If you don't know how to use the "commonality and variability metrix" pattern from netobjectives, please do yourself a favor the check it out, it will help you write software that is easier to change and therefore ready for the future, using concepts like strategy and factory pattern.

Jose.

re: Future-Proofing A Design

rbirkby — Mon, 19 Jan 2009 15:24:23 GMT

#1 rule: Separate your object graph construction (aka wiring, aka 'new') from your logic.

If you do this, you end up with manual dependency injection and a very flexible system which allows your objects to be wired together to suit unforeseen circumstances. It's a shame no language designer has yet created a language which enforces this.

This and many more tips on Misko Hevery's blog: http://misko.hevery.com/ syndicated on the Google Testing blog.

re: Future-Proofing A Design

Tom Kirby-Green — Sun, 18 Jan 2009 10:32:52 GMT

Brilliant posting Eric! I can't help hoping that this will be the first of such in one of your intermittent themed series of posts.

re: Future-Proofing A Design

Greg — Sun, 18 Jan 2009 08:23:08 GMT

#1 future proof rule:

Do not use the latest model, coding style, methodology, third party control, api call, etc. Using the latest new thing will increase the chance your system is married to a buggy, poorly supported, poorly thought out, etc concept, library, tool, api, etc.

This is one of the traps I've seen people with less than 5 years experience fall into where they avoid solving the business problem and think that applying the latest methodology, object model, library, etc will ensure them delivering a functioning system that meets business needs.

I ask whether or not their system/design will a) be maintainable by someone with less than 2 years experience and b) be maintainable by someone on a monday morning where they did not sleep the previous two days. This helps cut down on the premature optimization increasing code complexity needlessly as well as the increased code complexity for the sake of developer ego boost by writing code as if it is a creative writing project instead of a solution to a business problem.

Future-Proofing A Design

DotNetShoutout — Sun, 18 Jan 2009 03:34:56 GMT

Thank you for submitting this cool story - Trackback from DotNetShoutout

re: Future-Proofing A Design

Bahador — Sat, 17 Jan 2009 21:06:22 GMT

That was the best OO back-to-basic post I've read in 2009 ;)

re: Future-Proofing A Design

Craig — Sat, 17 Jan 2009 04:15:29 GMT

With regards to premature generality, the non-coding example that popped immediately into my head was the bus tunnel system in Seattle. They tried early on to plan for a future problem, solved it badly, and had to rip the whole thing out and start over.

re: Future-Proofing A Design

Darren Clark — Sat, 17 Jan 2009 04:04:42 GMT

This reminds me of issues I've seen with developers and databases. The tendency is to thing of the user interface or process, and model the DB to act as a backing store for that process.

What I always advise is "model the world, not the activity". In other words, as closely as possible create the datamodel based on the entities and relationships of the problem domain, NOT on the actual problem being solved.

A lot of times you will end up with a technically more complex data model, but over a very few iterations the complexity pays off in being able to change(fix) your workflow without fighting with or remodeling your data.

The absolute worst outcome is to take a workflow based datamodel, alter the workflow and then try to avoid changing the datamodel. After a couple iterations that system becomes nearly incomprehensible as half of things on the UI have a direct relationship with data, and half some some completely confusing derivation.

In short, databases model things and code models activities, therefore the design of the datamodel should be derived from things and the design of the code should be modeled from activities. The job of the programmer is to bridge the gap.

-Darren