Agile vs. waterfall ?!

[LudovicoVan]

Agile vs. waterfall is another one we should clearly stand against: it's just the marketing of a false dichotomy, but it is as wrong and a damage as it can be because it promotes massive misconceptions not only about the software process but about the very state of the art.

Rather than setting up primary schools on the art of tying shoelaces, we'd better focus on getting the basics straight.

-LV

[RonJeffries]

Lucovico,

On Nov 8, 2012, at 6:54 PM, LudovicoVan <ju...@diegidio.name> wrote:

Rather than setting up primary schools on the art of tying shoelaces, we'd better focus on getting the basics straight.

So ... in your view ... what are "the basics"?

Ron Jeffries

www.XProgramming.com

I know we always like to say it'll be easier to do it now than it

will be to do it later. Not likely. I plan to be smarter later than

I am now, so I think it'll be just as easy later, maybe even easier.

Why pay now when we can pay later?

[LudovicoVan]

On Friday, 9 November 2012 00:47:37 UTC, Ron Jeffries wrote:

> So ... in your view ... what are "the basics"?

Get a book on SE, will you?  IOW, it is clear what the basics are to those who know the basics, the point was about commitment and professional integrity.

 

In fact, the topic here specifically was "Agile vs. Waterfall, the big scum".  Any comments young lad?

 

-LV

 

[RonJeffries]

Ludovico,

On Nov 9, 2012, at 6:40 AM, LudovicoVan <ju...@diegidio.name> wrote:

Get a book on SE, will you?  IOW, it is clear what the basics are to those who know the basics, the point was about commitment and professional integrity.

For my sins, I hold advanced degrees in mathematics and computer science. I was asking YOU what YOU think the basics are. Your reply is quite illuminating.

 

In fact, the topic here specifically was "Agile vs. Waterfall, the big scum".  Any comments young lad?

I've worked both ways. I know which has worked better for me. I've worked with many teams who have worked both ways. I know what worked best for them. I've studied and worked in the area for a half century, and paid attention while doing it, so not only do I know what has worked, I know rather a lot about why.

What do you know, Ludovico, and how do you know it?

Ron Jeffries

www.XProgramming.com

If not now, when? -- Rabbi Hillel

[LudovicoVan]

On Friday, 9 November 2012 13:07:43 UTC, Ron Jeffries wrote:

> What do you know, Ludovico, and how do you know it?

I know that you are just dodging the question, Ron, and just trying the usual personal attack instead.

Anyway, as just a starting hint to the not so skilled, agility is *orthogonal* to the software process models, so that agility vs. waterfall is plain pure nonsense.  Just to begin with.

-LV

 

[Corey Haines]

Okay, let's stop this before it gets further into nonsense.

This list is civil and not a place to play 'look who is bigger'

I'm also curious about what LV considers 'the basics,' but it seems like the answer was 'what is in a software engineering book.' Let's leave it at that.

-Corey

--
You received this message because you are subscribed to the Google Groups "software_craftsmanship" group.
To view this discussion on the web visit https://groups.google.com/d/msg/software_craftsmanship/-/LiRzuH8fmpAJ.
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.

[Marcus Milanez]

Hey guys! Keep Calm (e vai Corinthians!) :D

This is a very important and interesting topic/discussion. I'm glad I'm having the chance to read all these arguments and learn with you all - thanks a lot.

2012/11/9 LudovicoVan <ju...@diegidio.name>

 

--

You received this message because you are subscribed to the Google Groups "software_craftsmanship" group.

[LudovicoVan]

On Friday, 9 November 2012 13:21:45 UTC, Corey Haines wrote:

> Okay, let's stop this before it gets further into nonsense.
> This list is civil and not a place to play 'look who is bigger'

Indeed.

> I'm also curious about what LV considers 'the basics,'
 

Feel free to open a specific thread about "the basics": this one remains about "agility vs. waterfall" and what that means.

-LV

[Corey Haines]

Ludovico,

The topic of "agilty vs waterfall" is probably best done on an actual agile mailing list. This is the software craftsmanship list. You'll probably get a better reception and more response to that question on an agile list, such as the XP or Scrum list.

