The simplest thing doesn't work

[Alan Baljeu]

Following the maxim of writing "the simplest thing that could possibly work" seems to be causing trouble.  The trouble is that we end up with classes that don't fully implement the functionality that's eventually needed, and when others come around to use those classes, and eventually fuller implementations are required, then it turns out that the original design is not adequate, a new design is required, some expectations (tests) need to change and previous uses of the class need to be updated.

In short, because we wrote simple code in the beginning and didn't think deeply enough about what the needs were, a significant amount of redesign ends up being required, resulting in a lengthy turnaround time for implementing a simple feature.  The nice part is that our tests tell us what stuff needs to change.  The lousy part is that so many things need to change.  This seems to be a frequent occurrence here where something comes up requiring a day's detour to redesign something (and everything around it) that previously seemed just fine.

I'm thinking the solution is BDUF, but that's a bad word here.  Is there a better solution?

 Alan Baljeu


      __________________________________________________________________
Looking for the perfect gift? Give the gift of Flickr!

http://www.flickr.com/gift/

[Matt Wynne]

On 18 Aug 2009, at 21:52, Alan Baljeu wrote:

> Following the maxim of writing "the simplest thing that could  
> possibly work" seems to be causing trouble. The trouble is that we  
> end up with classes that don't fully implement the functionality  
> that's eventually needed, and when others come around to use those  
> classes, and eventually fuller implementations are required, then it  
> turns out that the original design is not adequate, a new design is  
> required, some expectations (tests) need to change and previous uses  
> of the class need to be updated.
>
> In short, because we wrote simple code in the beginning and didn't  
> think deeply enough about what the needs were, a significant amount  
> of redesign ends up being required, resulting in a lengthy  
> turnaround time for implementing a simple feature. The nice part is  
> that our tests tell us what stuff needs to change. The lousy part is  
> that so many things need to change. This seems to be a frequent  
> occurrence here where something comes up requiring a day's detour to  
> redesign something (and everything around it) that previously seemed  
> just fine.
>
> I'm thinking the solution is BDUF, but that's a bad word here. Is  
> there a better solution?
>
> Alan Baljeu
>

Hi Alan,

One thing you can do to mitigate this, in my experience, is to write  
both unit tests to drive out the design, and acceptance tests to tell  
you whether the design integrates. Having good acceptance test  
coverage means you can be much more fearless about redesigns of low-
level components.

It's also about good planning: you want to prioritise core features  
that will help you start to build the most important parts of the  
design first. There will inevitably be some churn as the design  
evolves, but careful selection of the order in which you build the  
product out will usually help to reduce this churn. Also make sure the  
developers are in constant conversation with the customers /  
stakeholders who are driving the requirements of the product so they  
get a *sense* of where the change-points are likely to be. Big design  
up-front can be wasteful as you couple your design to a schedule of  
delivery that might never be completed. The key is to design 'just  
enough' up front to make sure your current design has the best chance  
of dealing with tomorrow's change, without being a slave to something  
that might never happen.

Kent Beck has written some great posts about this recently, on the  
subject of 'Responsive Design', notably this one:
http://www.threeriversinstitute.org/blog/?p=175

cheers,
Matt

[phone]
matt@...
http://mattwynne.net

[George Dinwiddie]

Alan Baljeu wrote:
> I'm thinking the solution is BDUF, but that's a bad word here.  Is
> there a better solution?

I've always found incremental design and refactoring to not only give me
excellent designs, but do so quickly.  Let's look in more detail at your
problems:

 > Following the maxim of writing "the simplest thing that could
 > possibly work" seems to be causing trouble.  The trouble is that we
 > end up with classes that don't fully implement the functionality
 > that's eventually needed, and when others come around to use those
 > classes, and eventually fuller implementations are required, then it
 > turns out that the original design is not adequate, a new design is
 > required, some expectations (tests) need to change and previous uses
 > of the class need to be updated.

When you say "fuller implementation" do you mean handle more cases?  Do
you mean accept a more complex API?  What problems pop up when you try
to evolve the original design?

Perhaps an example would be good right about now.

 > In short, because we wrote simple code in the beginning and didn't
 > think deeply enough about what the needs were, a significant amount
 > of redesign ends up being required, resulting in a lengthy turnaround
 > time for implementing a simple feature.  The nice part is that our
 > tests tell us what stuff needs to change.  The lousy part is that so
 > many things need to change.  This seems to be a frequent occurrence
 > here where something comes up requiring a day's detour to redesign
 > something (and everything around it) that previously seemed just
 > fine.

When a change requires modifying lots of places, that's telling you
something about your design.  And BDUF won't save you from the things
it's telling you.  You have to pay attention to the fundamentals of
clean code.  You can look at basic coupling and cohesion.  You can look
at Design Principles.  You can look at Uncle Bob's book, Clean Code.

That's about as much as I can say without seeing the code.  You could
post some here, or privately, if you want something more detailed.

  - George

