Topics

What does "Evolutionary Design" mean to you?


Jim Shore
 

Hey y’all,

Let’s talk about code. Evolutionary Design is my very favorite XP practice, but also the one that took me the longest to accept. It’s also the hardest to teach, I think, and the one that seems to get the least traction.

What does Evolutionary Design mean to you? How do you describe it? Convince people to try it? Teach it?

Cheers,
James

--
James Shore - The Art of Agile

voice: +1 503-267-5490
blog: http://jamesshore.com


Avi Kessner
 

I think the term "evolutionary design" evokes ideas of design which is emergent and just happens without thought. And I think that is why it's hard to grasp.

I think a better way to think about it is as the coming together of iterative design, backwards compatibility, and test driven design. After you lay down the foundation for those ideas, then you can give it the label of evolutionary design, because it makes sense. But I think when you introduce the label first, it anchors the wrong impression which the students then needs to fight against as they systhesize the new ideas.

On Wed, Jun 24, 2020, 23:35 Jim Shore <jshore@...> wrote:
Hey y’all,

Let’s talk about code. Evolutionary Design is my very favorite XP practice, but also the one that took me the longest to accept. It’s also the hardest to teach, I think, and the one that seems to get the least traction.

What does Evolutionary Design mean to you? How do you describe it? Convince people to try it? Teach it?

Cheers,
James

--
James Shore - The Art of Agile

voice: +1 503-267-5490
blog: http://jamesshore.com


Steve Ropa
 

Might be over simplistic, but I like to say its like a polaroid photo, where you see the design emerge over time.  So far I haven’t had anyone recommend waving the code in the air to get it to develop faster..

 

From: extremeprogramming@groups.io <extremeprogramming@groups.io> On Behalf Of Jim Shore
Sent: Wednesday, June 24, 2020 2:35 PM
To: extremeprogramming@groups.io
Subject: [extremeprogramming] What does "Evolutionary Design" mean to you?

 

Hey y’all,

 

Let’s talk about code. Evolutionary Design is my very favorite XP practice, but also the one that took me the longest to accept. It’s also the hardest to teach, I think, and the one that seems to get the least traction.

 

What does Evolutionary Design mean to you? How do you describe it? Convince people to try it? Teach it?

 

Cheers,

James

--
James Shore - The Art of Agile

voice: +1 503-267-5490
blog: http://jamesshore.com

 


Jeff Langr
 

Hi James,

I've been using the phrase "continuous design" and had started a book on it. I suggest to developers that every choice they make in or about code is some aspect of design. They make choices at the outset of a project, during planning for a feature, and as they build a feature--every day, every few minutes as they build code. With a continuous design mentality, they address design concerns every few minutes in order to help minimize costs--and also make life easier for themselves.

I think there's appeal for many folks that everything they do matters. Maybe it also discourages people who think they can just slap stuff out. (Not that I'd deliberately discourage developers; I only try to help them see how what they can do helps them directly, as well as their teammates and their product/company.)

As far as teaching it, nothing works better than sitting with them and test-driving some feature or reshaping their existing code--helping them get their work done. If we've decided that everything they code is some facet of design, then convincing them to try it is a matter of getting them to allow me to work with them. I only ask that we stop and fix design issues--theirs and mine--as we create them, or as existing ones are slowing us down.

