Paul Gielens:ThoughtsService

IMHO, you need to take enough time to think things through to such an extend that you know for sure you've examined all the situations and know the consequences when you take any step forward.

XP tends to fall short on that 'enough time', at least in my opinion. Often I hear: "But XP does a thourough analysis phase too!", but that isn't XP, that's just plain old software design with 2 people behind the same keyboard.

Thought experiment: imagine a system where you can have a given piece of functionality, F, architectured in two ways, A and B. A and B are paradigmatically different, though share common code. If you look closely, A is a specialization of B, that is, if B's design exists when you design A.

Now, what if A exists in design, and not B? What if preliminairy research suggests, A is the way to go, and it is build (After all, XP is all about writing the here and now, not considering about what will happen eventually in 3 years from now). After some time, B is required as well, but you already have A implemented, while A could also be build as an extension of B, though that's now no longer possible because A's already in use, interfaces are defined, and it would take a huge refactoring process to make A be an extension of B.

I believe that with proper research, and WITH considering what could happen in the future, A and B would have been considered before the project would have been implemented, which would have resulted in the proper design: A as extension of B.

Another gripe of me with XP is that they seem to think that refactoring is free. It's not. Refactoring is very expensive. The more you can AVOID refactoring, the better it is.

I'm not sure I totally understand what Frans is saying with all the A's and B's. :)

But I don't think Frans is completely right on the refactoring bit. Also because he might mean what's discussed in this topic : http://www.agileprogrammer.com/geeknoise/archive/2005/10/10/8491.aspx

Nobody says refactoring is free. But I think every developer benefits from the fact that you first write the simplest working version, before writing a more generic version that can be used from within multiple locations in your code.

Example: Opening a connection, setting up some sqlcommand object, setting up parameters, filling these, execute it, close it, etc. Write it first in one method.

Refactoring comes up, now refactor things out you can use again. In this example, about every line of code. Now you KNOW how it's supposed to look, how it's supposed to work, and if anything should've come up, you have already bumped into it, because you've already done it once.

So when you're done, you might have something like the EntLib Data Acces Block, where every generic function has been refactored out.

Of course this is an example that has been done a million times or more, but I hope you get the point :)

Now, about the part Paul discusses, the enterprise architecture. Every example that's discussed in design, is always something really really small. Customer <-> Order. I haven't seen anything yet that's really big.

But I know people like Fowler en Uncle Bob have done XP projects with dozens of developers, all split up in several smaller teams. So there HAS been thought about the bigger enterprise architectures, but they might not have been discussed.

Man do we need that discussion platform Paul and I have been talking about! ;)

To be more clear...

XP does EDUF (Enough Design Up Front)
instead of
BDUF (Big Design Up Front)

The difference is like, when you start a project, you consider what has to be done, what has to be developed, how long it'll take, do some analysis, etc, etc. The inception phase.

Then the next step is skipped, and that's the BDUP part. Drawing every piece of software that is to be developed in many, many UML diagrams. I've done that, it doesn't work. Or at least I've seen people trying! ;)

I've also been on a project where people have thought of the design and just had draw a few classes, from which I had to generate code from some case tool. After two weeks, the design was already completely upside down.

Call it lack of design experience, call it lack of whatever experience. The requirements were pretty vague and the result soon was that nothing was lack of the little design that was made. Just start coding and Design All The Time! :)

Funny thing is Frans’s view is a bit different and we’re both basically on the same line. Although he does have a point! Looking back at this project I think people spent too much time on the overall architecture which changed drastically late in the process. I must admit a big architecture change is questionable, but you have to trust me on this one... it makes sense. I think that in this case, in Frans’s head bells start ringing and warning signs pop-up where we just live with the change. I discussed this yesterday with my team lead:
When have you examined enough and know the consequences to take that one step forward? What are the criteria's for such a milestone? Under what circumstances do you fail? Should you look beyond one, two weeks, months, or years (considering the lifecycle of your application) regarding to architecture. And if you can come up with criteria’s for architecture, what about design?

What is Architecture becomes Architecture in an Agile World

In my experience as an Agile software development coach (and a developer/designer in former lives within waterfall stylemethods), BDUF in Waterfall is about speculation: we have to meet this criterion for the app. We think by implementing this mechanism we will not run intoi the perceived problem.

The Agile angle is a different one: Learn. So for a percieved problem you try a solution after some thoughts and peer-questioning (done within a few hours-->EDUF) implement it AND measure/test whether the problem exists. The measurement is done based on a criterium specified. If the perceived problem exists...find another solution. If it does not exist...keep measuring! And nine out of ten times this is just enough...ironically

Cheers
Peter