--
  ----------------------------------------------------------------------
   * George Dinwiddie *                      http://blog.gdinwiddie.com
   Software Development                    http://www.idiacomputing.com
   Consultant and Coach                    http://www.agilemaryland.org
  ----------------------------------------------------------------------

[Michael Hill-10]

I've a very strong feeling that one, some, or all of the factors below are
the real cause of your woe.
* team is not yet up to speed on refactoring, so your classes aren't really
minimal;

* team is not yet skilled at simplicity, so ditto;

* team is not yet udoing aggressive & rapid microtesting, so changes break
tests too often;

* team doesn't know how to handle cross-team or company-to-public
dependencies, e.g. shipping api's;

* team neither pairing nor open workspacing, dramatically slowing team-wide
understanding.

* team likely has no jiggle-less build;

* team could be using tools from the '40s.

I'm not saying that all of these are true.  But I've been doing this for ten
years, and the majority of the teams I've helped all started with one, some,
or all of those problems.

Hill
<geepawhill@...>
http://anarchycreek.com

On Tue, Aug 18, 2009 at 4:52 PM, Alan Baljeu <alanbaljeu@...> wrote:

>
>
> Following the maxim of writing "the simplest thing that could possibly
> work" seems to be causing trouble. The trouble is that we end up with
> classes that don't fully implement the functionality that's eventually
> needed, and when others come around to use those classes, and eventually
> fuller implementations are required, then it turns out that the original
> design is not adequate, a new design is required, some expectations (tests)
> need to change and previous uses of the class need to be updated.
>
> In short, because we wrote simple code in the beginning and didn't think
> deeply enough about what the needs were, a significant amount of redesign
> ends up being required, resulting in a lengthy turnaround time for
> implementing a simple feature. The nice part is that our tests tell us what
> stuff needs to change. The lousy part is that so many things need to change.
> This seems to be a frequent occurrence here where something comes up
> requiring a day's detour to redesign something (and everything around it)
> that previously seemed just fine.
>
> I'm thinking the solution is BDUF, but that's a bad word here. Is there a
> better solution?
>
> Alan Baljeu
>
> __________________________________________________________
> Looking for the perfect gift? Give the gift of Flickr!
>
> http://www.flickr.com/gift/
>  
>

[Non-text portions of this message have been removed]

[Gary Brown-2]

Alan,

Here is my recollection of the rules for simple design:

- does everything needed for now
- passes all of the tests
- contains no duplication
- clearly reveals its intent
* some also add - uses the minimum number of classes and methods

If you later discover that more features are needed, then start with a
failing test ...

GB.



----- Original Message -----
From: "Alan Baljeu" <alanbaljeu@...>
To: <testdrivendevelopment@...>
Sent: Tuesday, August 18, 2009 3:52 PM
Subject: [TDD] The simplest thing doesn't work

> Following the maxim of writing "the simplest thing that could possibly
> work" seems to be causing trouble.  The trouble is that we end up with
> classes that don't fully implement the functionality that's eventually
> needed, and when others come around to use those classes, and eventually
> fuller implementations are required, then it turns out that the original
> design is not adequate, a new design is required, some expectations
> (tests) need to change and previous uses of the class need to be updated.
>
> In short, because we wrote simple code in the beginning and didn't think
> deeply enough about what the needs were, a significant amount of redesign
> ends up being required, resulting in a lengthy turnaround time for
> implementing a simple feature.  The nice part is that our tests tell us
> what stuff needs to change.  The lousy part is that so many things need to
> change.  This seems to be a frequent occurrence here where something comes
> up requiring a day's detour to redesign something (and everything around
> it) that previously seemed just fine.
>
> I'm thinking the solution is BDUF, but that's a bad word here.  Is there a
> better solution?
>
> Alan Baljeu
>
>
>      __________________________________________________________________
> Looking for the perfect gift? Give the gift of Flickr!
>
> http://www.flickr.com/gift/
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

[Alan Baljeu]

I've a very strong feeling that one, some, or all of the factors below are
the real cause of your woe.
>* team is not yet up to speed on refactoring, so your classes aren't really
>minimal;
True.  We haven't been aggressive on this point.  It's difficult as we have a legacy system with lots of undiscovered redundancy (e.g. 10 functions that do almost the same thing, but are scattered around the program.)

>* team is not yet skilled at simplicity, so ditto;
Possibly.

>* team is not yet udoing aggressive & rapid microtesting, so changes break
>tests too often;
Don't understand you here.

>* team doesn't know how to handle cross-team or company-to-public
>dependencies, e.g. shipping api's;
Not applicable.

>* team neither pairing nor open workspacing, dramatically slowing team-wide
>understanding.
False.

>* team likely has no jiggle-less build;
?????  F7 key does a pretty good job for us there.

> * team could be using tools from the '40s.
MSVC++, so I guess you're right ;-)

>I'm not saying that all of these are true.  But I've been doing this for ten
>years, and the majority of the teams I've helped all started with one, some,
>or all of those problems.

Hill
<geepawhill@anarchyc reek.com>
http://anarchycreek .com