Most of my emphasis, then, is on how much effort they have to expend in order to understand code or add to it. Generally their eyes light up when they see how much time they can save (time that they're currently costing themselves and others). Many of them find the ability to build direct, simple, and concise code appealing. I'll stop & pause and do a couple before/after comparisons to let the differences sink in, anytime there's a clear win from what we've done.

Modern (newer) developers appreciate the emphasis on simple design, in that they don't have to go read some stodgy old book to learn a bunch of principles & patterns, something many of us here grew up on. (They learn a lot of that, incrementally, as I sit with them over time.) If I go read the first sentence of wikipedia's page on software design, it says: "Software design is the process by which an agent creates a  specification of a software artifact... blah blah." Yeah, none of these modern devs want to do that.

The big pushback to continuous design is of course from devs who insist that they need an end-all solution now, and that it has to be completely implemented now even if the design represents a speculative need.

About three years ago I spent 3 days teaching TDD to a bunch of C++ devs. The first two days I thought I'd lost them with the amount of angst they had over the idea of deferring such "necessary" complexity. (It helps to have some exercises to suggest their speculative designs aren't going to hold up anyway to left-field-but-realistic feature requests.) Day 2, I ended up in debate with someone who was insistent on pressing the issue for almost 10 minutes straight. (Not usually a good thing to do--I could see others' eyes glazing over.)  I stopped & reminded them that they were here to learn how to build things incrementally, and that they should continue to work through exercises with that in mind; that seemed to calm them down a bit. On the third day I was still nervous, but I ended up receiving some of the best feedback I'd had across 18 years. Patience, listening, and repeating some of the core goals helped. Letting things sink in overnight seems to help. They're still doing TDD last time I checked.

Such initial resistance is typical, but maybe the worst I'd encountered in that class. People don't learn new habits overnight. Three days barely scratches the surface, so sitting with them as they work through real stuff, and showing how things play out, is critical. It can be months before better habits stick.

Mobbing makes this a lot easier.

Jeff


Jim Shore wrote on 6/24/20 2:35 PM:

Hey y’all,

Let’s talk about code. Evolutionary Design is my very favorite XP practice, but also the one that took me the longest to accept. It’s also the hardest to teach, I think, and the one that seems to get the least traction.

What does Evolutionary Design mean to you? How do you describe it? Convince people to try it? Teach it?

Cheers,
James


Dave Nicolette
 

How I describe it:

To me, evolutionary design means to begin development with the
following elements:

1. Team's collective knowledge and experience about solutions similar
to the one at hand. In my opinion all of that counts as part of our
up-front design for our next project. Everything we've learned over
the years. We aren't really starting completely from scratch, except
maybe in our first university class or our first self-directed
learning exercise.

2. A team-agreed selection of a reference architecture or a custom
variant of a reference architecture, already known (or reasonably
expected) to fit the planned solution. After all, we know an Android
app is an Android app, an MVC webapp is an MVC webapp, a RESTful
service is a RESTful service, a mainframe ETL process is a mainframe
ETL process, etc. There aren't too many architectural mysteries in the
world of generic business application development. Of course, that's
not the only type of development in the world, but it's basically what
I do, so it's what I understand.

3. Team consensus about a general direction for the low-level design,
subject to change as things are learned.

4. A selection of development tools that supports a test-driven
approach without too much hassle. That's not a problem on most
platforms these days.

Then, during development: Use TDD to allow a low-level design to
emerge naturally. Refactor freely. Revise or replace the initial
design direction as appropriate based on lessons learned. Lots of
feedback and discussion. Lots of code discarded along the way. Small
steps, generally.

So, it's only the low-level technical design that emerges, usually.
Not literally every aspect of design. It's like starting with a broad
outline and then filling in the gaps. Sometimes that leads to more
extensive architectural changes, but not very often, as we started
with a well-known reference architecture that already fits the
situation. Only in the rare case when we're working on something that
is truly novel would we have to "discover" or "invent" an
architectural design. This is in line with the Principle of Least
Astonishment.

How do I convince people to try it?

I'm not much of a convincer. If the team members are hesitant about
evolutionary design, I'll often avoid the buzzwords and say things
like "What if we try this?" or "Can we explore this idea a little
bit?" But I have to be sitting with and working with team members to
do that. Just talking isn't effective. And I don't have "a way" of
convincing people or a personal need to do so. If they see it in
action and they still don't want to do it, that's okay with me. I
don't live their lives for them. And most people are smarter than me
anyway, so it's always quite possible they know a better way. I don't
mind learning from them. That's the way I learned this stuff in the
first place - someone smarter than me showed me a better way than I
knew at the time.

Teach it?

Depends on the situation. In many coaching situations, a code dojo or
similar event is well received. If the client is already used to
having regular tech events like that, or community of practice
sessions or what-not, it's easy to make "evolutionary design" the
topic of one of them. Otherwise, teaching happens piecemeal in the
course of mentoring during real work, in the team's context. In some
cases, teams are open to Mob Programming as a learning mechanism, or
just as a way to do everyday work. I find that format lends itself
nicely to teaching practices like evolutionary design.

For straight-up training, my lesson plans include evolutionary design
in the context of other skills such as test-driven development, like
this one: https://neopragma.com/training/courses/course-tdd-01-3/. But
in that case, people sign up for a training course and they don't have
to be convinced or "tricked" into trying it. They've already decided
to try it.

That's my take, anyway, FWIW. Hope it helps.
Dave

On Wed, Jun 24, 2020 at 1:35 PM Jim Shore <jshore@...> wrote:

Hey y’all,

Let’s talk about code. Evolutionary Design is my very favorite XP practice, but also the one that took me the longest to accept. It’s also the hardest to teach, I think, and the one that seems to get the least traction.

What does Evolutionary Design mean to you? How do you describe it? Convince people to try it? Teach it?

Cheers,
James

--
James Shore - The Art of Agile

voice: +1 503-267-5490
blog: http://jamesshore.com


Andres Joaquin
 

When we talk about of "Evolutionary Architecture" or "Agile Architecture" are we talking about the same thing than when we talk about "Evolutionary Design"? 

I'm asking this because I usually found myself (right or wrong) using these terms instead of "Evolutionary Design" to express the same concept. I found that using these alternative terms it is more easy (at least for me) to teach it or just to have a conversation with other programmers.


On Wed, Jun 24, 2020 at 5:35 PM Jim Shore <jshore@...> wrote:
Hey y’all,

Let’s talk about code. Evolutionary Design is my very favorite XP practice, but also the one that took me the longest to accept. It’s also the hardest to teach, I think, and the one that seems to get the least traction.

What does Evolutionary Design mean to you? How do you describe it? Convince people to try it? Teach it?

Cheers,
James

--
James Shore - The Art of Agile

voice: +1 503-267-5490
blog: http://jamesshore.com


Jim Shore
 

There’s a book called “Building Evolutionary Architecture,” http://evolutionaryarchitecture.com/index.html, which I haven’t read. But one of the authors gave a talk at Yow! a few years ago that I did watch:


From this I concluded that evolutionary design and evolutionary architecture are very tangentially related, if at all.

James

On Jun 24, 2020, at 2:38 PM, Andres Joaquin <andresjoaquin@...> wrote:

When we talk about of "Evolutionary Architecture" or "Agile Architecture" are we talking about the same thing than when we talk about "Evolutionary Design"? 

I'm asking this because I usually found myself (right or wrong) using these terms instead of "Evolutionary Design" to express the same concept. I found that using these alternative terms it is more easy (at least for me) to teach it or just to have a conversation with other programmers.

On Wed, Jun 24, 2020 at 5:35 PM Jim Shore <jshore@...> wrote:
Hey y’all,

Let’s talk about code. Evolutionary Design is my very favorite XP practice, but also the one that took me the longest to accept. It’s also the hardest to teach, I think, and the one that seems to get the least traction.

What does Evolutionary Design mean to you? How do you describe it? Convince people to try it? Teach it?

Cheers,
James

--
James Shore - The Art of Agile

voice: +1 503-267-5490
blog: http://jamesshore.com





Dave Nicolette
 

You haven't read that book? Ha! That's nothing. There's a million
books I haven't read. I'm way ahead of you in the not-reading
department!

On Wed, Jun 24, 2020 at 2:41 PM Jim Shore <jshore@...> wrote:

There’s a book called “Building Evolutionary Architecture,” http://evolutionaryarchitecture.com/index.html, which I haven’t read. But one of the authors gave a talk at Yow! a few years ago that I did watch:

https://www.youtube.com/watch?v=-Z_Va9iWo0I

From this I concluded that evolutionary design and evolutionary architecture are very tangentially related, if at all.

James

On Jun 24, 2020, at 2:38 PM, Andres Joaquin <andresjoaquin@...> wrote:

When we talk about of "Evolutionary Architecture" or "Agile Architecture" are we talking about the same thing than when we talk about "Evolutionary Design"?

I'm asking this because I usually found myself (right or wrong) using these terms instead of "Evolutionary Design" to express the same concept. I found that using these alternative terms it is more easy (at least for me) to teach it or just to have a conversation with other programmers.

On Wed, Jun 24, 2020 at 5:35 PM Jim Shore <jshore@...> wrote:

Hey y’all,

Let’s talk about code. Evolutionary Design is my very favorite XP practice, but also the one that took me the longest to accept. It’s also the hardest to teach, I think, and the one that seems to get the least traction.

What does Evolutionary Design mean to you? How do you describe it? Convince people to try it? Teach it?

Cheers,
James

--
James Shore - The Art of Agile

voice: +1 503-267-5490
blog: http://jamesshore.com



Jim Shore
 

I don’t know, I’m putting up some stiff competition in the “books I haven’t read” race.

I *did* finally buy GOOS, by Steve Freeman and Nat Pryce, just a few weeks ago. It’s sitting on my shelf looking sorrowfully at me every time I walk by.

On Jun 24, 2020, at 2:46 PM, Dave Nicolette <davenicolette@...> wrote:

You haven't read that book? Ha! That's nothing. There's a million
books I haven't read. I'm way ahead of you in the not-reading
department!

On Wed, Jun 24, 2020 at 2:41 PM Jim Shore <jshore@...> wrote:

There’s a book called “Building Evolutionary Architecture,” http://evolutionaryarchitecture.com/index.html, which I haven’t read. But one of the authors gave a talk at Yow! a few years ago that I did watch:

https://www.youtube.com/watch?v=-Z_Va9iWo0I

From this I concluded that evolutionary design and evolutionary architecture are very tangentially related, if at all.

James

On Jun 24, 2020, at 2:38 PM, Andres Joaquin <andresjoaquin@...> wrote:

When we talk about of "Evolutionary Architecture" or "Agile Architecture" are we talking about the same thing than when we talk about "Evolutionary Design"?

I'm asking this because I usually found myself (right or wrong) using these terms instead of "Evolutionary Design" to express the same concept. I found that using these alternative terms it is more easy (at least for me) to teach it or just to have a conversation with other programmers.

On Wed, Jun 24, 2020 at 5:35 PM Jim Shore <jshore@...> wrote:

Hey y’all,

Let’s talk about code. Evolutionary Design is my very favorite XP practice, but also the one that took me the longest to accept. It’s also the hardest to teach, I think, and the one that seems to get the least traction.

What does Evolutionary Design mean to you? How do you describe it? Convince people to try it? Teach it?

Cheers,
James

--
James Shore - The Art of Agile

voice: +1 503-267-5490
blog: http://jamesshore.com




Jeff Langr
 

section 4 ("sustainable test-driven development") has a lot of great stuff in it...


Jim Shore wrote on 6/24/20 3:49 PM:

I don’t know, I’m putting up some stiff competition in the “books I haven’t read” race.

I *did* finally buy GOOS, by Steve Freeman and Nat Pryce, just a few weeks ago. It’s sitting on my shelf looking sorrowfully at me every time I walk by.

On Jun 24, 2020, at 2:46 PM, Dave Nicolette <davenicolette@...> wrote:

You haven't read that book? Ha! That's nothing. There's a million
books I haven't read. I'm way ahead of you in the not-reading
department!

On Wed, Jun 24, 2020 at 2:41 PM Jim Shore <jshore@...> wrote:
There’s a book called “Building Evolutionary Architecture,” http://evolutionaryarchitecture.com/index.html, which I haven’t read. But one of the authors gave a talk at Yow! a few years ago that I did watch:

https://www.youtube.com/watch?v=-Z_Va9iWo0I

>From this I concluded that evolutionary design and evolutionary architecture are very tangentially related, if at all.

James

On Jun 24, 2020, at 2:38 PM, Andres Joaquin <andresjoaquin@...> wrote:

When we talk about of "Evolutionary Architecture" or "Agile Architecture" are we talking about the same thing than when we talk about "Evolutionary Design"?

I'm asking this because I usually found myself (right or wrong) using these terms instead of "Evolutionary Design" to express the same concept. I found that using these alternative terms it is more easy (at least for me) to teach it or just to have a conversation with other programmers.

On Wed, Jun 24, 2020 at 5:35 PM Jim Shore <jshore@...> wrote:
Hey y’all,

Let’s talk about code. Evolutionary Design is my very favorite XP practice, but also the one that took me the longest to accept. It’s also the hardest to teach, I think, and the one that seems to get the least traction.

What does Evolutionary Design mean to you? How do you describe it? Convince people to try it? Teach it?

Cheers,
James

--
James Shore - The Art of Agile

voice: +1 503-267-5490
blog: http://jamesshore.com











Andres Joaquin
 

Are books for reading? It was my understanding that they are only to take a picture of the cover and share it on social media ;-)


