1a.
Re: EverydayAgile
Posted by: "Marta Gonzalez Ferrero" marta.gferrero@gmail.com martagf_99
Sun May 11, 2008 5:16 am (PDT)
I agree with Chris, I have seen the same in companies I have worked for,
specially the last group. I know teams that see the benefit of Agile, but
don't see the need to change because they are performing well already (even
if it's not exactly accurate). It's not because they don't get it, but
because they're absolutely sure that the change doesn't have any value for
them (and in some cases this is probably true). However, often these teams
have issues they are not aware of, or just ignoring (just because you hit
the deadline doesn't mean it has not been a painful journey). Transitioning
to Agile is really difficult to explain for them, because what's needed is
not just to explain what the benefits of adopting an Agile approach are
(which most of them already have heard of). It's also necessary to help them
realise that they do have issues, and that dealing with them effectively
would be a benefit for the team (which, of course, often makes the person
unpopular for those who prefer the ostrich strategy!)
Cheers,
Marta
2008/5/10 Chris Wheeler <christopher.wheeler@gmail.com>:
> On Sat, May 10, 2008 at 11:15 AM, Clarke Ching <clarke.ching@gmail.com<clarke.ching%40gmail.com>
> >
> wrote:
>
>
> > Hi everyone,
> >
> > One of the things that really bothers me about Agile - as a
> > movement/revolution - is that a lot of good people are missing out on
> the
> > benefits of working in an agile way because they're convinced that agile
> is
> > for rocket scientists.
> >
> > The one thing you WILL NOT get out of this is the chance to blame "those
> > idiots" for not "getting it".
> >
>
> My experience is not the same as yours - I've never seen anyone around
> here
> blame 'those idiots' for 'not getting it'. Also, my experience is not that
> people think agile if too hard or for 'rocket scientists'; rather, they
> have
> either tried it and it has not worked, or they haven't tried it and feel
> it
> couldn't work.
>
> That's different than your characterization of the situation.
>
> Chris.
>
> [Non-text portions of this message have been removed]
>
>
>
[Non-text portions of this message have been removed]
2a.
Re: Incremental design material (was YAGNI Football Analogy)
Posted by: "Ilja Preuss" it@iljapreuss.de ipreussde
Sun May 11, 2008 5:32 am (PDT)
I'd think that "Refactoring" by Martin Fowler would be the seminal work.
"Agile Software Development - Principles, Patterns and Practices" also
seems like it would fit.
Kim Gräsman wrote:
> Hello all,
>
> It seems incremental design has become a theme (if implicit) on the
> list these past weeks -- does anyone have good references to reading
> on incremental design? Kent's note below whet my appetite...
>
> Ron's C# Adventure book is finally in the mail headed for my house,
> but it'd be interesting to see if there's more material available.
>
> Thanks,
> - Kim
>
> On Wed, May 7, 2008 at 6:22 PM, Kent Beck <kentb@earthlink.net> wrote:
>> <snip>
>> I don't know if that was helpful, but I have design-y ideas swirling around
>> in my head as I work on the incremental design material, so it came out
>> easily. Please let us know how your situation came out.
>
> ------------------------------------
>
> To Post a message, send it to: extremeprogramming@eGroups.com
>
> To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@eGroups.com
>
> ad-free courtesy of objectmentor.comYahoo! Groups Links
>
>
>
>
2b.
Re: Incremental design material (was YAGNI Football Analogy)
Posted by: "Kim Gräsman" kim.grasman@gmail.com kimgrasman
Sun May 11, 2008 6:56 am (PDT)
Hi Ilja,
Thanks for answering.
On Sun, May 11, 2008 at 2:32 PM, Ilja Preuss <it@iljapreuss.de> wrote:
> I'd think that "Refactoring" by Martin Fowler would be the seminal work.
>
> "Agile Software Development - Principles, Patterns and Practices" also
> seems like it would fit.
I've read both of them, but maybe not with the right glasses on.
I guess I'm looking for practical advice on how to design for
evolution. I suppose /Refactoring/ has enough tips in it that it might
fit the bill... I'll read it again and see how it feels.
Cheers,
- Kim
2c.
Re: Incremental design material (was YAGNI Football Analogy)
Posted by: "Steven Gordon" sgordonphd@gmail.com sfman2k
Sun May 11, 2008 7:24 am (PDT)
On Sun, May 11, 2008 at 6:56 AM, Kim Gräsman <kim.grasman@gmail.com> wrote:
>
> Hi Ilja,
>
> Thanks for answering.
>
> On Sun, May 11, 2008 at 2:32 PM, Ilja Preuss <it@iljapreuss.de> wrote:
> > I'd think that "Refactoring" by Martin Fowler would be the seminal work.
> >
> > "Agile Software Development - Principles, Patterns and Practices" also
> > seems like it would fit.
>
> I've read both of them, but maybe not with the right glasses on.
>
> I guess I'm looking for practical advice on how to design for
> evolution. I suppose /Refactoring/ has enough tips in it that it might
> fit the bill... I'll read it again and see how it feels.
Maybe the advice will seem too theoretical - the simpler and more
expressive the code is, the easier it is to adapt it to the next new
requirement.
So, by not trying to explicitly design for future requirements, but
instead focussing on creating the simplest and most expressive code
for the current requirements, we create the design that will be most
adaptable over the set of all possible future evolutions of the
system. I remember that this was my major takeaway from ASD - PPP.
Striving for simplicity and expressiveness is the recommended agile
strategy for designing for evolution. TDD and Refactoring are
recommended techniques for executing that strategy.
Steve
>
> Cheers,
> - Kim
2d.
Re: Incremental design material (was YAGNI Football Analogy)
Posted by: "Ilja Preuss" it@iljapreuss.de ipreussde
Sun May 11, 2008 7:39 am (PDT)
In my opinion, the OO design principles discussed in the latter book,
together with the XP definition of "Simple Design", are the main things
you need to understand and apply when designing for evolution. And
Refactoring is how you evolutionary *change* the design.
So I'm not sure what glasses you had on, but to me it seems to be quite
clear... ;)
Cheers, Ilja
Kim Gräsman wrote:
> Hi Ilja,
>
> Thanks for answering.
>
> On Sun, May 11, 2008 at 2:32 PM, Ilja Preuss <it@iljapreuss.de> wrote:
>> I'd think that "Refactoring" by Martin Fowler would be the seminal work.
>>
>> "Agile Software Development - Principles, Patterns and Practices" also
>> seems like it would fit.
>
> I've read both of them, but maybe not with the right glasses on.
>
> I guess I'm looking for practical advice on how to design for
> evolution. I suppose /Refactoring/ has enough tips in it that it might
> fit the bill... I'll read it again and see how it feels.
>
> Cheers,
> - Kim
>
> ------------------------------------
>
>
>
>
2e.
Re: Incremental design material (was YAGNI Football Analogy)
Posted by: "Ron Jeffries" ronjeffries@XProgramming.com RonaldEJeffries
Sun May 11, 2008 8:46 am (PDT)
Hello, Kim. On Sunday, May 11, 2008, at 9:56:23 AM, you wrote:
> I guess I'm looking for practical advice on how to design for
> evolution. I suppose /Refactoring/ has enough tips in it that it might
> fit the bill... I'll read it again and see how it feels.
I'd suggest two things:
First, going back to the classic issues of good design, high
cohesion and low coupling. Good design means changeable design, and
these characteristics, cohesion and coupling, delineate and measure
design quality, albeit subjectively.
Second, follow Beck's description of simple design. In priority
order, a design is simple to the extent that
1. It runs all the tests,
2. Contains no duplication,
3. Expresses all the design ideas that are in there,
4. Minimizes the number of entities such as classes and methods.
The Beck description is simple, but deep. As we follow these rules
more and better, the design becomes better. As the design becomes
better it becomes better able to evolve.
2f.
Hi guys,
Yes, I see the same truths repeated and they are good, but I think
there's more to it than simplicity. For me, Beck's bullet point list
for simple design is too reduced. It sounds clear and concise, but I
find there's something missing for me to relate it to my own design
activities. Narrative, perhaps, I'm not sure.
I found Fowler's /Is design dead?/ [1], which I really liked. There's
a section on reversibility -- I think this may be one of the
cornerstones of malleable design, that you try your darndest not to
make irreversible design decisions.
Jim Shore's /Continuous Design/ [2] is a nice presentation of the
benefits and has a list of goals of incremental design to facilitate
change.
I'm just thinking about this in the abstract, I don't have an actual
question really, but it seems to me getting a team started with
incremental design can be difficult, and I've talked to people who
have tried without much success. So I think I'm trying to better
understand the practice before misguidedly attempting to use it.
It seems to me it would be interesting to look at BDUF designs
compared to incremental designs (as Jim S seems to have done) and see
what sets them apart. What aspects of code make it suitable for
evolution? Simplicity, sure. Singularity, yes. Abstraction?
Reversibility? Strict obedience of all of Uncle Bob's OO principles
;-)?
I'll go back to my books and do some more thinking...
Thanks,
- Kim
[1] http://martinfowler.com/articles/designDead.html
[2] http://www.martinfowler.com/ieeeSoftware/continuousDesign.pdf
> > Hi Ilja,
> >
> > Thanks for answering.
> >
> > On Sun, May 11, 2008 at 2:32 PM, Ilja Preuss <it@iljapreuss.de> wrote:
> > > I'd think that "Refactoring" by Martin Fowler would be the seminal work.
> > >
> > > "Agile Software Development - Principles, Patterns and Practices" also
> > > seems like it would fit.
> >
> > I've read both of them, but maybe not with the right glasses on.
> >
> > I guess I'm looking for practical advice on how to design for
> > evolution. I suppose /Refactoring/ has enough tips in it that it might
> > fit the bill... I'll read it again and see how it feels.
>
> Maybe the advice will seem too theoretical - the simpler and more
> expressive the code is, the easier it is to adapt it to the next new
> requirement.
>
> So, by not trying to explicitly design for future requirements, but
> instead focussing on creating the simplest and most expressive code
> for the current requirements, we create the design that will be most
> adaptable over the set of all possible future evolutions of the
> system. I remember that this was my major takeaway from ASD - PPP.
>
> Striving for simplicity and expressiveness is the recommended agile
> strategy for designing for evolution. TDD and Refactoring are
> recommended techniques for executing that strategy.
>
> Steve
Back to top
Reply to sender | Reply to group | Reply via web post
Messages in this topic (10)
2g.
Re: Incremental design material (was YAGNI Football Analogy)
Posted by: "George Dinwiddie" lists@idiacomputing.com gdinwiddie
Sun May 11, 2008 12:14 pm (PDT)
Kim Gräsman wrote:
> Hi Ilja,
>
> Thanks for answering.
>
> On Sun, May 11, 2008 at 2:32 PM, Ilja Preuss <it@iljapreuss.de> wrote:
>> I'd think that "Refactoring" by Martin Fowler would be the seminal work.
>>
>> "Agile Software Development - Principles, Patterns and Practices" also
>> seems like it would fit.
>
> I've read both of them, but maybe not with the right glasses on.
Uncle Bob's articles on Object Oriented Design Principles (on the
objectmentor.com site) might also be good. I'm sure the same things are
brought up in the book, but the older articles might be more in line
with what you're seeking.
- George
--
----------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------
Back to top
Reply to sender | Reply to group | Reply via web post
Messages in this topic (10)
2h.
Re: Incremental design material (was YAGNI Football Analogy)
Posted by: "Carlo Bottiglieri" carlo.bottiglieri@gmail.com invernomutoai
Sun May 11, 2008 2:31 pm (PDT)
Hello,
> [Snap]. What aspects of code make it suitable for
> evolution? Simplicity, sure. Singularity, yes. Abstraction?
> Reversibility? Strict obedience of all of Uncle Bob's OO principles
> ;-)?
In my very limited experience the one aspect that most influences the
ability to evolve an existing design into the next feature is code
duplication, whenever explicit or not, simply because very few
structural changes are difficult if all distinct logic is single, I
agree on cohesion, but it is my humble opinion that it can be tackled
quickly if the system is dry, so duplication ranks first. At the same
time, strict dryness usually requires well encapsulated and thus well
expressed concept.
I've also noticed that it is very hard for an existing system to not
show some form of duplication if it doesn't obey Martin's principles
to the extent required by its domain complexity, but I would be
dubious of the opposite, so, while I would use them for diagnosis I
would not use them as a metric.
Finally, most decisions which are localized in a single point are
usually reversible, so I would still look at duplication first.
>
> I'll go back to my books and do some more thinking...
>
> Thanks,
> - Kim
>
> [1] http://martinfowler.com/articles/designDead.html
> [2] http://www.martinfowler.com/ieeeSoftware/continuousDesign.pdf
>
>
> On Sun, May 11, 2008 at 4:24 PM, Steven Gordon <sgordonphd@gmail.com>
> wrote:
> >
> > On Sun, May 11, 2008 at 6:56 AM, Kim Gräsman <kim.grasman@gmail.com>
> wrote:
> > >
> > > Hi Ilja,
> > >
> > > Thanks for answering.
> > >
> > > On Sun, May 11, 2008 at 2:32 PM, Ilja Preuss <it@iljapreuss.de> wrote:
> > > > I'd think that "Refactoring" by Martin Fowler would be the seminal
> work.
> > > >
> > > > "Agile Software Development - Principles, Patterns and Practices"
> also
> > > > seems like it would fit.
> > >
> > > I've read both of them, but maybe not with the right glasses on.
> > >
> > > I guess I'm looking for practical advice on how to design for
> > > evolution. I suppose /Refactoring/ has enough tips in it that it might
> > > fit the bill... I'll read it again and see how it feels.
> >
> > Maybe the advice will seem too theoretical - the simpler and more
> > expressive the code is, the easier it is to adapt it to the next new
> > requirement.
> >
> > So, by not trying to explicitly design for future requirements, but
> > instead focussing on creating the simplest and most expressive code
> > for the current requirements, we create the design that will be most
> > adaptable over the set of all possible future evolutions of the
> > system. I remember that this was my major takeaway from ASD - PPP.
> >
> > Striving for simplicity and expressiveness is the recommended agile
> > strategy for designing for evolution. TDD and Refactoring are
> > recommended techniques for executing that strategy.
> >
> > Steve
>
2i.
Re: Incremental design material (was YAGNI Football Analogy)
Posted by: "Ron Jeffries" ronjeffries@XProgramming.com RonaldEJeffries
Sun May 11, 2008 3:04 pm (PDT)
Hello, Kim. On Sunday, May 11, 2008, at 2:49:30 PM, you wrote:
> Yes, I see the same truths repeated and they are good, but I think
> there's more to it than simplicity. For me, Beck's bullet point list
> for simple design is too reduced. It sounds clear and concise, but I
> find there's something missing for me to relate it to my own design
> activities. Narrative, perhaps, I'm not sure.
3. The code expresses all your design ideas might be part of what
you are looking for. What do you mean when you say "narrative"?
Ron Jeffries
www.XProgramming.com
Without practice, no emergence. -- Dougen Zenji
3a.
Re: Executable Specifications
Posted by: "Gary Brown" glbrown@inebraska.com gb70840
Sun May 11, 2008 6:44 am (PDT)
Hi, Josh,
----- Original Message -----
From: "Joshua Kerievsky" <joshua@industriallogic.com>
To: <extremeprogramming@yahoogroups.com>
Sent: Friday, May 09, 2008 11:44 AM
Subject: Re: [XP] Re: Executable Specifications
> Gary,
>
> Of late (and after years of doing FIT), we're now using Selenium RC
> (Remote
> Control) with xUnit (JUnit, NUnit, etc) for Storytest-Driven Development
> (SDD).
>
> Consider this storytest:
>
> class StudentTakesSingleSelectQuizTest...
> public void testStudentChoosesCorrectAnswer() {
> navigateToTwoPlusTwoQuiz();
> pickAnswerOfFour();
> showAnswers();
> verifyAnswerOfFourIsReportedCorrect();
> verifyAnswersOfOneAndFiveAreReportedIncorrect();
> verifyStudentToldOfChoosingCorrectly();
> }
>
> Note how we're embedding "example" data in method names. We also embed
> example data via parameters, like so:
>
> class UserPostsFeedbackTests...
> public void testPostingAllFeedbackTypes() {
> navigateToContentPage();
> verifyFeedbackCounts(0, 0, 0);
>
> openFeedbackDialog();
>
> String subject = "This is a question";
> String body = "The quick brown fox jumps over the lazy dog.";
> postAQuestion(subject, body);
> verifyQuestionPosted(subject, body);
>
> subject = "This is a test comment";
> body = "All work and no play makes Jack a dull boy.";
> postAComment(subject, body);
> verifyCommentPosted(subject, body);
>
> String errorSubject = "This is a test error and it's a good one";
> body = "Fourscore and seven years ago";
> postAnError(errorSubject, body);
> verifyErrorPosted(subject, body);
>
> closeFeedbackDialog();
> verifyFeedbackCounts(1, 1, 1);
> }
>
> The idea is that non-technical customers (including QA) help specify
> storytests (on a whiteboard, document, whatever) and programmers automate
> in
> an OO environment (where we have re-use, superclasses, helper
> methods/classes, etc). The trick is to produce the automated storytests
> in a way that preserves their readability to non-techies. We run a
> script
> to extract the storytests (and not any helper methods) so that customers
> can
> easily study what storytests they have.
>
> This is definitely a departure from using documents hooked up to fixtures
> hooked up to production code. When time permits, I could describe why
> we've
> abandoned that approach.
Very interesting! This could work for us, since our developers write most
of the acceptance tests.
How do you get the QAs to trust the developer tests? Since QAs tend toward
a much more comprehensive testing approach than developers, are you able to
automate all of their ideas?
Thanks!
GB.
No comments:
Post a Comment