-Corey

-LV

--

You received this message because you are subscribed to the Google Groups "software_craftsmanship" group.

To view this discussion on the web visit https://groups.google.com/d/msg/software_craftsmanship/-/rytqZkQqyCQJ.

[LudovicoVan]

On Friday, 9 November 2012 13:36:13 UTC, Corey Haines wrote:

> The topic of "agilty vs waterfall" is probably best done on an actual agile mailing list. This is the software craftsmanship list. You'll probably get a better reception and more response to that question on an agile list, such as the XP or Scrum list.

IMHO, that is just ridiculous and rather testifies how this group too has been hijected.  After all, aren't I entitled to my opinion for how "out of line" it could be?

 

I'll just state the main point again and the relevance in this context, then of course all are free to express their opinion or even just ignore the topic alltogether:

"Agile vs. waterfall is another one we should clearly stand against."

-LV

 

[Dave Rooney]

On 12-11-09 8:41 AM, LudovicoVan wrote:
> "Agile vs. waterfall is another one we should clearly stand against."

What we clearly stand against on this list is shitty software.

There has been great software built with both approaches. If you would
like to discuss the merits and pitfalls of each then please then, as
Corey said, please try process-related lists such as Scrum Development,
Lean/Agile, etc.

Dave...

[Corey Haines]

On Fri, Nov 9, 2012 at 6:41 AM, LudovicoVan <ju...@diegidio.name> wrote:

On Friday, 9 November 2012 13:36:13 UTC, Corey Haines wrote:

> The topic of "agilty vs waterfall" is probably best done on an actual agile mailing list. This is the software craftsmanship list. You'll probably get a better reception and more response to that question on an agile list, such as the XP or Scrum list.

IMHO, that is just ridiculous and rather testifies how this group too has been hijected.  After all, aren't I entitled to my opinion for how "out of line" it could be?

It is true, I've hijacked this list. Sorry about that.

I'll end with what I said on twitter.

Everyone, please don't feed the trolls.

-Corey

 

-LV

 

--
You received this message because you are subscribed to the Google Groups "software_craftsmanship" group.

To view this discussion on the web visit https://groups.google.com/d/msg/software_craftsmanship/-/zeh2NfxRnVgJ.

[Raoul Duke]

On Fri, Nov 9, 2012 at 5:46 AM, Dave Rooney <davero...@gmail.com> wrote:
> What we clearly stand against on this list is shitty software.
>
> There has been great software built with both approaches. If you would like
> to discuss the merits and pitfalls of each then please then, as Corey said,
> please try process-related lists such as Scrum Development, Lean/Agile, etc.

+ lots, well said.

http://alistair.cockburn.us/Characterizing+people+as+non-linear,+first-order+components+in+software+development

[RonJeffries]

I originally wrote this in response to LV's notion that agility is orthogonal to process model, because it isn't. I'm posting it here because there are important implications to craftsmanship that are driven from the process model. I'll put it under a new heading, and if you like, go ahead and ignore it.

The waterfall model as practiced today (not as originally defined) is phase based, with a project consisting of separate phases like analysis, then design, then coding, and then testing. These phases are expected to be gone through just once.

Agile methods, on the other hand, are iterative and incremental. Instead of one long series of phases, Agile projects are made up of a series of short time boxes, called iterations or Sprints. In each of these short iterations, the team builds a version of the product including a subset of its features, but technically complete, that is, embodying good analysis, good design, good coding, and good testing, for all those features. They deliver a low-feature version of the product that is ready for the addition of more features, more good analysis, design, coding, and testing, in the next iteration.

These are quite different, even when observed from the outside. From the outside, the waterfall project delivers usable software only near the end of the project. The Agile project delivers usable software every few weeks, throughout the course of the project. The implication of this difference in observable production is that the Agile project can be managed both differently and more elegantly. Managing the Agile project consists mostly in observing how much is getting done, and deciding what to do next. In the waterfall project, we do not have concrete knowledge of what is done, and need to manage more by metrics and clues.