On Wed, Jun 24, 2020 at 6:49 PM Jim Shore <jshore@...> wrote:
I don’t know, I’m putting up some stiff competition in the “books I haven’t read” race.

I *did* finally buy GOOS, by Steve Freeman and Nat Pryce, just a few weeks ago. It’s sitting on my shelf looking sorrowfully at me every time I walk by.

> On Jun 24, 2020, at 2:46 PM, Dave Nicolette <davenicolette@...> wrote:
>
> You haven't read that book? Ha! That's nothing. There's a million
> books I haven't read. I'm way ahead of you in the not-reading
> department!
>
> On Wed, Jun 24, 2020 at 2:41 PM Jim Shore <jshore@...> wrote:
>>
>> There’s a book called “Building Evolutionary Architecture,” http://evolutionaryarchitecture.com/index.html, which I haven’t read. But one of the authors gave a talk at Yow! a few years ago that I did watch:
>>
>> https://www.youtube.com/watch?v=-Z_Va9iWo0I
>>
>> From this I concluded that evolutionary design and evolutionary architecture are very tangentially related, if at all.
>>
>> James
>>
>> On Jun 24, 2020, at 2:38 PM, Andres Joaquin <andresjoaquin@...> wrote:
>>
>> When we talk about of "Evolutionary Architecture" or "Agile Architecture" are we talking about the same thing than when we talk about "Evolutionary Design"?
>>
>> I'm asking this because I usually found myself (right or wrong) using these terms instead of "Evolutionary Design" to express the same concept. I found that using these alternative terms it is more easy (at least for me) to teach it or just to have a conversation with other programmers.
>>
>> On Wed, Jun 24, 2020 at 5:35 PM Jim Shore <jshore@...> wrote:
>>>
>>> Hey y’all,
>>>
>>> Let’s talk about code. Evolutionary Design is my very favorite XP practice, but also the one that took me the longest to accept. It’s also the hardest to teach, I think, and the one that seems to get the least traction.
>>>
>>> What does Evolutionary Design mean to you? How do you describe it? Convince people to try it? Teach it?
>>>
>>> Cheers,
>>> James
>>>
>>> --
>>> James Shore - The Art of Agile
>>>
>>> voice: +1 503-267-5490
>>> blog: http://jamesshore.com
>>>
>>>
>>>
>>
>>
>
>
>