On Tue, Aug 18, 2009 at 4:52 PM, Alan Baljeu <alanbaljeu@yahoo. com> wrote:

>
>
> Following the maxim of writing "the simplest thing that could possibly
> work" seems to be causing trouble. The trouble is that we end up with
> classes that don't fully implement the functionality that's eventually
> needed, and when others come around to use those classes, and eventually
> fuller implementations are required, then it turns out that the original
> design is not adequate, a new design is required, some expectations (tests)
> need to change and previous uses of the class need to be updated.
>
> In short, because we wrote simple code in the beginning and didn't think
> deeply enough about what the needs were, a significant amount of redesign
> ends up being required, resulting in a lengthy turnaround time for
> implementing a simple feature. The nice part is that our tests tell us what
> stuff needs to change. The lousy part is that so many things need to change.
> This seems to be a frequent occurrence here where something comes up
> requiring a day's detour to redesign something (and everything around it)
> that previously seemed just fine.
>
> I'm thinking the solution is BDUF, but that's a bad word here. Is there a
> better solution?
>
> Alan Baljeu
>
> ____________ _________ _________ _________ _________ _________ _
> Looking for the perfect gift? Give the gift of Flickr!
>
> http://www.flickr. com/gift/
>
>

[Non-text portions of this message have been removed]


   


      __________________________________________________________________
Looking for the perfect gift? Give the gift of Flickr!

http://www.flickr.com/gift/

[Alan Baljeu]

It's not just "more features", but that the new features partially invalidate the class's behavior.

To me this suggests the original class concept wasn't simple.  Simple concepts are hard to invalidate I think.  But then how do you get a complex system if everything is simple?  Somewhere concepts must build on one another, and then it gets hairier?



________________________________
From: Gary Brown <glbrown@...>
To: testdrivendevelopment@...
Sent: Tuesday, August 18, 2009 5:22:59 PM
Subject: Re: [TDD] The simplest thing doesn't work

   
Alan,

Here is my recollection of the rules for simple design:

- does everything needed for now
- passes all of the tests
- contains no duplication
- clearly reveals its intent
* some also add - uses the minimum number of classes and methods

If you later discover that more features are needed, then start with a
failing test ...

GB.

----- Original Message -----
From: "Alan Baljeu" <alanbaljeu@yahoo. com>
To: <testdrivendevelopme nt@yahoogroups. com>
Sent: Tuesday, August 18, 2009 3:52 PM
Subject: [TDD] The simplest thing doesn't work

> Following the maxim of writing "the simplest thing that could possibly
> work" seems to be causing trouble.  The trouble is that we end up with
> classes that don't fully implement the functionality that's eventually
> needed, and when others come around to use those classes, and eventually
> fuller implementations are required, then it turns out that the original
> design is not adequate, a new design is required, some expectations
> (tests) need to change and previous uses of the class need to be updated.
>
> In short, because we wrote simple code in the beginning and didn't think
> deeply enough about what the needs were, a significant amount of redesign
> ends up being required, resulting in a lengthy turnaround time for
> implementing a simple feature.  The nice part is that our tests tell us
> what stuff needs to change.  The lousy part is that so many things need to
> change.  This seems to be a frequent occurrence here where something comes
> up requiring a day's detour to redesign something (and everything around
> it) that previously seemed just fine.
>
> I'm thinking the solution is BDUF, but that's a bad word here.  Is there a
> better solution?
>
> Alan Baljeu
>
>
>      ____________ _________ _________ _________ _________ _________ _
> Looking for the perfect gift? Give the gift of Flickr!
>
> http://www.flickr. com/gift/
>
>
> ------------ --------- --------- ------
>
> Yahoo! Groups Links
>
>
>

   


      __________________________________________________________________
Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now
http://ca.toolbar.yahoo.com.

[Non-text portions of this message have been removed]

[Gary Brown-2]

Hi, Alan,

Don't expect to be perfect!  8^)

Here is one tip I give to all of my teams.  For each new feature, do a quick
design session (see pp 69-70 of the pink book).

I the new feature fits easily into the existing design, then add it.  If
not, refeactor the existing design so that the new feature does fit in
easily.

That is how you grow your design/architecture incrementally using the rules
of simple design.

YMMV, but probably not by much,

GB.


----- Original Message -----
From: "Alan Baljeu" <alanbaljeu@...>
To: <testdrivendevelopment@...>
Sent: Tuesday, August 18, 2009 4:28 PM
Subject: Re: [TDD] The simplest thing doesn't work