From the inside, waterfall and Agile are quite different as well. The waterfall project uses different skills at different times. It uses analysis skills early, then design skills, then coding, and then testing. The impact of this is that the personnel on the project change dramatically over time. From the viewpoint of the software, it is like being handed along from an analyst to a designer to a coder to a tester. In the Agile project, the team always does analysis, design, coding, and testing, all in the space of a couple of weeks, so the makeup of the team does not change.

Finally, we can look at what people who work effectively on Agile projects need to do. For best results they need to be quite competent in all of analysis, design, coding, and testing, though of course different people are differently skilled. Since the Agile project creates a product that continually improves, rather than a product that is assembled at the last minute, the Agile team needs skills in incremental development, notably including refactoring. 

In a waterfall project, one expects the design to be mostly figured out, and expects that little will be discovered later on that obviates that planned design. (This rarely happens in practice, which is why Royce's original paper made the point that the waterfall model would not work.) Waterfall projects do not contemplate changing the design, and since they tend to build the design up and only then code to it, when they do run into trouble, they have lots of refactoring to do all at once, not a little bit at a time.

So, no, Agile is not "orthogonal" to method. It enables a particular style of method, incremental and iterative, and thus dominates the more conventional phased approaches such as waterfall-as-done-today.

The meaning for a craft focus is that the balance shifts substantially. It used to be that a long period of design was appropriate, and though it works less well, it meant that we did have lots of time to contemplate and draw pictures. We still need that skill, but we need to be able to do it more rapidly, which implies a lighter tool set, but also a more flexible, rapid approach. At the same time, we know that we will be changing and improving the design, which puts much more weight on refactoring that it has in a more phased approach. Truth is, refactoring came along at the same time as Agile and was not really a topic at all when I was taking that advanced degree in Computer Science.

And if we are going to build incrementally, implying refactoring, we will be changing the code a lot, and the code will contain actual features that are supposed to work. So we must have a growing structure of tests as we go. To me, this isn't some erudite recommendation from someone with his nose in the air. It's practically laws of physics: you're going to change this code, and it needs to work. Therefore you must test it. It is growing. Therefore you must test it more and more. Therefore automated tests are your only hope if you don't want to be hip deep in people doing manual testing. 

And finally, there is something important going on in Test-Driven. It's not unlike the intimacy between mind and computer that one gets in Smalltalk, or Lisp, and less so in languages like Ruby, but there is more to it than that. There is a kind of solidity to working that way, that makes it easier to try things, and keeps the program just getting better.

All in all, the process model calls for different emphasis, and the more modern skills enable a way of working that seems, often if not always, to be better.

[David Harvey]

>>>

And finally, there is something important going on in Test-Driven. It's not unlike the intimacy between mind and computer that one gets in Smalltalk, or Lisp, and less so in languages like Ruby, but there is more to it than that. There is a kind of solidity to working that way, that makes it easier to try things, and keeps the program just getting better.

<<<

Can I just say that this is really important. Really, really important! Ask any musician about their relationship to their instrument - this is what 9for me) goes on when test-driven is firing on all cylinders.

David

------------------
David Harvey
www.teamsandtechnology.com
@david_harvey

--
You received this message because you are subscribed to the Google Groups "software_craftsmanship" group.

[Jason Catena]

> There is a kind of solidity to working that way, that makes it easier to try things, and keeps the program just getting better.

I think we can speak of it more concretely.  With TDD you know that changed software still coheres with its tests, in the same way you know through frequent compilation that it still coheres with the language (or at least compiler), and through continuous integration that it still coheres with others' code.  Whether the tests, language/compiler, or others' code are actually correct and reflect intent isn't proved, but inconsistencies are found more quickly than without these three methods.

Jason Catena

[Emmanuel Gaillot]

Jason,

> I think we can speak of it more concretely. With TDD you know that
> changed software still coheres with its tests, in the same way you know
> through frequent compilation that it still coheres with the language (or
> at least compiler), and through continuous integration that it still
> coheres with others' code.

I think we can speak of it even more concretely ;)