Steve Gordon
 

For me the key is having the humility to understand that at the beginning we cannot know what the ultimate design of the system should be (especially if we are not looking at all the requirements ala waterfall).  This means writing code that satisfies the stories we have undertaken so far in a coherent, simple, well-tested way without prematurely committing to design patterns that might have to be untangled and refactored into different design patterns to handle future stories.  It takes discipline to hold off until the appropriate design patterns emerge and the refactor to those patterns.



Mike Hill <mike.hill@...>
 

Jim...

What it means:

1. The design starts by doing one story.
2. The design changes as each additional story is added.
3. The design never covers more than the sum of the current stories + 1.
4. The design is continuously optimized to align with a principle-set.[*].

[*] Say, a house set, or Corey's rules or Beck's ideas or even SOLID if that's your thing.  

How I describe it:
Pretty much the same as I define it.

Convince people to try it:
My whole coaching shtick, but it comes down to showing people tiny steps they can take that make them feel better about what they do, over a good long while. They don't know or much care what path they're headed down, they attend to the fact that each micro-step we take makes them feel they are becoming "better" for their definition of the word.

Teach it:
I don't very much, explicitly, because I don't think it's the kind of thing that can be taught, only learned. (This is an attitude I have and use for a lot of subjects.)

Cheers,
GeePaw


