4 ms·

> 17. Rule of Extensibility: Design for the future, because it will be here sooner than you think. Question is "how much" design for the future is necessary to

> 17. Rule of Extensibility: Design for the future, because it will be here sooner than you think. Question is "how much" design for the future is necessary today. The basic rule of thumb that I follow is to ensure that necessary means of abstraction have been applied and are in place today so that tomorrow we can extend without reworking all the parts.

silentbicycle 17y ago
That's covered by rules 1-6, which emphasize constructing the system using small, independent programs communicating over pipes. I'd rephrase rule 17 as "Don't paint yourself into a corner.". It's easy to waste time overgeneralizing a program before you have a clear idea how it will actually be used. The emphasis on prototyping also keeps this in check, though.
ajross 17y ago
To advocate for the devil: how many useless (or at least unused) abstractions has this produced in your code? How many interfaces have only a single subtype (or turn out not to need runtime virtualization at all)? How many dead/untested accessor methods are there? How many declared methods went unimplemented because they weren't called? How many "plugin" interfaces have you written for software that doesn't need runtime plugins? It's been my experience that "future proof" code tends to be filled with this stuff, and that the cost of all this chaff is vastly higher than the authors think it is when they write it.
sophacles 17y ago
I've always found that if I can forsee an obvious feature or set of functionality that could be useful, to go ahead and either just implement it, or make my low-level functions capable of supporting that from the get-go. Doubly so if the difference in effort is a day or less. I sometimes call this the miracle worker principle. Some bosses dislike you doing things beyond what they say, so you can't tell them when you are following this principle. In 6 months, when they get around to "coming up with the next great idea", you can flip the metaphorical switch, and have their functionality in mere moments. You look like a miracle worker :).
wendroid 17y ago
Yeah I wondered about that one. I would have said it was more like "design for now, tomorrow is a long way off". I think perhaps it means more like "don't make your Epoch 32bits long, it'll soon be 2038" oh

silentbicycle 17y ago

That's covered by rules 1-6, which emphasize constructing the system using small, independent programs communicating over pipes. I'd rephrase rule 17 as "Don't paint yourself into a corner.". It's easy to waste time overgeneralizing a program before you have a clear idea how it will actually be used. The emphasis on prototyping also keeps this in check, though.

ajross 17y ago

To advocate for the devil: how many useless (or at least unused) abstractions has this produced in your code? How many interfaces have only a single subtype (or turn out not to need runtime virtualization at all)? How many dead/untested accessor methods are there? How many declared methods went unimplemented because they weren't called? How many "plugin" interfaces have you written for software that doesn't need runtime plugins? It's been my experience that "future proof" code tends to be filled with this stuff, and that the cost of all this chaff is vastly higher than the authors think it is when they write it.

sophacles 17y ago

I've always found that if I can forsee an obvious feature or set of functionality that could be useful, to go ahead and either just implement it, or make my low-level functions capable of supporting that from the get-go. Doubly so if the difference in effort is a day or less. I sometimes call this the miracle worker principle. Some bosses dislike you doing things beyond what they say, so you can't tell them when you are following this principle. In 6 months, when they get around to "coming up with the next great idea", you can flip the metaphorical switch, and have their functionality in mere moments. You look like a miracle worker :).

wendroid 17y ago

Yeah I wondered about that one. I would have said it was more like "design for now, tomorrow is a long way off". I think perhaps it means more like "don't make your Epoch 32bits long, it'll soon be 2038" oh