I like to think of code as matter - the (not so physical) substance we
manipulate - and of TDD as the process through which we build a sensory
envelope that enable us to "feel" the code. With this sensory envelope
we have the means to know when we "break" the code, when it "resists"
refactoring, usw.

In this sense, TDD is what enables the coder to physically engage with
their work, much like touch, smell and vision does it to the regular
craftsman.

Yours,
-- Emmanuel.

[Curtis Cooley]

Ron,

Have you written this up as a blog? I'm coaching at a company and
everyone involved would greatly benefit by reading something like
this. I know there's similar content out there, and I preach these
concepts daily, but I think you've really captured it here.

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

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

[Curtis Cooley]

On Fri, Nov 9, 2012 at 5:15 AM, LudovicoVan <ju...@diegidio.name> wrote:
> On Friday, 9 November 2012 13:07:43 UTC, Ron Jeffries wrote:
>
>> What do you know, Ludovico, and how do you know it?
>
> I know that you are just dodging the question, Ron, and just trying the
> usual personal attack instead.
>

Hmm, interesting. I'm not seeing that, and I've never seen Ron take
that approach. I believe he's trying to use Socratic questioning to
engage in meaningful conversation.

It's a communication and listening method that has many names, but
basically the strategy is:
1. Please tell me everything about what you believe and why you
believe it, so I can understand your perspective.
2. Please allow me to explain what I believe and why so you can
understand from my perspective.
Until we have that shared level of understanding, we're arguing
without communicating.

> Anyway, as just a starting hint to the not so skilled, agility is
> *orthogonal* to the software process models, so that agility vs. waterfall
> is plain pure nonsense. Just to begin with.
>

If you are saying the skills required to be agile are orthogonal to
software process models, I might agree. Those same skills apply across
processes. I do think Agile describes a set of processes which
Waterfall is not a member, so Agile vs Waterfall seems to make sense
to me.

I'm also confused about what it means for a software craftsmanship
group to be against Agile vs Waterfall.

[Marcus Milanez]

Thanks for writing this valuable email Jon. I appreciate it !

2012/11/9 RonJeffries <ronje...@acm.org>

[RonJeffries]

Hi Curtis ...

On Nov 12, 2012, at 11:38 AM, Curtis Cooley <curtis...@gmail.com> wrote:

Have you written this up as a blog? I'm coaching at a company and
everyone involved would greatly benefit by reading something like
this. I know there's similar content out there, and I preach these
concepts daily, but I think you've really captured it here.

Then use it! Or does it need to be on the web somewhere to become true?

[Tim Ottinger]

No, but if it is on the web, written by someone else, then it doesn't look like the coach just made that crap up.  

With a little verification It would have to be a conspiracy, or an occupational neurosis. :-)

Not to mention that sometimes other people express themselves in different ways, and that helps reach people who don't learn exactly the way we teach. This is the more important of the two effects of having it written up somewhere.

In a moment of desperation, you can tell me something deeply true and intelligent-sounding and I can give blogging it a shot. 

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

--
Tim
----
http://www.industriallogic.com/

[RonJeffries]

Hi Tim,

On Nov 12, 2012, at 4:22 PM, Tim Ottinger <tott...@industriallogic.com> wrote:

No, but if it is on the web, written by someone else, then it doesn't look like the coach just made that crap up.  

With a little verification It would have to be a conspiracy, or an occupational neurosis. :-)

Not to mention that sometimes other people express themselves in different ways, and that helps reach people who don't learn exactly the way we teach. This is the more important of the two effects of having it written up somewhere.

In a moment of desperation, you can tell me something deeply true and intelligent-sounding and I can give blogging it a shot. 

Well, I was thinking I had already written it, just now and was not clear how it'd be more official if I put it on the web since, after all, it already is ...

Ron Jeffries

www.XProgramming.com

I try to Zen through it and keep my voice very mellow and low.

Inside I am screaming and have a machine gun.

Yin and Yang I figure.

  -- Tom Jeffries

[John Goodsen]

Curtis, your next challenge is to get people to actually read it  bhwaaa haaa haaa  :)