> It's not just "more features", but that the new features partially
> invalidate the class's behavior.
>
> To me this suggests the original class concept wasn't simple.  Simple
> concepts are hard to invalidate I think.  But then how do you get a
> complex system if everything is simple?  Somewhere concepts must build on
> one another, and then it gets hairier?
>
>
>
> ________________________________
> From: Gary Brown <glbrown@...>
> To: testdrivendevelopment@...
> Sent: Tuesday, August 18, 2009 5:22:59 PM
> Subject: Re: [TDD] The simplest thing doesn't work
>
>
> Alan,
>
> Here is my recollection of the rules for simple design:
>
> - does everything needed for now
> - passes all of the tests
> - contains no duplication
> - clearly reveals its intent
> * some also add - uses the minimum number of classes and methods
>
> If you later discover that more features are needed, then start with a
> failing test ...
>
> GB.
>
> ----- Original Message -----
> From: "Alan Baljeu" <alanbaljeu@yahoo. com>
> To: <testdrivendevelopme nt@yahoogroups. com>
> Sent: Tuesday, August 18, 2009 3:52 PM
> Subject: [TDD] The simplest thing doesn't work
>
>> Following the maxim of writing "the simplest thing that could possibly
>> work" seems to be causing trouble.  The trouble is that we end up with
>> classes that don't fully implement the functionality that's eventually
>> needed, and when others come around to use those classes, and eventually
>> fuller implementations are required, then it turns out that the original
>> design is not adequate, a new design is required, some expectations
>> (tests) need to change and previous uses of the class need to be updated.
>>
>> In short, because we wrote simple code in the beginning and didn't think
>> deeply enough about what the needs were, a significant amount of redesign
>> ends up being required, resulting in a lengthy turnaround time for
>> implementing a simple feature.  The nice part is that our tests tell us
>> what stuff needs to change.  The lousy part is that so many things need
>> to
>> change.  This seems to be a frequent occurrence here where something
>> comes
>> up requiring a day's detour to redesign something (and everything around
>> it) that previously seemed just fine.
>>
>> I'm thinking the solution is BDUF, but that's a bad word here.  Is there
>> a
>> better solution?
>>
>> Alan Baljeu
>>
>>
>>      ____________ _________ _________ _________ _________ _________ _
>> Looking for the perfect gift? Give the gift of Flickr!
>>
>> http://www.flickr. com/gift/
>>
>>
>> ------------ --------- --------- ------
>>
>> Yahoo! Groups Links
>>
>>
>>
>
>
>
>
>
>      __________________________________________________________________
> Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your
> favourite sites. Download it now
> http://ca.toolbar.yahoo.com.
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

[Adam Sroka-3]

On Tue, Aug 18, 2009 at 2:28 PM, Alan Baljeu<alanbaljeu@...> wrote:
>
>
> It's not just "more features", but that the new features partially
> invalidate the class's behavior.
>

They do that. Question: if you designed up front could this happen
anyway? And, if so what would you have gained?

> To me this suggests the original class concept wasn't simple. Simple
> concepts are hard to invalidate I think. But then how do you get a complex
> system if everything is simple? Somewhere concepts must build on one
> another, and then it gets hairier?
>

I don't know about that. I have often started with a naive but simple
solution and later found that I needed to optimize it in a way that
invalidated much of what I had done. That is more often true of
algorithmic stuff rather than business logic, but nonetheless.

It helps me not to think of this as "rework" per se. I didn't just
implement the wrong solution. I evaluated a sub-optimal solution, saw
it work, and then reevaluated what I needed it to do. That is part of
the learning process that is inherent to creating great software. It
is also the essence of Agile.

[Steven Gordon-2]

On Tue, Aug 18, 2009 at 8:02 PM, Adam Sroka<adam.sroka@...> wrote:

>
>
> On Tue, Aug 18, 2009 at 2:28 PM, Alan Baljeu<alanbaljeu@...> wrote:
>>
>>
>> It's not just "more features", but that the new features partially
>> invalidate the class's behavior.
>>
>
> They do that. Question: if you designed up front could this happen
> anyway? And, if so what would you have gained?
>
>> To me this suggests the original class concept wasn't simple. Simple
>> concepts are hard to invalidate I think. But then how do you get a complex
>> system if everything is simple? Somewhere concepts must build on one
>> another, and then it gets hairier?
>>
>
> I don't know about that. I have often started with a naive but simple
> solution and later found that I needed to optimize it in a way that
> invalidated much of what I had done. That is more often true of
> algorithmic stuff rather than business logic, but nonetheless.
>
> It helps me not to think of this as "rework" per se. I didn't just
> implement the wrong solution. I evaluated a sub-optimal solution, saw
> it work, and then reevaluated what I needed it to do. That is part of
> the learning process that is inherent to creating great software. It
> is also the essence of Agile.

Also, it is often the case that the "sub-optimal" first solution was
what the customer actually asked for, and that it was only after this
first solution was in use for a little while that it was discovered
that it was sub-optimal and in exactly what ways.  BDUF takes much
longer to discover this delta between what the customer asks for and
what the users really need, which makes bridging that gap much more
expensive.

While learning how to minimize the rework, it may seem like there is a
lot of rework in this approach, but it still works out better than
BDUF where a slightly less sub-optimal solution might be delivered,
but it will be later, and so the discovery of the correct requirements
and the implementation of the optimal solution all too often waits
until version 2 or 3.

Steve G

[franz see]

I think the solution there is simple - refactoring.

TDD is TFD + Refactoring.

