Hi Louis,



_,,,^..^,,,_ (phone)
> On Dec 12, 2015, at 5:19 AM, Louis LaBrunda <Lou at Keystone-Software.com> wrote:
> 
> Hi Guys,
> 
> +0.95  I certainly agree we shouldn't write code now that we may need in
> the future but it doesn't hurt to look a little ahead and plan a bit.  If
> the people defining database tables thought a little ahead and didn't try
> to save two characters per date by leaving off the century there never
> would have been a Y2K scare.
> 
> Lou

   I am /not/ saying one shouldn't look forward; I am /not/ saying cut corners or do weak design.  I am saying don't implement what you're not necessarily going to use.  The y2k bug is either bad design or a space optimisation, depending on your point of view, but it isn't an example of requirements driving design.  The requirement is to represent dates; the step to use 2 digits for the year is a subsequent step.

Here's perhaps a better example. I've just spent two years working on Spur, the VM & object representation under Squeak 5 and Pharo 5.  I designed in support for 64-bits from the start.  Because I looked forward, this year the 64-bit version was relatively straight-forward to add.  I /could/ have designed the system to support 128 bits on the assumption that some time 64-bits will be superseded by 128 bits. There there was a requirement for 64 bits.  There is no requirement for 128 bits.  Had I aimed for 128 bits the system would be a mess; too big, slow, more complex to try and get it to work in 32- & 64-bits.

Even further back I designed into the Cogit (the VM's JIT compiler) a split between the generic code generator and an object-representation-specific code generator that generates all code to do with object representation, such as testing for tagged typed, fetching inst vars or allocating new objects, because I knew I wanted to replace the object representation as soon as possible.  Had I not done so, adding Spur would have taken much more work; I would have had to engineer the split by refactoring instead of by design.

So being driven by requirements doesn't mean not looking to the future, it means implementing what you need and what you /know/ you're going to need, not what "would be nice to have" or what "sounds like a really cool idea".

_,,,^..^,,,_ (phone)

> On Sat, 12 Dec 2015 10:09:24 +0100, Stéphane Rollandin
> <lecteur at zogotounga.net> wrote:
> 
>> Eliot Miranda:
>> 
>>> But I'd let requirements drive design, not feature dreams.
>> 
>> ...
>> 
>>> Be guided by what you need now, not by what you think you'll need further
>>> down the road.
>> 
>> 
>> These two sentences should be written in human sized gold letters in 
>> your bathroom, people ! Wisdom !
>> 
>> I mean, +1
>> 
>> 
>> Stef
> -- 
> Louis LaBrunda
> Keystone Software Corp.
> SkypeMe callto://PhotonDemon
> 
>