Jay Bazuzi
 

For me:

Definition: I use my sense of code smell and skill at refactoring to adapt the code to changing needs.

Implications:

  • The better I get at that, the less important it becomes to make the initial architecture great.

  • I can start with the best design I know for the current set of features (no speculative generality).

  • I can update the design as new requirements arrive, keeping it always ideal for the current set of requirements.

  • When I learn something new about design (globals are bad?!) then I can update the design to include that new understanding.
Recently I worked on a project that had a brilliant design when it was created almost 20 years ago. As it came to market, they learned more about what customers needed, and bolted new high-value features onto the existing design.

Then the market shifted from Windows to Mac so they switched to a cross-platform UI framework. The new framework had different metaphors so they wrapped the new framework with the old metaphors, keeping everything else the same. 

Then the market shifted from desktop to web, so they replaced the UI layer with a web front-end. 

At each shift, they left the basic design the same, and used brute force to make it do the new thing. 

Now the cost of every new feature is 0.1% feature and 99.9% working through the mess.

The product has been hugely successful, which is why they can afford to pay 1000x for a feature.

-J


On Wed, Jun 24, 2020 at 1:35 PM Jim Shore <jshore@...> wrote:
Hey y’all,

Let’s talk about code. Evolutionary Design is my very favorite XP practice, but also the one that took me the longest to accept. It’s also the hardest to teach, I think, and the one that seems to get the least traction.