The make-the-simplest-thing part is in TFD. But as you've probably already
realized, the simplest thing that works does not necessarily mean
maintainable. That's why you'd have to do refactoring. And after you
refactor, what you have left may not necessarily be the simplest thing
anymore, but you'll find that it's close enough but much more maintainable.

And refactoring is beyond extraction of methods. TDD's refactoring also
allows you to see other classes come into life. It can go something like
this:

(All steps done with TDD)
1. You implement a simple class for requirement#1
2. Then you modify that simple class for requirement#2. Became a bit more
complex but still manageable.
3. You modify the same class again for requirement#3 to requirement#n.

Ok, by this point you see that your simple class had bloated. And you tests
had become much more complex. When this happens, it's a sign that the 'unit'
you once thought of at step#1 is no longer a unit. So you break it down into
several units of their own and things are much more manageable again.

What about BDUF? - well, sure, it could have save you some refactoring time,
but so would 'DUF'. 'DUF' will give you much of the benefit of BDUF with far
less headaches :-)

Cheers,

--
Franz Allan Valencia See | Java Software Engineer
franz.see@...
LinkedIn: http://www.linkedin.com/in/franzsee

On Wed, Aug 19, 2009 at 5:28 AM, Alan Baljeu <alanbaljeu@...> wrote:

>
>
> It's not just "more features", but that the new features partially
> invalidate the class's behavior.
>
> To me this suggests the original class concept wasn't simple. Simple
> concepts are hard to invalidate I think. But then how do you get a complex
> system if everything is simple? Somewhere concepts must build on one
> another, and then it gets hairier?
>
> ________________________________
> From: Gary Brown <glbrown@... <glbrown%40inebraska.com>>
> To: testdrivendevelopment@...<testdrivendevelopment%40yahoogroups.com>
> Sent: Tuesday, August 18, 2009 5:22:59 PM
> Subject: Re: [TDD] The simplest thing doesn't work
>
>
> Alan,
>
> Here is my recollection of the rules for simple design:
>
> - does everything needed for now
> - passes all of the tests
> - contains no duplication
> - clearly reveals its intent
> * some also add - uses the minimum number of classes and methods
>
> If you later discover that more features are needed, then start with a
> failing test ...
>
> GB.
>
> ----- Original Message -----
> From: "Alan Baljeu" <alanbaljeu@yahoo. com>
> To: <testdrivendevelopme nt@yahoogroups. com>
> Sent: Tuesday, August 18, 2009 3:52 PM
> Subject: [TDD] The simplest thing doesn't work
>
> > Following the maxim of writing "the simplest thing that could possibly
> > work" seems to be causing trouble. The trouble is that we end up with
> > classes that don't fully implement the functionality that's eventually
> > needed, and when others come around to use those classes, and eventually
> > fuller implementations are required, then it turns out that the original
> > design is not adequate, a new design is required, some expectations
> > (tests) need to change and previous uses of the class need to be updated.
> >
> > In short, because we wrote simple code in the beginning and didn't think
> > deeply enough about what the needs were, a significant amount of redesign
>
> > ends up being required, resulting in a lengthy turnaround time for
> > implementing a simple feature. The nice part is that our tests tell us
> > what stuff needs to change. The lousy part is that so many things need to
>
> > change. This seems to be a frequent occurrence here where something comes
>
> > up requiring a day's detour to redesign something (and everything around
> > it) that previously seemed just fine.
> >
> > I'm thinking the solution is BDUF, but that's a bad word here. Is there a
>
> > better solution?
> >
> > Alan Baljeu
> >
> >
> > ____________ _________ _________ _________ _________ _________ _
> > Looking for the perfect gift? Give the gift of Flickr!
> >
> > http://www.flickr. com/gift/
> >
> >
> > ------------ --------- --------- ------
> >
> > Yahoo! Groups Links
> >
> >
> >
>
> __________________________________________________________
> Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your
> favourite sites. Download it now
> http://ca.toolbar.yahoo.com.
>
> [Non-text portions of this message have been removed]
>
>  
>

[Non-text portions of this message have been removed]

[Adam Sroka-3]

I'm fairly certain that Alan understands the role that refactoring
plays in the TDD cycle.

Refactoring doesn't change the behavior of the code. Refactoring makes
the code do the same thing, but eliminates duplication and other
sources of complexity.

The issue is that the code is simple (Because we started simple, and
then refactored even simpler) but it turns out not to do everything it
needs to do. Further, when we try to understand how to add the next
test to make it do what we (now) need it to do we realize that a whole
bunch of stuff has to change.

So, if we have to change a bunch of stuff in order to make the
(simple, refactored) code do what it (now) needs to do, what did we
gain by starting with a (too) simple solution?

What I believe is that we gained the knowledge that the simple
solution worked, that it didn't do everything we needed to do, and
that some significant portion of it had to change. We didn't just
assume that; we actually learned it, because we actually saw it
happen. I believe that knowledge drives our efforts forward and is
worth the energy we put in to it despite the instinct to label it as
"rework."

