Hi Eliot,

>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'm sure you not.  And I didn't mean to imply otherwise.  And I don't
disagree with anything you've said.  I just wanted to be sure everyone
understood there is a difference between not implementing what isn't needed
now and looking ahead enough to allow easy changes in the future.  Your
example designing in support for 64-bits from the start is spot on.

>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.

Just a little history because I'm old enough to remember when disk space
was limited and at a premium (I think IBM 3330 were about 200MB).  The
choice to leave off the century (back then dates and times were often
stored as strings) was a space saving effort.  It was a bad choice, if it
was a conscious one.  I'm not sure it was a conscious choice, as many
programmers didn't look very far ahead even to see the approaching century.

>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
>> 
>> 
>
-- 
Louis LaBrunda
Keystone Software Corp.
SkypeMe callto://PhotonDemon