What does Evolutionary Design mean to you? How do you describe it? Convince people to try it? Teach it?

Cheers,
James

--
James Shore - The Art of Agile

voice: +1 503-267-5490
blog: http://jamesshore.com


Tim Ottinger
 

I can't really add much to what Jeff L and Geepaw have said, I know. 

But I think about Martin Fowler talking about Long-Term Refactoring, when you realize that the way the code is currently designed is not the way it "wants to be" or "needs to be" designed. 

When we are doing evolutionary design, we look at how things ARE in the codebase; architecture, coding, expression, vocabulary, whatever. We don't just check it off as tracking close to the initial design or the conceptual design of whoever drew the first diagrams, but we think about what it needs/wants/converges on being. And we go there.

It's hard to teach because some people don't want to make any large-scale changes (fear of the code, fear of the time sync, fear of lost productivity, fear of not "scoring points' with the PO, whatever). 

 The harder sell is with people who have been taught that changing the design is "rework waste." If they were any good at design, the myth declares, they would have gotten it "right to begin with" and wouldn't have to do any "reworking." It's an admission of dereliction, wastefulness, and unprofessional conduct. Well, to them.

Both of those, I fear, are very much alive in non-agile (and non-technical-agile) camps.  When you've never had refactorable, testable code then you naturally fear it. When you've always done waterfall, you know that you can't succeed unless the initial analysis and design are correct.  Even if the developer doesn't see it that way, it's likely the managers do -- until they've lived in an agile world. 

A few stray thoughts - I'm working on a refactoring and legacy unit in my current workshop, so this is relevant to me.



Tim Ottinger http://industriallogic.com/ http://agileotter.blogspot.com/


On Wednesday, June 24, 2020, 03:35:11 PM CDT, Jim Shore <jshore@...> wrote:


Hey y’all,

Let’s talk about code. Evolutionary Design is my very favorite XP practice, but also the one that took me the longest to accept. It’s also the hardest to teach, I think, and the one that seems to get the least traction.

What does Evolutionary Design mean to you? How do you describe it? Convince people to try it? Teach it?

Cheers,
James

--
James Shore - The Art of Agile

voice: +1 503-267-5490
blog: http://jamesshore.com


Steve Gordon
 

English is such an ambiguous language.  I totally agree with "but we think about what it needs/wants/converges on being. And we go there.", but only if "we think" means the whole team collaboratively thinks it through and reaches a consensus that there is enough information that a specific convergence is well warranted.  It should not be the refactoring that just one pair does during each TDD cycle, but more like a mob refactoring session.


On Thu, Jun 25, 2020 at 2:17 PM Tim Ottinger via groups.io <linux_tim=yahoo.com@groups.io> wrote:
I can't really add much to what Jeff L and Geepaw have said, I know. 

But I think about Martin Fowler talking about Long-Term Refactoring, when you realize that the way the code is currently designed is not the way it "wants to be" or "needs to be" designed. 

When we are doing evolutionary design, we look at how things ARE in the codebase; architecture, coding, expression, vocabulary, whatever. We don't just check it off as tracking close to the initial design or the conceptual design of whoever drew the first diagrams, but we think about what it needs/wants/converges on being. And we go there.

It's hard to teach because some people don't want to make any large-scale changes (fear of the code, fear of the time sync, fear of lost productivity, fear of not "scoring points' with the PO, whatever). 

 The harder sell is with people who have been taught that changing the design is "rework waste." If they were any good at design, the myth declares, they would have gotten it "right to begin with" and wouldn't have to do any "reworking." It's an admission of dereliction, wastefulness, and unprofessional conduct. Well, to them.

Both of those, I fear, are very much alive in non-agile (and non-technical-agile) camps.  When you've never had refactorable, testable code then you naturally fear it. When you've always done waterfall, you know that you can't succeed unless the initial analysis and design are correct.  Even if the developer doesn't see it that way, it's likely the managers do -- until they've lived in an agile world. 

A few stray thoughts - I'm working on a refactoring and legacy unit in my current workshop, so this is relevant to me.





On Wednesday, June 24, 2020, 03:35:11 PM CDT, Jim Shore <jshore@...> wrote:


Hey y’all,

Let’s talk about code. Evolutionary Design is my very favorite XP practice, but also the one that took me the longest to accept. It’s also the hardest to teach, I think, and the one that seems to get the least traction.

What does Evolutionary Design mean to you? How do you describe it? Convince people to try it? Teach it?

Cheers,
James

--
James Shore - The Art of Agile

voice: +1 503-267-5490
blog: http://jamesshore.com


Phlip
 

"Is it common when you begin to code and then you realize that there's
a better solution, so that you re-write a big part of your code??
Today it happened to me" -- a novice on Twitter


Ron Jeffries
 

Hi ...

Hard to add anything new to the good ideas here, but here's my twist.

On Jun 24, 2020, at 4:35 PM, Jim Shore <jshore@...> wrote:

What does Evolutionary Design mean to you? How do you describe it? Convince people to try it? Teach it?

"Agile" approaches like Scrum and XP call for the incremental production and delivery of the product, real running tested software, feature by feature, week in and week out, from the beginning right on through the end.   This means that in the first few weeks, we'll have a few features, and some fraction of the time to work on the design and architecture of the code. 

Clearly this large product, the one we'll be adding the last few features to a year from now, will have to have a clean, clear, robust design and architecture. We can talk about the properties that such a system must have a year out, and we should think and discuss not just here, but every day during the product development.

To borrow a phrase from Alistair Cockburn, the trick that makes this work is to build in "just barely insufficient" design and architecture every single week, every single day, every single feature. We keep the design as close as we can to "just enough" to support the system as it is today. 

Every day, as we add new capability, the design we have drifts away from the design we need. We keep ourselves aware of that drift, and as soon as we notice a design deficiency -- and there will be plenty -- we relieve that design deficiency by refactoring the code, in small steps, toward the better design that we now see that we need.

Note these things:
  • We must build up a growing understanding of the design we need, or we won't see deficiencies until too late. We think about design all the time.
  • We must make progress in features and capability all the time. We build in our best ideas for design in small steps, day by day.
  • We will discover new and better ideas as we progress, and we do not want to stop to redo vast swaths of work. We learn to make large design improvements in small refactoring steps.
This does require skill. The more skill we have in design, testing, refactoring ... in all the skills of software development ... the better we are able to build software this way.

When we learn how to do this, our job becomes easier, the work goes more smoothly, and the organization sees continuous progress in delivering what they need. 

It's well worth doing.

Ron Jeffries
ronjeffries.com
Isn’t testing quality in a lot like weaving straw into gold?
— George Cameron


Steve Gordon
 

This is what I was trying to express.

More than just software development skills, it also takes humility, patience, restraint, discipline and confidence.

On Fri, Jun 26, 2020 at 5:14 AM Ron Jeffries <ronjeffriesacm@...> wrote:
Hi ...

Hard to add anything new to the good ideas here, but here's my twist.

On Jun 24, 2020, at 4:35 PM, Jim Shore <jshore@...> wrote:

What does Evolutionary Design mean to you? How do you describe it? Convince people to try it? Teach it?

"Agile" approaches like Scrum and XP call for the incremental production and delivery of the product, real running tested software, feature by feature, week in and week out, from the beginning right on through the end.   This means that in the first few weeks, we'll have a few features, and some fraction of the time to work on the design and architecture of the code. 

Clearly this large product, the one we'll be adding the last few features to a year from now, will have to have a clean, clear, robust design and architecture. We can talk about the properties that such a system must have a year out, and we should think and discuss not just here, but every day during the product development.

To borrow a phrase from Alistair Cockburn, the trick that makes this work is to build in "just barely insufficient" design and architecture every single week, every single day, every single feature. We keep the design as close as we can to "just enough" to support the system as it is today. 

Every day, as we add new capability, the design we have drifts away from the design we need. We keep ourselves aware of that drift, and as soon as we notice a design deficiency -- and there will be plenty -- we relieve that design deficiency by refactoring the code, in small steps, toward the better design that we now see that we need.

Note these things:
  • We must build up a growing understanding of the design we need, or we won't see deficiencies until too late. We think about design all the time.
  • We must make progress in features and capability all the time. We build in our best ideas for design in small steps, day by day.
  • We will discover new and better ideas as we progress, and we do not want to stop to redo vast swaths of work. We learn to make large design improvements in small refactoring steps.
This does require skill. The more skill we have in design, testing, refactoring ... in all the skills of software development ... the better we are able to build software this way.

When we learn how to do this, our job becomes easier, the work goes more smoothly, and the organization sees continuous progress in delivering what they need. 

It's well worth doing.

Ron Jeffries
ronjeffries.com
Isn’t testing quality in a lot like weaving straw into gold?
— George Cameron


Jeff Langr
 

Hi Tim!

Tim Ottinger via groups.io wrote on 6/25/20 3:17 PM:

 The harder sell is with people who have been taught that changing the design is "rework waste." If they were any good at design, the myth declares, they would have gotten it "right to begin with" and wouldn't have to do any "reworking." It's an admission of dereliction, wastefulness, and unprofessional conduct. Well, to them.
What's curious to me is that most developer teams really don't do seem to much up-front design anyway. Thoughts on how that reconciles with your statement?

I'll use the writing metaphor sometimes. Good writers get their thoughts on paper first, then come back and reread what they wrote, looking to ensure that it reads well and engages others. "Write for yourself first, then write for others," as Stephen King says.

I never understood the notion that we were supposed to perfectly craft our code first before putting it into the computer. It might have been an ok idea in 1980 (I remember having to fill out coding sheets on one project) when desk-checking was a thing.

Do people really still think that severely about getting code right the first time? I also sense some level of "good enough for now" and "we just have to move on."

Cheers!
Jeff