It is not waste, because the naive solution was at least partially
correct based on the information we had. We now have more information.
We took our best shot, we got feedback from seeing that attempt
execute, and then we adjusted our course.

On Tue, Aug 18, 2009 at 9:48 PM, Franz Allan Valencia
See<franz.see@...> wrote:

>
>
> I think the solution there is simple - refactoring.
>
> TDD is TFD + Refactoring.
>
> The make-the-simplest-thing part is in TFD. But as you've probably already
> realized, the simplest thing that works does not necessarily mean
> maintainable. That's why you'd have to do refactoring. And after you
> refactor, what you have left may not necessarily be the simplest thing
> anymore, but you'll find that it's close enough but much more maintainable.
>
> And refactoring is beyond extraction of methods. TDD's refactoring also
> allows you to see other classes come into life. It can go something like
> this:
>
> (All steps done with TDD)
> 1. You implement a simple class for requirement#1
> 2. Then you modify that simple class for requirement#2. Became a bit more
> complex but still manageable.
> 3. You modify the same class again for requirement#3 to requirement#n.
>
> Ok, by this point you see that your simple class had bloated. And you tests
> had become much more complex. When this happens, it's a sign that the 'unit'
> you once thought of at step#1 is no longer a unit. So you break it down into
> several units of their own and things are much more manageable again.
>
> What about BDUF? - well, sure, it could have save you some refactoring time,
> but so would 'DUF'. 'DUF' will give you much of the benefit of BDUF with far
> less headaches :-)
>
> Cheers,
>
> --
> Franz Allan Valencia See | Java Software Engineer
> franz.see@...
> LinkedIn: http://www.linkedin.com/in/franzsee
>
> On Wed, Aug 19, 2009 at 5:28 AM, Alan Baljeu <alanbaljeu@...> wrote:
>
>>
>>
>> It's not just "more features", but that the new features partially
>> invalidate the class's behavior.
>>
>> To me this suggests the original class concept wasn't simple. Simple
>> concepts are hard to invalidate I think. But then how do you get a complex
>> system if everything is simple? Somewhere concepts must build on one
>> another, and then it gets hairier?
>>
>> ________________________________
>> From: Gary Brown <glbrown@... <glbrown%40inebraska.com>>
>> To:
>> testdrivendevelopment@...<testdrivendevelopment%40yahoogroups.com>
>> Sent: Tuesday, August 18, 2009 5:22:59 PM
>> Subject: Re: [TDD] The simplest thing doesn't work
>>
>>
>> Alan,
>>
>> Here is my recollection of the rules for simple design:
>>
>> - does everything needed for now
>> - passes all of the tests
>> - contains no duplication
>> - clearly reveals its intent
>> * some also add - uses the minimum number of classes and methods
>>
>> If you later discover that more features are needed, then start with a
>> failing test ...
>>
>> GB.
>>
>> ----- Original Message -----
>> From: "Alan Baljeu" <alanbaljeu@yahoo. com>
>> To: <testdrivendevelopme nt@yahoogroups. com>
>> Sent: Tuesday, August 18, 2009 3:52 PM
>> Subject: [TDD] The simplest thing doesn't work
>>
>> > Following the maxim of writing "the simplest thing that could possibly
>> > work" seems to be causing trouble. The trouble is that we end up with
>> > classes that don't fully implement the functionality that's eventually
>> > needed, and when others come around to use those classes, and eventually
>> > fuller implementations are required, then it turns out that the original
>> > design is not adequate, a new design is required, some expectations
>> > (tests) need to change and previous uses of the class need to be
>> > updated.
>> >
>> > In short, because we wrote simple code in the beginning and didn't think
>> > deeply enough about what the needs were, a significant amount of
>> > redesign
>>
>> > ends up being required, resulting in a lengthy turnaround time for
>> > implementing a simple feature. The nice part is that our tests tell us
>> > what stuff needs to change. The lousy part is that so many things need
>> > to
>>
>> > change. This seems to be a frequent occurrence here where something
>> > comes
>>
>> > up requiring a day's detour to redesign something (and everything around
>> > it) that previously seemed just fine.
>> >
>> > I'm thinking the solution is BDUF, but that's a bad word here. Is there
>> > a
>>
>> > better solution?
>> >
>> > Alan Baljeu
>> >
>> >
>> > ____________ _________ _________ _________ _________ _________ _
>> > Looking for the perfect gift? Give the gift of Flickr!
>> >
>> > http://www.flickr. com/gift/
>> >
>> >
>> > ------------ --------- --------- ------
>> >
>> > Yahoo! Groups Links
>> >
>> >
>> >
>>
>> __________________________________________________________
>> Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your
>> favourite sites. Download it now
>> http://ca.toolbar.yahoo.com.
>>
>> [Non-text portions of this message have been removed]
>>
>>
>>
>
> [Non-text portions of this message have been removed]
>
>

[Donaldson, John (GEO)]

Alan,

