Geeks With Blogs
Mark Schmidt's Abode On programming, writing, gaming and life...

I am the lead architect for a component (specifically the presentation layer) on our team.  I have 1 other person helping me with implementation.  One day we had to add a new feature.  I designed a solution and handed it off to him and he came back and asked “why do we need it to do this? It wasn't in the requirements?”  I responded by saying something along the lines of “because eventually someone will ask for it”.  In fact, I find myself saying that over and over again.

Now here's a little background on what I'm doing.  I call my component an engine for good reason but will not delve into those reasons right now.  The best comparison you can make to a technology out there that is similar to what I'm doing is the engine that renders XAML or Mozilla using XUL.  I have had 3 main tenants from beginning until present day.  The engine must be 1) extensible, 2) customizable and 3) simple.  So, what if I followed his advice and just designed a new feature to work with that one single requirement.  Is it extensible? No.  Is it customizable? Probably not. Is it simple? Yes.  But you see, I have a definite “yes” for the 1st tenant so I immediately scrapped that design in favor of a design that supported all three.  However, I think he still tends to disagree.  To put it in example form, let's say you had a requirement to add a new feature that would transform the UI definition document from 1 form to another using XSLT.  Using his methodology, we go by the book.  We add a feature that takes the UI definition document, a path or stream to some XSLT and transform to some result document.  My methodology however is more along the lines of we take the UI definition document, a path or stream to some unknown format that a plugin only knows about, tell the plugin to transform to a result document.  We can then create an XSLT plugin, a javascript based plugin that uses a javascript source file (just thinking off the top of my head), and later on down the road we add a plugin for technology X that someone is creating in their garage right now.

So with the design just outlined, let's ask the questions again: 1) extensible? Yes via plugins. 2) customizable? yes, we can now mix and match different plugins based on what we want the engine to do 3) simple? Yup.

Now I must also say that their are some times where you just have to follow the requirment word for word.  For this project however, I am creating a framework/infrastructure type component and therefore need to anticipate features that developers may require in the future.


Posted on Monday, May 24, 2004 1:04 PM General Programming | Back to top

Comments on this post: Design for the now or the future?

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

Copyright © Mark Schmidt | Powered by: