Responsibility Driven Design Kata
Nieve
I am wondering whether anyone can direct me to a kata that would work
on the way a developer can use TDD especially to extract certain roles
and responsibilities from one class to other collaborators...Does that
make any sense?
-nieve
Corey Haines
I like Conway's game of life for this.
Nieve
I like Conway's game of life for this.
On May 9, 2011 1:21 PM, "Nieve" <niev...@gmail.com> wrote:
--
You received this message because you are subscribed to the Google Groups "software_craftsmanship" group.
To post to this group, send email to software_cr...@googlegroups.com.
To unsubscribe from this group, send email to software_craftsma...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/software_craftsmanship?hl=en.
Matteo Vaccari
Nieve
Thanks a lot for you thoughts!
Funny that you say that this is something you can add as a restriction to your kata- that's something I've been thinking of lately.
The way I'm starting to see this lately is that in order to respect SRP you *would* want to extract certain responsibilities from your kata object into other object that will collaborate with the object in question, so that your object would have optimally only one reason to change; I do believe the kata, as well as my TDD usage will demand me to do these extractions in the 'refactor' of my red, green, refactor, since green would be just writing the code the way it will just work. Or am I missing something here?
Regards,
n
--
Matteo Vaccari
Matteo,
Thanks a lot for you thoughts!
Funny that you say that this is something you can add as a restriction to your kata- that's something I've been thinking of lately.
The way I'm starting to see this lately is that in order to respect SRP you *would* want to extract certain responsibilities from your kata object into other object that will collaborate with the object in question, so that your object would have optimally only one reason to change; I do believe the kata, as well as my TDD usage will demand me to do these extractions in the 'refactor' of my red, green, refactor, since green would be just writing the code the way it will just work. Or am I missing something here?
Regards,
n
"refactor to remove duplication" step, you will end up separating
responsibilities. So yes, in fact you are right; when I'm facilitating a
dojo I often have to point out that until you remove all duplication you
should not write the next test.
The fact is that most TDD beginners, including at times me, don't see how
important it is to remove every tiny bit of duplication, even when it seems
you're overdoing it! So the reason for the additional rules is to push learners to strive harder. For instance, after doing the OCP Dojo for a while it's become more natural for me to extract functionality to new methods and then to new classes.
Matteo
Ron Jeffries
> I expect JB Reinsberger would point out that if you *really* do the
> "refactor to remove duplication" step, you will end up separating
> responsibilities. So yes, in fact you are right; when I'm facilitating a
> dojo I often have to point out that until you remove all duplication you
> should not write the next test.
> The fact is that most TDD beginners, including at times me, don't see how
> important it is to remove every tiny bit of duplication, even when it seems
> you're overdoing it! So the reason for the additional rules is to push
> learners to strive harder. For instance, after doing the OCP Dojo for a
> while it's become more natural for me to extract functionality to new
> methods and then to new classes.
+ SomeLargeConstant;
I am continually surprised at how much improvement in my code comes
from a constant focus on removing duplication. I'm sure there are
more sophisticated checks and refactorings to be aware of, but even
those, to me, are more and more driven by simply observing and
removing duplication.
Thanks!
Ron Jeffries
www.XProgramming.com
It is better to attempt something great and fail that attempt,
than to attempt to do nothing and succeed.
--Cookie, Garden Court Chinese Restaurant, Hamburg, MI
Steve Tooke
Steve
Ralf Westphal
> > Matteo,
> > Thanks a lot for you thoughts!
> > Funny that you say that this is something you can add as a restriction to
> > your kata- that's something I've been thinking of lately.
beginning.
Instead do them in iterations, e.g. Kata Potter:
1. Calculate the total price for a shopping basket full of HP books,
each is $8.
2. Calculate the total price, but grant a rebate if it´s 2, 4, 7
books.
3. Grant the rebate only for rows of different HP books.
This more like real life, where you don´t know all requirements up
front :-)
And it puts the evolvability of code under stress.
The question always is: Why do you want to do a kata at all?
Since TD has two purposes, namely producing correct code and producing
evolvable code, you need to pose the kata in a way so that both sides
of TDD get exercised.
However, another, altogether different question is: Should you do
katas to learn TDD at all? ;-)
I find TDD highly overrated.
> > The way I'm starting to see this lately is that in order to respect SRP you
> > *would* want to extract certain responsibilities from your kata object into
> > other object that will collaborate with the object in question, so that your
> > object would have optimally only one reason to change; I do believe the
> > kata, as well as my TDD usage will demand me to do these extractions in the
> > 'refactor' of my red, green, refactor, since green would be just writing the
> > code the way it will just work. Or am I missing something here?
green - refactor.
It´s core to TDD. It´s TDD´s design technique.
But refactoring is not producing any value for the customer.
So I´d say: refactoring should be avoided altogether if possible.
Why write code thereby producing customer value - while at the same
time being fully conscious you need to refactor it in the end thereby
burning the customer´s money?
When I´m doing a kata, I´m not refactoring anymore. Still my code
follows all core principles of clean code: SRP, SoC, SLA, loose
coupling; it´s most easily testable (I don´t even need a mock
framework); it´s highly evolvable.
That´s because I replaced TDD´s "test hard" approach with a "test
smart" method.
I´m still doing test-first implementation. For every functional unit I
´m implementing I´m writing the tests first.
But which functional units I need does not come from refactoring, but
from thinking.
Careful requirements analysis and explicit design are core to me.
So when I start coding I know exactly which functional units I need.
They are all small. And they were easily found during design. No CRC
card shuffling needed.
One thing I have to admit, though: This is not possible when you
approach a kata with your grandpa´s OO thinking ;-) You need to forget
about nouns and data for a while.
-Ralf
Curtis Cooley
I TDD because I can not yet reliably predict the perfect design for
the problem I'm solving. Given this handicap, I've found TDD to be the
best coping mechanism. When I can reliably and perfectly predict the
optimal design, I'll probably abandon true TDD as well.
Also, given there is no shortcut for experience, I find TDD to be the
best way for novices and advanced beginners to learn about design and
what makes a design good. That moment when you get a new requirement
and you see the code in your brain and realize all you need to do is
change this one line and the new requirement will fit right in is the
epiphany you need to get from Advanced Beginner to Proficient, IMHO at
least :)
I also get the design wrong a lot because I don't really know what's
coming next, so honing my refactoring skills seems appropriate and
necessary.
--
Curtis Cooley
curtis...@gmail.com
blog:http://ponderingobjectorienteddesign.blogspot.com
===============
Leadership is a potent combination of strategy and character. But if
you must be without one, be without the strategy.
-- H. Norman Schwarzkopf
Peter Gfader
>>I find TDD overrated because it puts refactoring on a pedestal: red -green - refactor.
--
You received this message because you are subscribed to the Google Groups "software_craftsmanship" group.
To post to this group, send email to software_cr...@googlegroups.com.
To unsubscribe from this group, send email to software_craftsma...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/software_craftsmanship?hl=en.
Matteo Vaccari
>>I find TDD overrated because it puts refactoring on a pedestal: red -green - refactor.I wouldn't say that I find TDD overrated, but I agree, it is good to step back and think about the problem a bit more before starting to hack away...< personal experience >I did the "alpha-end converter" kata in TDD manner. Description of the coding problem here http://www.thycotic.com/codetest.txtDuring doing this Kata I got into this "brute force coding" mode, where I didn't think too much, but I just wanted to get the test to green. It took me a while to get over this hurdle and I couldn't solve the kata in that 1 hour session...This annoyed me a lot, so I stepped back, thought about the problem on paper for a couple of minutes and had the solution there...</ personal experience >
I find that this is a problem with kata that drive towards an algorithm, wrt
katas that push me to write a maintainable solution. I don't think that
getting folks to recognize that we're asked to convert from base-10 to
base-13 is particularly interesting. It gets more interesting if you start
asking yourself: can I change base? Can I change the symbols? Can I also
support Roman numerals? Hours and angles (base-60 but with more than one
symbol per "digit")? Babylonian? Can I support different number systems
in the same program? Without introducing IFs?
<http://www.antiifcampaign.com/>
Matteo
Peter Gfader
--
You received this message because you are subscribed to the Google Groups "software_craftsmanship" group.
To post to this group, send email to software_cr...@googlegroups.com.
To unsubscribe from this group, send email to software_craftsma...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/software_craftsmanship?hl=en.
Ron Jeffries
> I find that this is a problem with kata that drive towards an algorithm, wrt
> katas that push me to write a maintainable solution. I don't think that
> getting folks to recognize that we're asked to convert from base-10 to
> base-13 is particularly interesting. It gets more interesting if you start
> asking yourself: can I change base? Can I change the symbols? Can I also
> support Roman numerals? Hours and angles (base-60 but with more than one
> symbol per "digit")? Babylonian? Can I support different number systems
> in the same program? Without introducing IFs?
A kata is not a free-form fight. It is an exercise to practice one
small set of things. Some of Uncle Bob's adhere more closely to this
notion than others that are out there. I prefer to solve a small
problem in a new way, rather than repeat a solution the same way
again and again.
Strictly speaking, that sort of thing, and the ones Matteo mentions
above, are not katas, despite how enjoyable and helpful they can be.
They are more of a free-form dance with the devil in the pale
moonlight. Or something.
Ron Jeffries
www.XProgramming.com
Make it real or else forget about it -- Carlos Santana
Ralf Westphal
> the problem I'm solving.
difficulty of software development.
OOAD is trying to solve this, as is CRC cards, as is TDD.
I call it "the fear of the empty flipchart" :-) Developers faced with
the task of implementing some requirements stand before an empty
flipchart (or whiteboard) and need to fill it somehow. But how to
start? Which class to draw on the flipchart first? Then how to assign
methods to those classes...
For a long time - essentially 25 years, I´d say ;-) - I struggled with
this problem, too.
But then... then I changed my approach completely.
Todays it is very easy for me to design software. It just depends on
my understanding of the problem.
Take the Alpha-end Kata as an example (http://www.thycotic.com/
codetest.txt).
Here´s my problem analysis: http://ge.tt/5a7Emfe/problem%20analysis.pdf?type=download
It took me about 10-15 minutes to come up with the algorithm. (Needed
to refresh my math knowledge about logarithms ;-)
Only after understanding the problem and knowing how to solve the
problem in general, I could have started to code.
TDD would not really have helped me beyond some trivial code.
Instead, though, I did not start coding, but modelled my solution
using Flow-Design (essentially data flow diagrams).
Here´s my design: http://ge.tt/5a7Emfe/solution%20design.pdf?type=download
After understanding the problem it was pretty simple to come up with a
model. The model here is a formalization of the algorithm´s steps.
Modelling took me about 5-10 minutes.
Then I translated the model into code. This was the most boring part,
since I already knew the solution ;-) It lay right before me.
Implementation including unit and integration tests took about 45min.
Here´s the code of the conversion class. It runs flawlessly againts
the predefined kata tests: http://codepaste.net/h5pfe6
Intentionally the methods in the code are left in the order I
implemented them. This is not optimal for understanding the code, but
I wanted to demonstrate how implementation can advance without TDD, if
you have a model you´re transforming into code.
Bottom line:
a. Thinking before coding is essential. TDD does not replace
understanding the problem.
b. Implementation is so much easier without the need for refactoring -
which TDD requires. I just coded away on the model. No refactoring
needed, no mock fx needed.
c. The model is devoid of any implementation detail like classes or
loops. This makes it easy to understand. Explaining the solution with
the model in hand is much easier than showing off code and tests.
>Given this handicap, I've found TDD to be the
> best coping mechanism. When I can reliably and perfectly predict the
> optimal design, I'll probably abandon true TDD as well.
not start coding using TDD.
More to the contrary! Code is much harder to change. So stay away from
coding as long as possible.
Why refactor a single line if you can shuffle around functional units
of code on a higher level of abstraction (aka a model)?
Coding should be done if and only if you´re perfectly sure what to do.
(Which does not mean you know every line of code before you write it,
but you know exactly the purpose of the method/class you´re writing.)
>
> Also, given there is no shortcut for experience, I find TDD to be the
> best way for novices and advanced beginners to learn about design and
> what makes a design good.
and platform.
Design is about, well, design, that means a map, and abstraction, a
plan.
Maps are not the terrain. So you better plan a trip using a map.
>That moment when you get a new requirement
> and you see the code in your brain and realize all you need to do is
> change this one line and the new requirement will fit right in is the
> epiphany you need to get from Advanced Beginner to Proficient, IMHO at
> least :)
Mostly it requires digging around a lot before you know what to do.
That´s different if you´ve a model like the one I drew. Spotting the
places to change in a model is much easier. And it´s much easier to
reason about that with a group in front of a whiteboard showing the
model than looking at code.
>
> I also get the design wrong a lot because I don't really know what's
> coming next, so honing my refactoring skills seems appropriate and
> necessary.
a. You seem to thing you need to get your design right the first time.
But why? Requirements are ever changing. So your design will need to
change with new requirements. Designing does not mean doing it once
and for all. It´s an ongoing task...
Take the Alpha-end Kata again as an example. For the additional
converters for the hex/octal/binary number systems I reasoned about
the necessary changes using my understanding of the problem and the
model. It was immediately clear that conversion for a number system
depends only on 2 data items: the base and the digits. This I
visualized in the model first: http://ge.tt/5a7Emfe/solution%20design%20iteration%202.pdf?type=download
Then I reasoned about how to translate this into code. And again the
solution was obvious: make the current converter a base class.
See here: http://codepaste.net/vf4gt2
And then add converter classes for all bases, e.g. http://codepaste.net/3a2rm7
If I only had the code... how much more difficult would have reasoning
been about the necessary changes.
But with the model in hand and a simple translation of the model into
code, it took me just 11 minutes.
-Ralf
Curtis Cooley
works. I was tasked with implementing a feature set, that existed in
one application, in another application. Not wanting to repeat myself,
I decided to model a framework on the whiteboard that could then be
reused in other applications.
Since I only had one real implementation, I got it mostly wrong. Not
only do I now have to rebuild the framework, I wasted a week building
it in the first place. In short, I was lazy and jumped to the
framework without at least two example implementations.
Had I been on my game, I would have hacked the feature into the new
application then refactored out the commonalities into a framework
that can be reused in the next application that requires this feature.
I tried design up front and got it terribly wrong. I wasted my time
and the company's money. No model of the two implementations would
have helped me see the common pieces, because I would have gotten the
model wrong. Only the code would have shown me the common pieces and
what could be refactored out.
You say that you don't have to get the model right the first time, so
what do you call it when you get the model a little wrong and then
have to improve the design of the existing code?
Additionally, I do not wander blindly into TDD without doing some
analysis of the problem and design of the solution. Which is why
kata's are not a great barometer of TDD's effectiveness given how a
kata is usually algorithm discovery which usually can be done on a
whiteboard.
TDD is not a silver bullet to perfect systems, but it's the best way
I've found so far to build highly maintainable, loosely couple, highly
cohesive systems. I believe that it's much more difficult to build a
tightly coupled, low cohesion system while doing TDD. As you start to
depend on more and more objects, TDD gets harder. As your class starts
to do more and more things, TDD gets harder. It has built in viscosity
that works in your favor.
After 25 years of doing this sort of thing, you have an intuition into
design that others do not. When I stare at and empty flip chart and
start to feel anxious about what to write, I can often relieve my
anxiety by writing the simplest test that fails and going from there.
> --
> You received this message because you are subscribed to the Google Groups "software_craftsmanship" group.
> To post to this group, send email to software_cr...@googlegroups.com.
> To unsubscribe from this group, send email to software_craftsma...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/software_craftsmanship?hl=en.
>
>
--
Ralf Westphal
On 14 Mai, 00:24, Curtis Cooley <curtis.coo...@gmail.com> wrote:
> I just recently went through a real world example of why refactoring
> works.
refactoring if you´re already wading through a brownfield.
> I tried design up front and got it terribly wrong. I wasted my time
> and the company's money. No model of the two implementations would
> have helped me see the common pieces, because I would have gotten the
> model wrong. Only the code would have shown me the common pieces and
> what could be refactored out.
You´re blaming your modelling for your failure. But it wasn´t
modelling that made things go wrong.
Rather it was your assumption you were already able to come up with a
framework.
That´s a whole different reason.
Modelling is not there to save you from false assumptions or not
understanding the problem.
I could not have designed the model for a framework if I had solved
the problem just once, either.
>
> You say that you don't have to get the model right the first time, so
> what do you call it when you get the model a little wrong and then
> have to improve the design of the existing code?
of a model first.
So, yes, refactoring is needed as you improve your understanding of a
problem or extend a solution.
But this mostly happens within the model, not within the code.
With the sample I´ve given (alpha-end kata) this might not be obvious.
I translated the model to methods.
But that was just for simplicity´s sake and because it was an
algorithmic problem.
Still, though, you sure will agree the methods are very small. So if
changes are needed, not much refactoring can even take place. What do
you want to extract from a 3 line method to go into another class?
Again: I´m not saying refactoring is not needed. I just claim (code)
refactoring is the wrong tool to arrive at a design. Don´t use code
refactoring to plan (!) software.
This is not BDUF I´m talking about. No, I´m thinking very short
iterations each starting with a "thinking phase" aka design.
Model a little, code a little...
>
> Additionally, I do not wander blindly into TDD without doing some
> analysis of the problem and design of the solution.
about it?
>Which is why
> kata's are not a great barometer of TDD's effectiveness given how a
> kata is usually algorithm discovery which usually can be done on a
> whiteboard.
algorithmic katas are used throughout the community to get people
started on TDD -, what size problems show TDD´s effectiveness and
efficiency to design (!) software.
Would you feel more comfortable to start an invoicing application
using TDD?
You´d open your IDE of choice and create a test first to get a handle
on the problem?
>
> TDD is not a silver bullet to perfect systems, but it's the best way
> I've found so far to build highly maintainable, loosely couple, highly
> cohesive systems.
ineffectiveness of OOAD or the lack of design guidance your software
development education gave you.
But I´m sure we as an industry can do better than TDD to come up with
designs for code.
>I believe that it's much more difficult to build a
> tightly coupled, low cohesion system while doing TDD.
CRC, or whatever you call your "homegrown OO design approach"?
Yes, TDD is more effective because while doing TDD you´re not even
thinking in terms of objects. Rather you´re thinking in terms of
functionality, you´re focussing on verbs, actions.
Take the alpa-end kata for example again. You start by focussing on
Converter.Convert(). A single function, an action. Then you might do
the simplest possible thing:
string Convert(int n10)
{
return "5";
}
And then... You need to step up from 1 digit numbers to multi digit
numbers. So you think hard what can be done (!) next.
Maybe you come up with this:
string Convert(int n10)
{
string nBase13;
if (n10 > 12) then nBase13 += "1";
nBase13 += MapDigit(n10-13);
return nBase13;
}
This would satisfy the test:
Assert.AreEqual("17", c.Convert(20));
And so on... You´re focussing on actions. That´s great!
But you see: now you are forced to refactor. You need to shuffle code
around.
That´s effort you don´t have to go thru, if you model your solution
first.
TDD essentially is wasting the customers money because, well, changing
code is always harder than changing lines on a whiteboard.
Yes, "bubbles don´t crash" - but that´s an advantage. You´re much more
free to design code with bubbles than without.
The question is, however, which bubbles to use for modelling :-)
My conclusion after many years of trying to do it like the OOAD (or
even DDD) guys are saying: the "look for classes approach" is plain
ineffective and inefficient.
It´s a waste of time, it´s frustrating, it´s only occaissonally
leading to systems living up to clean code principles.
So I can perfectly well understand you´re so inclined to get your
hands on a keyboard and work with code.
Mainstream design approaches simply don´t deliver on their promises.
But they are not the end of it. Neither is TDD. TDD - to me - just is
a reaction to the frustration OOAD brought about.
The pendulum is winging back from bubbles to code.
But in the end... we´ve to take code for what code is: just code. A
clumsy necessity to deliver value to our customers.
Code is the material from which we build software skyscrapers.
But how to arrange the material? That should not be determined by just
trial and error at code level. We´d be not better than medieval masons
- which undoubtedly did marvellous things, but would not have been
able to build the Empire State Building or the SF Bay Bridge or the
Sydney Opera.
Code is just an implementation detail ;-)
If we´re making more of it we´re violating the basic Separation of
Concerns principle.
So the question remains: How to design code? By coding? No, I don´t
think so. Thinking (and modelling) are much more powerful and
efficient.
Again: I did not need to refactor a single line during implementation
of the alpha-end kata.
Coding was straightforward and boring.
And my understanding of the problem would not have been better if I
had started right away with TDD.
Right to the contrary! Understanding is a different mental process
then coding. So I´d say understanding would have been hampered if I
had mixed it with coding.
TDD is multitasking. And multitasking - as we´ve come to know - is
bad.
>As you start to
> depend on more and more objects, TDD gets harder. As your class starts
> to do more and more things, TDD gets harder. It has built in viscosity
> that works in your favor.
think if you did not know what to do in the first place.
But why not use our brains a little more?
My guess is: people jump to TDD because they are lacking mental tools
to tackle a problem otherwise.
If you don´t know anything about compilers you´d probably start by
TDDing like this for a math expression compiler:
Func<double, double> Compile(string expression)
{
return x => return 1;
}
...
Assert.AreEqual(1, c.Compile("1")(1));
And then?
But with some compiler theory, ie. a model of how compilers look, you
´d first come up with a grammar, which is a model. And you then would
mechanically translate this grammar into code, and the code would be
split at least into three disctinct and canonical functional units:
scanner, parser, code generator. All else would be stupid (except for
using ANTLR or Coco/R ;-)
So a little theory, a small basket of thinking/modelling tools goes a
long way.
Math is a thinking tool, state machines are a thinking tool - and flow-
design is a thinking tool.
No, object orientation - to me - is no thinking tool; we´ve tried that
for 20 years now and the results are desastrous.
(That´s a critique of OOAD, not OO languages like C# or Java.)
>
> After 25 years of doing this sort of thing, you have an intuition into
> design that others do not. When I stare at and empty flip chart and
> start to feel anxious about what to write, I can often relieve my
> anxiety by writing the simplest test that fails and going from there.
problem is as new to me as to a freshman.
Solving alpha-end was not about intuition. Some math helped me, for
sure. But designing the solution, drawing the model, had not much to
do with intuition.
But I can understand that you find relieve in writing some code. I
understand that very well.
The purpose of coding, though, is not bringing relieve. I don´t want a
musician get on stage to relieve herself. I want her to perform at her
best for me and all the others in the audience. I don´t want her to
practice and try out new stuff on stage, either.
So to relieve your coding anxiety (which essentially stems from not
understanding the problem enough) write some code - but don´t call it
production code. Call it a spike. XP did much good by bringing spike
solutions to the industries consciousness.
And then, after you improved your understanding of the problem enough,
go back to modelling ;-) And after modelling your solution on the
basis of your spike-improved understanding go back to coding; but now
it´s production code whose structure you arrive at by translating the
model. You should feel relaxed or even bored when writing production
code.
Solving problems, tackling challenges, overcoming lack of
understanding all should not be done while writing production code.
This also is a fundamental separation of concerns.
Learning and relieving anxiety is different from delivering value to a
customer.
Explicit modelling and spike solutions are powerful means to separate
those concerns within your software production process.
-Ralf
Ron Jeffries
> I call it "change" or "refactoring" if you will. But it�s refactoring
> of a model first.
> So, yes, refactoring is needed as you improve your understanding of a
> problem or extend a solution.
> But this mostly happens within the model, not within the code.
I'm going to offer here a different way of looking at the model /
code question than seems to be in your text.
What seems to be missing in the above is that the code /is/ a model.
In fact it is the /only/ model that completely represents the code.
To be useful, a model, including the code, has to represent
something (I'll just say "something") that we want to think about.
Sometimes a drawing or some other form is easier, for some people,
to think about.
> With the sample I�ve given (alpha-end kata) this might not be obvious.
> I translated the model to methods.
> But that was just for simplicity�s sake and because it was an
> algorithmic problem.
I don't understand what you're saying here. It sounds to me as if
you are saying the model is real and the methods are not. The
opposite is the case. The program is what we want, the model is a
means to the program.
Can it be easier, for some people, at some times, to think in terms
of another model? Yes. Does that make it best for them or for
everyone? That's not so clear.
> Still, though, you sure will agree the methods are very small. So if
> changes are needed, not much refactoring can even take place. What do
> you want to extract from a 3 line method to go into another class?
If the program wants the other class,and we pay attention to it, it
will tell us so. If we have an idea in our head, we can put it into
the code, or extract it from the code, as seems best. If we do not
have an idea in our head, it doesn't matter what form of modeling we
use.
It is possible that thinking in some other "format" will help some
people, sometimes, get a new and better idea.
> Again: I�m not saying refactoring is not needed. I just claim (code)
> refactoring is the wrong tool to arrive at a design. Don�t use code
> refactoring to plan (!) software.
I think you're saying that for you, sometimes, you do not reach a
good design using code and refactoring. I can understand that. I can
identify with it. And yet your conclusions, "wrong" and "don't",
seem to me not to follow.
> This is not BDUF I�m talking about. No, I�m thinking very short
> iterations each starting with a "thinking phase" aka design.
> Model a little, code a little...
No one is opposed to thinking, as far as I know. Personally, I would
not think it ideal to think sometimes and then code sometimes, as
the words above suggest. It seems to me to be better to be thinking
about design all the time.
The code /is/ a model. The code is /the/ model. I find many ways of
thinking to be useful, cards, pictures, text. Of them all, I find
the code to be particularly useful, in the sense that it represents
what actually is.
I understand that it can be difficult to look at what is and think
about what ought to be. I would suggest that that's not some
inherent difference between "code" and "model", because there is no
inherent difference between "code" and "model".
What you have discovered, I suggest, is something about your own
mental skills, abilities, preferences, not something about the
universe. That's the good news. We can do something about ourselves,
adjusting and changing our skills. The universe seems not so ready
to accommodate.
For me, I find that more and more I can work in the code and get
from one design to another, often quite different (and often much
better). And I can think about the code / design / model in other
ways with my fingers still on the keyboard. That's useful, because
it tends to keep my program always working as its design improves.
And sometimes, I still like to take a few minutes and draw a
picture. I think that's about me, not about the reality of pictures
and code.
Ron Jeffries
www.XProgramming.com
Know what I pray for? The strength to change what I can, the inability to
accept what I can't and the incapacity to tell the difference. --Calvin and Hobbes
Ralf Westphal
thanks for bringing this up:
On 14 Mai, 10:52, Ron Jeffries <ronjeffr...@acm.org> wrote:
> What seems to be missing in the above is that the code /is/ a model.
> In fact it is the /only/ model that completely represents the code.
> The code /is/ a model. The code is /the/ model. I find many ways of
> thinking to be useful, cards, pictures, text. Of them all, I find
> the code to be particularly useful, in the sense that it represents
> what actually is.
"the code is the design".
This was helpful in distinguishing software development from
construction work etc. We now know why some analogies fail - at least
partly.
But why be content with this? Why think this is it, now? Nothing more
to say about code and design.
If you look at design in a general way, then you probably can agree
with the following:
"Stuff" consists of "material". How the "material" is arranged into
"stuff" depends on requirements.
Design is the description of how to arrange "material" on a higher
level of abstraction. You won´t find mentioning of pieces of
"material" in designs.
Example architectural blueprint: There are no bricks, no window panes,
not shingles in a blueprint. A blueprint is just a high level
framework according to which later on individual pieces of building
material are arranged.
If descriptions of arrangements become more precise/detailed they are
not called design anymore, but plan.
So what about design in software?
Sure, source code is a description of an arrangement for machine code,
and does not contain machine code itself.
Source code thus is some kind of design (not a plan).
And a compiler is the "mason of software development" ;-) who reads
the design to concretely arrange op code "material according to the
design to deliver functional software "stuff".
We are agreeing on that, I guess.
However, I beg to disagree if someone says, that´s it with design in
software. Because this leaves out the purpose of design in general.
If I know how to arrange material into a solution, I´ll do that right
away. No design needed. And if there´s much to do, I hire some help.
If the "stuff" I intend to produce is somewhat big or I need to work
with helpers, I step up a level and make a plan.
And if the "stuff" is even bigger and/or I don´t really know how the
arrangement of "material" should be in detail to fulfill the
requirements... I step up another level and start desiging.
Whether or not to design thus is a matter of complexity.
That means: if source code becomes complex... I better design it
explicitly.
And that means in turn, I use a representation on a higher level of
abstraction.
TDD thus almost is an oxymoron, I´d say, because if combines the
"material" whose arrangement is complicated (or even complex), and
designing.
"Material" and design exist on different levels of abstractions. That
´s the purpose of design.
So designing for "material" by using "material" should not really be
the way to go.
Bottom line: Since source code usually is complicated is deserves a
design. This does not contradict the notion of source code being
design itself.
The design I´m referring to is on a higher level: a design for a
design, if you like.
So what you call a personal discovery I´d call a position based on
principles and fundamental concepts and basic terminology.
Of course I´d be happy to hear your view on why further design that
writing source code is not necessary in software development.
Unfortunately Wikipedia say about design (http://en.wikipedia.org/wiki/
Design): "No generally-accepted definition of “design” exists"
So maybe you want to relate your arguments to my above ad hoc
definition.
>
> No one is opposed to thinking, as far as I know. Personally, I would
> not think it ideal to think sometimes and then code sometimes, as
> the words above suggest. It seems to me to be better to be thinking
> about design all the time.
>
I visit for consulting or when I participate in a coding dojo.
Maybe there is no opposition to thinking before coding - but this does
not show in the process of software development.
On a regular basis teams have a very hard time to not talk in terms of
implementation details about a solution.
They mostly lack shared concepts, methodology, and terminology to do
other than code (and maybe draw a class diagram).
-Ralf
philip schwarz
You said: "I wouldn't say that I find TDD overrated, but I agree, it
back and think about the problem a bit more before starting to hack
away... "
December 2010:
KentBeck: gave up developing a complicated fsm test-by-test. at some
point i just needed to see the whole picture at once.
RonJeffries: @KentBeck FSMs hard test by test. i always draw the
picture first. i figure no one will hurt me for a few minutes'
planning
KevlinHenney: @KentBeck Why are these two things (focusing on detail
and seeing the whole thing) considered contradictory?
jamesshore: @RonJeffries Infidel!
RonJeffries: @jamesshore i am not an infidel. i believe me. see XP
Installed, "Quick Design Session". LOL
RonJeffries: @jamesshore if i had it to do all over again, i'd start a
religion. worked for Hubbard :)
kaleidic: An edge of TDD is nicely indicated by Kent Beck's note, "at
some point I just needed to see the whole picture at once."
RonJeffries: @kaleidic yes. one does need to see the whole program at
times. TDD can be useful for that, with programming by intention ...
RonJeffries: @kaleidic but that does not cover all issues.
KentBeck: @coreyhaines yep. i tried to draw the fsm first, gave up &
started tdd, then gave up & drew the picture. more tdd is next.
KentBeck: @KevlinHenney for me in this case they are informing each
other as i go back and forth.
KevlinHenney: @KentBeck Yup, that's how I see it. Without cycle
between the two, the development/growth may be skewed, faltering or
otherwise unhealthy.
Philip
On May 13, 3:06 am, Peter Gfader <pe...@gfader.com> wrote:
> >>I find TDD overrated because it puts refactoring on a pedestal: red -green
>
> - refactor.
>
> I wouldn't say that I find TDD overrated, but I agree, it is good to step
> back and think about the problem a bit more before starting to hack away...
>
> < personal experience >
> I did the "alpha-end converter" kata in TDD manner. Description of the
> During doing this Kata I got into this "brute force coding" mode, where I
> didn't think too much, but I just wanted to get the test to green. It took
> me a while to get over this hurdle and I couldn't solve the kata in that 1
> hour session...
>
> This annoyed me a lot, so I stepped back, thought about the problem on paper
> for a couple of minutes and had the solution there...
> </ personal experience >
>
> A friend of mine had the same experience and he suggested me the "Call the
> shots" technique for beating this. More on his bloghttp://www.davesquared.net/2010/08/calling-your-shots.html
>
> What is your experience doing TDD?
>
Ralf Westphal
On 14 Mai, 14:55, philip schwarz
> KevlinHenney: @KentBeck Yup, that's how I see it. Without cycle
> between the two, the development/growth may be skewed, faltering or
> otherwise unhealthy.
>
You should consciously switch between the two modes designing and
implementing.
Design a little, code a little.
But that to me also means: coding is not (!) designing - with regard
to source code. Coding is translating a design for source code into
source code.
Likewise is compiling the translation of source code as design for
machine code into machine code.
Designing is working on the level of the big picture.
And I don´t get how TDD can be designing in that regard, since you´re
immersed in source code.
TDD is explicitly not about the big picture. It is doing small steps
without much looking ahead, like cautiously walking through thick fog.
-Ralf
philip schwarz
You said: "refactoring should be avoided altogether if possible."
So you want be signing http://refactoringmanifesto.org any time
soon ;-)
Philip
philip schwarz
You said: "TDD is multitasking. And multitasking - as we´ve come to
know - is
bad."
"From Wikipedia's definition of multitasking: An example of
multitasking is listening to a radio interview while typing an email.
Some believe that multitasking can result in time wasted due to human
context switching and apparently causing more errors due to
insufficient attention."
In his afterword to Kent Beck's 'Test Driven Development by Example',
Martin Fowler explores the idea that the switching done in TDD
increases focus, lowers stress, and reduces monotony. Here is the gist
of Fowler's idea (I have turned excerpts of his afterword into bullet
points):
1. Programming is hard.
2. It sometimes feels like trying to keep several balls in the air at
once: any lapse of concentration and everything comes tumbling down.
3. TDD helps reduce this feeling, and results in rapid unhurriedness
(really fast progress despite feeling unhurried). This is because
working in a TDD development style gives you the sense of keeping just
one ball in the air at once, so you can concentrate on that ball
properly and do a really good job with it.
4. When you are trying to add some new functionality, you are not
worried about what really makes a good design for this piece of
function, you are just trying to get a test to pass as easily as
possible.
5. When you switch to refactoring mode, you are not worried about
adding some new function, you are just worried about getting the right
design.
6. With both of these activities, you are just focused on one thing at
a time, and as a result you can concentrate better on that one thing.
7. Adding features test-first and refactoring, are two monological
flavours of programming.
8. A large part of making activities systematic is identifying core
tasks and allowing us to concentrate on only one at a time.
9. An assembly line is a mind-numbing example of this - mind numbing
because you always do the one thing.
10. Perhaps what test-driven development suggests is a way of breaking
apart the act of programming into elemental modes, but avoiding the
monotony by switching rapidly between those modes.
11. The combination of monological modes and switching gives you the
benefits of focus and lowers the stress on the brain without the
monotony of the assembly line.
Philip
>
> read more »
Ron Jeffries
> But that to me also means: coding is not (!) designing - with regard
> to source code. Coding is translating a design for source code into
> source code.
Honestly, even if all you can do when writing code is translate an
existing design, that does not imply that is all that anyone can do.
Naturally the design we move to has to be in our head ... at least
somewhat. But for god's sake sit down with any good refactoring
person and watch what they do. They can evolve the design all over
without turning to some other form of "design".
Ron Jeffries
www.XProgramming.com
Ron gave me a good suggestion once. -- Carlton (banshee858)
Ron Jeffries
> Hm... "no one is opposed to thinking" is not the reality in the shops
> I visit for consulting or when I participate in a coding dojo.
> Maybe there is no opposition to thinking before coding - but this does
> not show in the process of software development.
You are supposed to learn to think while you code. It seems that may
be the element that has eluded you so far.
> On a regular basis teams have a very hard time to not talk in terms of
> implementation details about a solution.
I don't have that difficulty. And I can talk about design by showing
code or by other means. So I know it is possible. You speak as if it
isn't. But it's not impossible if people can do it.
> They mostly lack shared concepts, methodology, and terminology to do
> other than code (and maybe draw a class diagram).
They, who? Some people you know? I'm not sure who "they" is in this
sentence.
Ron Jeffries
www.XProgramming.com
Knowledge must come through action;
you can have no test which is not fanciful,
save by trial. -- Sophocles
J. B. Rainsberger
I use one in my courses that I haven't written up yet. Maybe I should.
Removing duplication leads to a structure emerging, then improving
names leads to moving responsibilities to more sensible places.
--
J. B. (Joe) Rainsberger :: http://www.jbrains.ca ::
http://blog.thecodewhisperer.com
Diaspar Software Services :: http://www.diasparsoftware.com
Author, JUnit Recipes
2005 Gordon Pask Award for contribution to Agile practice :: Agile
2010: Learn. Practice. Explore.
J. B. Rainsberger
> I expect JB Reinsberger would point out that if you *really* do the
> "refactor to remove duplication" step, you will end up separating
> responsibilities. So yes, in fact you are right; when I'm facilitating a
> dojo I often have to point out that until you remove all duplication you
> should not write the next test.
In problems that want MVC-style solutions, I find that removing
duplication creates the classes to which reponsibilities will
eventually move, but improving names helps identify which
responsibilities should move where.
J. B. Rainsberger
<philip.joh...@googlemail.com> wrote:
> @Ralf Westphal
>
> You said: "TDD is multitasking. And multitasking - as we´ve come to
> know - is
> bad."
I don't find this pattern to match the definition of "multitasking".
0. Write out a list of things you might do.
1. Decide what to do next.
2. Do it. If, in the process, something jumps into your mind that
doesn't help with the current task, then write it down.
3. Go to 1.
I believe this is "Getting Things Done". It's also TDD.
J. B. Rainsberger
> Hm... "no one is opposed to thinking" is not the reality in the shops
> I visit for consulting or when I participate in a coding dojo.
> Maybe there is no opposition to thinking before coding - but this does
> not show in the process of software development.
> On a regular basis teams have a very hard time to not talk in terms of
> implementation details about a solution.
> They mostly lack shared concepts, methodology, and terminology to do
> other than code (and maybe draw a class diagram).
This sounds really frustrating, Ralf, and I understand why it would
get you down. I recently spent time with a group of well-meaning
programmers whose code made it look like it was written in 2000, just
judging by their use of the language. In that situation, TDD seems
years away.
When I started practising test-first programming -- even before my
tests really drove my design -- I spent about 1 year before I felt
that I really began thinking of code in terms of input/output rather
than algorithms and implementation details. I spent that 1 year
practising an average of 4 hours/day. That means 1,000 hours of
practice. Do you think the teams with whom you consult consist of
people who have practised 1,000 hours yet?
It's not easy, it takes time, and we must have patience if we want to
see people improve.
Ralf Westphal
> @Ralf Westphal
>
> You said: "refactoring should be avoided altogether if possible."
>
> So you want be signinghttp://refactoringmanifesto.organy time
> soon ;-)
>
> Philip
>
itself.
It's definition says, you must not change functionality while
refactoring.
Thus refactoring should be avoided - unless it is necessary to make
adding functionality aka customer value easier.
If I can come up with evolvable code without refactoring I think
that's better than being forced to go thru refactoring steps first. I
hope we can agree on that.
If so, then we can go on to discuss the more interesting question: how
to arrive at clean code right away? (Sure I'm talking greenfield code
here. But thats difficult enough for a start.)
People advocating TDD seem to be saying: that's (almost) impossible;
you can't sit down an write clean code just like that. For a given
requirement you need to approach an evolvable structure thru
refactoring. You cannot know it before you have started to code.
As much as I like writing code test first, I nevertheless contest the
notion of "you need to go thru refactorings to find an appropriate
structure."
-Ralf
Ralf Westphal
> 10. Perhaps what test-driven development suggests is a way of breaking
> apart the act of programming into elemental modes, but avoiding the
> monotony by switching rapidly between those modes.
code right while coding.
Slinging code by itself is difficult enough. So you should start doing
it with the addition burden of finding evolvable structures on your
shoulders.
Sure, whatever structures are below the radar of prio modelling need
to be defined while coding.
But since code is comparatively hard to change you want the explicit
modelling radar to cover as much ground as possible.
I some guru programmer can do without, that's fine. But as you cited
even Kent Beck found it difficult to arrive at a solution just doing
TDD.
Structure code in an evolvable way as much as possible on a
whiteboard. Postpone coding. Make coding a no brainer.
Design work done on a whiteboard is not only easier (bubbles dont
crash, drawings are easier to change than code), it also allows more
team members to participate. That increases the likelihood of good
design. That increases the understanding of structures by more people.
Again: coding is no virtue, but a necessary evil in order to satisfy
customers with software. I guess we can agree on that, because we're
constantly seeking relieve from coding thru compilers, DSL, or some
other form of code generators.
So why make coding more difficult by mixing it with "structure
finding"?
To me there are two reasons:
1. addiction to code: writing code is so satisfying personally, that
developers seek out ways to keep doing it (on a level matching the
current culture; today that's 3GL, but formerly they were happy with
assembler and opposed higher level languages).
2. lack of an idea of how otherwise evolvable structures could be
found before coding. Take a pol at your average developer conference:
how many of the attendees are using UML? how many of those are using
more than class diagrams and sequenz diagrams?
I've done this poll several times in my talks at conferences in
Europe. The results are roughly: 15% doing UML, 5% using more than
those two diagrams.
Naturally TDD, an all code approach, must appeal to the 85% of
developers not using the #1 world wide standard for designing
software.
But does that really show the validity of TDD as a successor to
explicit design? Or is it a sign of failure of UML?
I indulge in thinking the latter - an am on a quest for easier
modelling tools, modelling tools for the masses, so to speak. Because,
as said above, code is hard to change, and refactoring does not add
value, and "structure finding" and "code instruction finding" are so
different, they should not be mixed.
-Ralf
Ralf Westphal
> somewhat. But for god's sake sit down with any good refactoring
> person and watch what they do. They can evolve the design all over
> without turning to some other form of "design".
But then, there exist people who can calculate the square root of
numbers with 10 digits in their head.
Or there are painters who can do whole wall paintings without
sketching first.
These are marvellous feats - but I doubt we should expect them from
average developers.
I at least know not a single developer who posesses the capability
you're describing. (hm, on second thought, maybe I know 2.)
You might attribute that to the culture and education of the .Net
community; poor slobs having to work with Microsoft trash. Or you
might say, that's the deplorable state of the are in far away Germany.
But to be honest, on my trips to England or the US doing conference
talks I haven't found that much of a difference between developer
communities/cultures.
But I'm happy for you that you're working in environments where such
capabilities are common.
-Ron
>
> Ron Jeffrieswww.XProgramming.com
J. B. Rainsberger
> Yes, refactoring is an activity which does not add customer value by
> itself.
> It's definition says, you must not change functionality while
> refactoring.
>
> Thus refactoring should be avoided - unless it is necessary to make
> adding functionality aka customer value easier.
This sounds to me like saying "you should avoid exercise, unless it is
necessary for you to keep your metabolism efficient enough to burn
excess fat and avoid heart disease". While strictly true, the condition
is so close to universally true that stating it explicitly in most
contexts obscures the truth, rather than helps to reveal it.
I prefer to say "the point of exercise is to increase one's metabolic
efficiency in order to burn excess fat and avoid heart disease", which
is the same statement made in a way that doesn't risk misleading the reader.
Similarly, the point of refactoring is to simplify the design to reduce
the marginal cost of features and to stop the cost of delivering a given
feature from rising quickly over time.
Refactoring /done well and for a sensible purpose/ adds customer value
that most customers with whom I work have difficulty seeing and
therefore that I have learned to articulate clearly.
I don't know many things that, /not/ done well nor for a sensible
purpose, help a business realise more profit, so don't do any of those
things.
--
J. B. Rainsberger :: http://www.jbrains.ca ::
http://www.thecodewhisperer.com