There's quite some distance from BDUF to NoDUF. Perhaps you just need to shift a little bit towards more design. Just enough.
If you are saying that you don't even see the requirement when you first create the classes (which eventually so much rework) then even BDUF won't protect you.

And in any case, tests and refactoring are the best protection in either case.

John D.

-----Original Message-----
From: testdrivendevelopment@... [mailto:testdrivendevelopment@...] On Behalf Of Alan Baljeu
Sent: 18 August 2009 22:52
To: testdrivendevelopment@...
Subject: [TDD] The simplest thing doesn't work

Following the maxim of writing "the simplest thing that could possibly work" seems to be causing trouble.  The trouble is that we end up with classes that don't fully implement the functionality that's eventually needed, and when others come around to use those classes, and eventually fuller implementations are required, then it turns out that the original design is not adequate, a new design is required, some expectations (tests) need to change and previous uses of the class need to be updated.

In short, because we wrote simple code in the beginning and didn't think deeply enough about what the needs were, a significant amount of redesign ends up being required, resulting in a lengthy turnaround time for implementing a simple feature.  The nice part is that our tests tell us what stuff needs to change.  The lousy part is that so many things need to change.  This seems to be a frequent occurrence here where something comes up requiring a day's detour to redesign something (and everything around it) that previously seemed just fine.

I'm thinking the solution is BDUF, but that's a bad word here.  Is there a better solution?

 Alan Baljeu

[Olof Bjarnason]

2009/8/19 Donaldson, John (GEO) <john.m.donaldson@...>:

>
>
> Alan,
>
> There's quite some distance from BDUF to NoDUF. Perhaps you just need to
> shift a little bit towards more design. Just enough.
> If you are saying that you don't even see the requirement when you first
> create the classes (which eventually so much rework) then even BDUF won't
> protect you.
>
> And in any case, tests and refactoring are the best protection in either
> case.

Might I humblify that statement just a little:

"Tests and refactoring are the best _known_ protection in either case."

>
> John D.
>
> -----Original Message-----
> From: testdrivendevelopment@...
> [mailto:testdrivendevelopment@...] On Behalf Of Alan Baljeu
> Sent: 18 August 2009 22:52
> To: testdrivendevelopment@...
> Subject: [TDD] The simplest thing doesn't work
>
> Following the maxim of writing "the simplest thing that could possibly work"
> seems to be causing trouble. The trouble is that we end up with classes that
> don't fully implement the functionality that's eventually needed, and when
> others come around to use those classes, and eventually fuller
> implementations are required, then it turns out that the original design is
> not adequate, a new design is required, some expectations (tests) need to
> change and previous uses of the class need to be updated.
>
> In short, because we wrote simple code in the beginning and didn't think
> deeply enough about what the needs were, a significant amount of redesign
> ends up being required, resulting in a lengthy turnaround time for
> implementing a simple feature. The nice part is that our tests tell us what
> stuff needs to change. The lousy part is that so many things need to change.
> This seems to be a frequent occurrence here where something comes up
> requiring a day's detour to redesign something (and everything around it)
> that previously seemed just fine.
>
> I'm thinking the solution is BDUF, but that's a bad word here. Is there a
> better solution?
>
> Alan Baljeu
>
>

--
twitter.com/olofb
olofb.wordpress.com
olofb.wordpress.com/tag/english

[Donaldson, John (GEO)]

Humblification accepted ;-)

-----Original Message-----
From: testdrivendevelopment@... [mailto:testdrivendevelopment@...] On Behalf Of Olof Bjarnason
Sent: 19 August 2009 10:12
To: testdrivendevelopment@...
Subject: Re: [TDD] The simplest thing doesn't work

2009/8/19 Donaldson, John (GEO) <john.m.donaldson@...>:

>
>
> Alan,
>
> There's quite some distance from BDUF to NoDUF. Perhaps you just need to
> shift a little bit towards more design. Just enough.
> If you are saying that you don't even see the requirement when you first
> create the classes (which eventually so much rework) then even BDUF won't
> protect you.
>
> And in any case, tests and refactoring are the best protection in either
> case.

Might I humblify that statement just a little:

"Tests and refactoring are the best _known_ protection in either case."

>
> John D.
>

[Alan Baljeu]

Adam wrote:
>On Tue, Aug 18, 2009 at 2:28 PM, Alan Baljeu<alanbaljeu@yahoo. com> wrote:
>> It's not just "more features", but that the new features partially
>> invalidate the class's behavior.
>>

>They do that. Question: if you designed up front could this happen
>anyway? And, if so what would you have gained?

Yes, but I suspect much less frequently.  So the gain would be less rework.

>> To me this suggests the original class concept wasn't simple. Simple
>> concepts are hard to invalidate I think. But then how do you get a complex
>> system if everything is simple? Somewhere concepts must build on one
>> another, and then it gets hairier?
>>

>I don't know about that. I have often started with a naive but simple
>solution and later found that I needed to optimize it in a way that
>invalidated much of what I had done. That is more often true of
>algorithmic stuff rather than business logic, but nonetheless.

