5

First some backgrounds, I'm interning at a company that makes parallel processing hardware.

We're currently working out the design for a component of our driver that is supposed to evolve over a few generations of our products. The next gen is still in simulation phase and the specification we have now may change when we actually get the hardware. Our module is supposed to work on the current gen and all future gens.

I've always been under the impression that a design should be as future-proofing as possible. In this case, we know exactly what to do for current gen hardware but are unclear on some fronts for the next gen.

So my question is:

When do you know that you should stop designing for the future and just keep it simple and correct for what you know right now?

BeyondSora
  • 151
  • 3

2 Answers2

13

Follow the YAGNI principle, and use sensible design best practices.

Despite the reputation that software developers have among the general public of being in command of some form of black magic, software developers still don't have predictive abilities that extend beyond those of said general public. So stick with what you know. Gather requirements, plan your work, act accordingly.

If one of the requirements is "The application shall be future-proof," well, that is not really a requirement, is it? It's not even a feature; it's just a wish. Take that wish, and break it down until it becomes testable requirements.

Example

The application shall have a plug-in, extensible interface, with the following specifications: [listed here]

That is a testable requirement.

Robert Harvey
  • 199,517
  • The answer seems incomplete. You should design to meet current requirements, and you should design so that you can change your implementation to meet new requirements with as little pain as possible without introducing impractical complexity. – Kevin Jan 22 '14 at 21:55
  • 1
    Kevin, that's the opposite of yagni. THat's YASGNIM. You Are So Gonna Need it, Maybe. – Warren P Jan 23 '14 at 00:42
  • 1
    YAGNI is an excellent principle, but it is not an absolute. Andy256 and gnat have presented the alternative better than I did. – Kevin Jan 23 '14 at 01:24
  • +1 for going back to real Requirements, and pointing out the difference between them and wishes. – mattnz Jan 23 '14 at 01:27
4

Typically we design such software in layers, each with it's own interface. Each layer encapsulates the one below. Layers may be very thin, and depending on the language used, compile down to code with no runtime cost (eg C or asm macros, or C++ templates).

The highest or outermost layer presents the interface your clients use to interact with your product, and changes as little as possible. Inner layers address implementation issues and change whenever they must.

How to design for the future? The hardware team must have some kind of road-map for where it's going. Consult with them. Whatever the extent of their future planning (which cannot be guaranteed to remain unchanged) is the limit of your future planning.

The key is to limit the costs of future change, and that's what those layers of abstraction do. The current lowest layer will address the current simulation. If the simulation changes then that bottom layer will also, but hopefully not the next layer up.

How to know when to stop designing? When you have a design that addresses the known future variation.

andy256
  • 3,156
  • 2
  • 15
  • 20