Fog Creek Software
Discussion Board

Designing for the future

OK, after a frustrating design session for a Version 1.0 app (functionality 95% closed) with lots of "But in future versions, we might need to..." style arguments, I came up with the following corollary-style thing.  I figured this would be a good venue to kick it about a bit.

"Always keep the future in mind, but don't spend all your time designing for it.  It will have changed by the time you get there."



rOD Begbie
Wednesday, October 24, 2001

Don't solve potential future problems with a component. First of all, chances are you'll never have them. Second, the unused features will probaby have bugs or inadequacies that you won't find until you start using them. By that time, you'll have forgotten how the code works, and fixing it will be much harder.

Don't do anything that increases line count or complexity for "future expansion" reasons, such as creating unneeded base classes, subclassing 3rd party components, or trying to build a generic extensible architecture. When the need arises, it'll be easy to refactor the code if it is simple.

On the other hand, if you KNOW that you're going to need a particular feature soon, you'll be better off spending the time thinking it into the design from the beginning, rather than refactoring. XP'ers may not agree with this.

Johannes Bjerregaard
Wednesday, October 24, 2001

Oh God yes, did you ever nail the nail on the flat part of the nail!  Rod, you are 100% in the right on this debate.  Premature coding for phantom features is one of my pet peeves.  Of course you should never design yourself into a corner, but what many people don't realize is that this sort of thinking is more likely to cause design flaws than fix them.

The reason why is very simple: it does not make any sense to design for a feature you don't understand completely and don't care to thoroughly investigate until the next revision.  There is a high probability that you'll have to scrap your half-@ssed framework (or worse -- if you're one of those programmers that are loathe to delete their own code, you'll be tempted into building around an ugly design).  Adding these hooks at the last minute will add needless complexity and cause inconsistencies between the implementation and interface of a component, resulting in a review, debugging, testing, and maintainence nightmare.

And chances are the feature won't be implemented anyways.  Ninety-nine times out of ten, these phantom features are nothing but pipe dreams anyways.  Just yesterday I had to file a bug on a component written by a clever implementor who "planned" for the possibility that there might be two or more users simultaneously logged into a PDA.  Yeah.  Real likely.  If it really was an important feature it would have been made a requirement in the first place.

I am not an XP nut, but I'll swear by the Fourth Commandment of XP: thou shalt do the simplest thing that could possibly work.

Thursday, October 25, 2001

Unfortunately too many times the reasonable idea of not spending time coding for things that don't yet exist and might never exist becomes entangled into data modelling and design issues so that the data model is so incomplete that making it complete breaks everything.<br>
XP is one thing, not designing at all is just stupid.

Simon Lucy
Thursday, October 25, 2001

The main point is to not try to build partial or complete solutions for problems that you don't fully understand. This is not only about wasting time developing for the future, but also about fully understanding the current requirements.

All too often, requirements are discovered ad hoc as development progresses. This is when the architecture becomes really crappy. As long as you know your current requirements before you start designing, you'll be fine.

Don't worry about potential future requirements until they become real. Unnessecary lines of code only adds to what you'll need to understand when that happens.

Johannes Bjerregaard
Friday, October 26, 2001

Something I read at ArsDigita about design...

"A good design should strike you as an elegant, efficient solution to the problem at hand. Elegant solutions often evoke a sense of "deep simplicity" - the problem is solved cleanly, and the conceptual integrity of the system is strong. By contrast, poor design evokes the word "kludge" - a solution that may or may not address all aspects of the problem, and seems to have its pieces held together by the programming equivalent of duct-tape."

Chances are if you manage to acheive this for the 'now' problems, the future issues will be in good shape too.

Tony McConnell
Sunday, October 28, 2001

I generally think that people should create frameworks, and build their applications on top of that.  This way, you're designing one level below what you want to create, and it's more of a matter of linking modifiable things together.

Modularity tends to come cheaply once that's done.

forgotten gentleman
Tuesday, October 30, 2001

*  Recent Topics

*  Fog Creek Home