Ah, as it happens I am working on algorithmic stuff in
the realm of computational geometry.

>It helps me not to think of this as "rework" per se. I didn't just
>implement the wrong solution. I evaluated a sub-optimal solution, saw
>it work, and then reevaluated what I needed it to do. That is part of
>the learning process that is inherent to creating great software. It
>is also the essence of Agile.

So reworking stuff is okay because I'm learning?  Makes some sense, but
it's not totally satisfying because there is so much rework it feels like we
hardly make any progress.

----

Many years ago I had tried an opposite approach (on a greenfield project)
where I studied the problem in-depth,
evaluated all the possibilities, worked out all the computations  necessary, wrote the code
for all the algorithms involved, painstakingly verified every line was correct, and the pressed Compile.
After a few days of eliminating compile errors, I spent a few weeks eliminating executional bugs,
but in the end this process worked for me.  If I were to follow that approach again, the one major
change I would make is to introduce unit testing and emphasize correctness-by-example over
mathematical correctness.

Yet I don't know that I really want to go back there.  It's certainly wasn't Agile.  What I want to achieve is
reliable iteration times.  The old process would give quality code after several months of development.  What
I have now works, but these reworking tasks that pop into the middle of development are turning 1wk efforts
into 1mo efforts.  A huge part of this problem is I don't really know how long things should take, and a huge part
of that is I don't know how much rework is going to pop up.


      __________________________________________________________________
Looking for the perfect gift? Give the gift of Flickr!

http://www.flickr.com/gift/

[Alan Baljeu]

>Also, it is often the case that the "sub-optimal" first solution was
>what the customer actually asked for, and that it was only after this
>first solution was in use for a little while that it was discovered
>that it was sub-optimal and in exactly what ways.  

The customer asked for e.g. "reliably make and
destroy holes with these qualities" in the geometric model.  
We know what has to be
done, but the devil is in the details of how does one define proper
holes in this scenario, in that scenario.  So it's not really about the
customer specifying in more detail, but it's about more test cases
arising out of the existing spec.

In other words, the delta is not from request to need, but from request to
figuring out the direct implications of that request.  Spending more time on
BDUF could quite possibly get a closer approximation of the truth into the code.

>BDUF takes much
>longer to discover this delta between what the customer asks for and
>what the users really need, which makes bridging that gap much more
>expensive.

Would you say it takes longer for my scenario?

>While learning how to minimize the rework, it may seem like there is a
>lot of rework in this approach, but it still works out better than
>BDUF where a slightly less sub-optimal solution might be delivered,
>but it will be later, and so the discovery of the correct requirements
>and the implementation of the optimal solution all too often waits
>until version 2 or 3.

Delivering an imperfect solution sooner may be a good option.  
Skipping the BDUF and getting to code could be the way to get there.
Or not skipping that and saving the effort of recoding 2x over might possibly work better?

>Steve G


      __________________________________________________________________
The new Internet Explorer® 8 - Faster, safer, easier.  Optimized for Yahoo!  Get it Now for Free! at http://downloads.yahoo.com/ca/internetexplorer/

[Alan Baljeu]

Hi Franz,
I deleted the first part because it seemed like good advice and I had nothing to add.
Question about below: You propose replacing "Big Design Up Front" with "Design Up Front"?  
If so what the heck do you mean by that?  Or did you mean something else?



________________________________


What about BDUF? - well, sure, it could have save you some refactoring time,
but so would 'DUF'. 'DUF' will give you much of the benefit of BDUF with far
less headaches :-)

Cheers,

--
Franz Allan Valencia See | Java Software Engineer
franz.see@gmail. com
LinkedIn: http://www.linkedin .com/in/franzsee


      __________________________________________________________________
Looking for the perfect gift? Give the gift of Flickr!

http://www.flickr.com/gift/

[Non-text portions of this message have been removed]

[Alan Baljeu]

>Might I humblify that statement just a little:
>"Tests and refactoring are the best _known_ protection in either case."

Could you please reveal the even better but unknown protection? ;->



      __________________________________________________________________
Be smarter than spam. See how smart SpamGuard is at giving junk email the boot with the All-new Yahoo! Mail.  Click on Options in Mail and switch to New Mail today or register for free at http://mail.yahoo.ca

[Alan Baljeu]

>Don't expect to be perfect!  8^)

Yes I continually fail to meet that expectation.

>Here is one tip I give to all of my teams.  For each new feature, do a quick
>design session (see pp 69-70 of the pink book).

Access violation: "pink book" does not refer to any local objects.  Press any key to reboot.

>I the new feature fits easily into the existing design, then add it.  If
>not, refeactor the existing design so that the new feature does fit in
>easily.

>That is how you grow your design/architecture incrementally using the rules
>of simple design.

>YMMV, but probably not by much,

>GB.

Sounds like a helpful approach Gary!



      __________________________________________________________________
The new Internet Explorer® 8 - Faster, safer, easier.  Optimized for Yahoo!  Get it Now for Free! at http://downloads.yahoo.com/ca/internetexplorer/