BT

Are Agile Development Practices Detrimental to Architecture and Design?

by Amr Elssamadisy on Jul 17, 2007 |

Is iterative and incremental development à la Agile practices - where one builds only what is required per iteration - detrimental to good design? Does Scrum encourage ignoring architectural issues? Can design and architecture evolve effectively without the technical Agile practices? Does test-first development lead to good design? Or does the red-green-refactor loop stall at local-minima?

Alan Shalloway of Net Objectives asked the members of the ScrumDevelopment yahoo group about their experience building applications using Scrum if they are finding that the quality of their code holds up:

When I ask people in my courses and at conferences where is the time spent in adding new features to an existing system - writing the feature or integrating it in - typically everyone answers it is in the integration cost. I know this is because most people don't write flexible, extensible, maintainable code incorporating the concepts of design patterns in. Most of these people are also not using Scrum.

Shalloway then explained his concerns in more detail:

... they [developers on a Scrum team] build the system a piece at a time as Scrum tells us to - based on customer value. Sometimes a strong architect on the team will be able to keep things organized well. Many developers have a good sense of stepping back to see where some implementation should be added and then putting it in the right place. But many more don't know that a procedure that is implemented differently will cause redundancy if it is copied and pasted and then changed (even completely). That in this case, a template method may be a better solution.

I may be pessimistic here - but my sense is that if you don't pay attention to things entropy means they will evolve into states you don't want them to. In your case, you were using Scrum to manage the improvement of the thing I think many teams ignore. So my question is:

  1. do people ignore this?
  2. if they do, does it cause a problem?

The responses so far seem to indicate that many using Scrum have this problem even teams that write tests and refactor regularly. We would expect that teams that do not use some variant of the Agile technical practices are in even more trouble. (Remember that Scrum is development-technique agnostic - you can build your software traditionally, with XP, or any other set of technical practices as long as you do so witin the Scrum framework.)

Which brings us to the next point - how effective is the Red-Green-Refactor loop in reality? Even if a team is diligent in writing tests and refactoring mercilessly does this lead to a good design? Paul Jones blogged about how TDD creates Ravioli Code alleging that code developed with TDD creates code that is non-cohesive:

I think that a lot of TDD and test-first idealists and evangelists end up with ravioli code that is well-tested but still difficult to comprehend.

It is probable that Jones doesn't grock TDD because it is much more about design than it is about testing. But this still brings up an interesting point. How well are we in the Agile community using our practices? As the community grows are our practices causing more trouble than we expected? Are these tools more dangerous to those incorrectly using them than traditional development techniques?

Finally, let us assume that we are practicing Scrum correctly and practicing TDD correctly along with it. After all - as Ron Jeffries so eloquently showed us in We Tried Baseball and It Didn't Work - we can't blame the practice if we don't execute it correctly. Does TDD lead to good design? Refactoring is a local optimization technique when used in the Red-Green-Refactor loop. We optimize the design at the local level. This is essentially equivalent to the steepest descent algorithm. That means that refactoring will almost always lead to suboptimal designs as evidenced by the soduko solution using TDD.

Is it time to revisit our practices with a critical eye?

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

It's time to be critical of agile hype by Dean Schulze

We should apply a healthy skepticism towards what agile "experts" say.

Ron Jeffries says that you need to customize your agile process for each project and therefore you can't define an agile process as a collection of practices because those practices will change on each project. (And he's got a lot of company in saying that.) That mentality makes his attempt at sarcasm in "We Tried Baseball and it Didn't Work" either hypocritical or meaningless. If you can't say that an agile process failed because you didn't follow the process - but the process is always different - then how are you supposed to know what process you should have followed?

This is the classic "have it both ways" situation. You have to follow the process, but that process will always change so it can't be defined. If your project failed don't blame the process because you weren't following the right process.

This is nonsense, except from one perspective. It creates opportunities for agile coaches to show you how to customize your agile process for your current project. And how are you to know that the custom process that you paid your agile coach for is the right one for your project? Of course there's no way to know that.

It's all very convenient for the agile coach. Taking metrics for comparison to any other project will always be an apples and oranges comparison because each project used a different agile process. It obviates the need for metrics and any attempt to see if your custom agile process really worked better than something else.

And Amr, if you considered Jeffries article "We Tried Baseball and it Didn't Work" to be eloquent then you need to get better reading material. For an example of an eloquent exposition of complex material read "Chaos" by James Gleick. It's almost 20 years old, but still one of the best examples of writing on technical subjects that I've seen.

Re: It's time to be critical of agile hype by deepak shetty

I agree that the agilists try to have it both ways and is among the things that put me off the most in the agile world (even more than pair programming :) )
Found the "We Tried Baseball and it Didn't Work" ironic because "someone tried cricket/stoolball, didnt work and probably created baseball"
And the real world suggests that Agile practices are no more and no less detrimental than other practices (Its like asking are <insertFavLanguage /> practices detrimental to design/architecture?)
regards
deepak

There's more to incremental design than TDD by James Shore

I agree: traditional approaches to design break down with aggressively short planning horizons of the sort you see with Scrum and other agile methods. TDD alone isn't enough to fill the gap. This is a serious problem with agile methods that don't provide technical practices.

I think Extreme Programming does a nice job of addressing this deficiency. It talks about using simple design, merciless refactoring, and TDD together to achieve "evolutionary" incremental design. In my experience, this approach works very well, leading to elegant, clean design.

The XP approach looks like this (this is excerpted from my upcoming book, The Art of Agile Development):


When TDD is done well, the design of individual classes and methods is beautiful: they're simple, elegant, and easy to use. This isn't enough. Without attention to the interaction between classes, the overall system design will be muddy and confusing.

During TDD, the navigator should also consider a wider scope. Are there similarities between the code you're implementing and other code in the system? Are class responsibilities clearly defined and concepts clearly represented? How well does this class interact with other classes?

When you see a problem, jot it down on your card. During one of the refactoring steps of TDD—usually, when you're not in the middle of something else—bring up the issue that you saw. Discuss solutions with your partner and refactor. If you feel that your design change will significantly affect other members of the team, take a quick break to discuss it around a whiteboard.

Re: There's more to incremental design than TDD by James Shore

I've also posted a more detailed response on my blog.

Re: There's more to incremental design than TDD by Amr Elssamadisy


I think Extreme Programming does a nice job of addressing this deficiency. It talks about using simple design, merciless refactoring, and TDD together to achieve "evolutionary" incremental design. In my experience, this approach works very well, leading to elegant, clean design.


I have to, respectfully, disagree. Let's call out the practices explicitly:

1) Simple Design
2) Test-First Development
3) Merciless refactoring

If these are the 3 technical methods you are describing in XP that produce the elegant designs then the question becomes:

Which type of refactoring are you talking about? The standard ones in Fowler's book or LARGE refactorings? If:

a) standard: then you have the local minima problem
b) Large: these are no longer linear in the amount of time they need, they are very expensive, and not commonly practiced or done well when they are.

Re: There's more to incremental design than TDD by James Shore


If these are the 3 technical methods you are describing in XP that produce the elegant designs then the question becomes:

Which type of refactoring are you talking about? The standard ones in Fowler's book or LARGE refactorings? If:

a) standard: then you have the local minima problem
b) Large: these are no longer linear in the amount of time they need, they are very expensive, and not commonly practiced or done well when they are.


Hi Amr,

I think you're presenting a false dichotomy here. It's neither a choice between blind hill-descending algorithms nor big, expensive refactorings.

You can use a hybrid of both: continuous small refactorings as you use TDD, combined with strategic design improvements that you work towards over time. Even big refactorings take place in a series of small steps.

To be specific, I operate at three levels simultaneously:


  • 1. Continuous method-level refactorings as I use TDD.

  • 2. Class-level refactorings that bring cohesiveness to classes and packages. These happen several times per day, with a few design breakthroughs each week. The breakthroughs (significant class-level design improvements) take a few hours to complete, but proceed in small, reversible, interruptible steps. I use my iteration slack to complete these. Sometimes there isn't enough time to do all of the class-level refactorings I identify; that's okay as long as the design is better at the end of the week than it was at the beginning.

  • 3. Architectural refactorings, as a result of design breakthroughs, once every few months. These can take several weeks to complete (due to the duplication inherent in architecture), but we perform them gradually over several weeks as we continue to implement stories.



Cheers,
Jim

Re: It's time to be critical of agile hype by Amr Elssamadisy

It would be great if you had addressed specifics of development instead of attacking people - whether they are coaches, Ron Jeffries, or Amr's taste ;)

With that said, I agree we have to be critical - but we should be critical of the practices:


It's all very convenient for the agile coach. Taking metrics for comparison to any other project will always be an apples and oranges comparison because each project used a different agile process. It obviates the need for metrics and any attempt to see if your custom agile process really worked better than something else.


Which metrics do you believe are good indicators of the success/failure of a development process?

Are you suggesting that there is one process that can be applied at everywhere and will be successful without modification? Please point it out so I can tell my clients.

Re: It's time to be critical of agile hype by Dean Schulze

The normal metrics:

Function points per developer per week or month.
Number of defects per function point.

What I'm saying is that changing the process for every project guarantees that you can't make any judgements about whether one process works better than any other.

A process that has to be changed for each project isn't a process at all.

Feature Driven Development can be applied to a wide range of projects and while certain details may change you'll still follow all the practices of FDD on each project. Practicioners of FDD note that it's probably not applicable to certain types of projects (i.e. embedded systems). So they know where it works and where it doesn't.

Be sure to tell your clients now.

a license to kill trees? by Victor Volle

Hm, I do not remember that you should not do any design. You should only avoid to do more design than necessary. If you can justify the cost for design: do it. If it helps you creating better software: do it.
The problem is: if your process forces you to create a big design document, that the architecture department has to sign off, and you are doing a small enough project, you spend too much time on documenting the design, than is justifiable. Often a sketch on a board is sufficient. If you have to hand the software over, you might need more, but that depends on the situation.

Any process that forces you to treat every project the same, is just "a license to kill trees" (www.amazon.com/Laws-Software-Process-Production...)

@Dean Schulze: blindly following a process is as dumb as changing the process at every step. To carry it to the (resp.) extremes:
Agilist: you didn't follow the right process
Strict-Process-Believer: you didn't follow the process.
But you generally can't completely follow the strict processes -- at least in my experience (some medical, some nuclear software systems aside) -- because nobody is willing to pay the price

Re: There's more to incremental design than TDD by Amr Elssamadisy

Hi Jim,


I think you're presenting a false dichotomy here. It's neither a choice between blind hill-descending algorithms nor big, expensive refactorings.


I haven't done so on purpose - I'm just calling it how I see it. This is how most people practice TDD - with small refactorings.

Specifically they don't:

* 3. Architectural refactorings, as a result of design breakthroughs, once every few months. These can take several weeks to complete (due to the duplication inherent in architecture), but we perform them gradually over several weeks as we continue to implement stories.


The fact that you perform large refactorings incrementally seems to be a contradiction in terms. Please explain.

Re: It's time to be critical of agile hype by Amr Elssamadisy


A process that has to be changed for each project isn't a process at all.


So people writing software should pick a process "X" and not modify it at all so it can be comparable to other projects?

This is not an alien thought to me - it sounds to me very similar that is common in the software process research groups: "It's the process stupid!" - that is process are the important part. If you choose the correct process then people will work well together.

My personal experience is that is patently FALSE. Actually, "It's the people stupid!" is much more accurate. It is much more effective to change the practices to fit the people using them.

My 2 piasters - Amr

Re: There's more to incremental design than TDD by James Shore

Hi Amr,

First, thanks for writing and responding about this subject. I think it's an important one.

This is how most people practice TDD - with small refactorings.


Perhaps so. If so, I think it relates to the problem you identified in your original essay: local optimization and suboptimal design. If you don't use up-front design to create and maintain the big-picture design, and you don't use refactoring to do so, I would expect your big-picture design to be, well, kinda crappy.

Since agile methods' short planning horizons and acceptance of requirements changes make it very difficult to use up-front design to create and maintain big-picture design, you have to do something else, don't you? Are there any options other than refactoring?

That does leave us with the question of "how":

The fact that you perform large refactorings incrementally seems to be a contradiction in terms. Please explain.


Sure. Pardon me if this starts out too basic.

First, refactoring is a verb and a noun, right? A refactoring (the noun) is a single, small, controlled change to the code. For example, the "Rename Method" refactoring, or the "Extract Method" refactoring.

The process of refactoring (the verb) is the act of applying one or more refactorings to change your design without changing its behavior. Any non-trivial design change will involve a sequence of several individual refactorings.

As you're refactoring, you should stop and run your tests after each individual refactoring. Each one should only take a few minutes, so you should be running your tests every few minutes. Each individual refactoring should change the design without changing behavior, so all of your tests should pass every time. In other words, you should be running your tests--and they should all pass--every few minutes as you refactor.

I think people forget about this last point sometimes.

You can stop what you're doing any time all of your tests pass. You may not be done, but the code compiles and the tests pass, so you can integrate if you want.

Therefore, every refactoring done in this way is in fact an incremental refactoring. The individual steps are a few minutes long. You can stop any time you want, which allows the overall refactoring to take as long as you want... even weeks.

In practice, I usually spend an hour or two on "big" refactorings. (But still using small steps.) Sometimes while I'm refactoring I have to make the design worse before I can make it better. An hour or two is enough for me to make a substantial change.

In the case of architectural refactorings, I'll have a big-picture design goal--for example, "move business rule logic out of Transaction Scripts and into Domain Model, then turn Transaction Scripts into Service Layer"--but it's too much to do in an hour or two. In that case, each hour-or-two refactoring session will help me get closer to that goal. The goal of a session might be "Move business rule logic out of this one transaction script", for example.

Over time, I (and the rest of the team) are able to achieve our overall architectural refactoring in a series of individual refactoring sessions.

Does that seem like less of a contradiction?

Re: There's more to incremental design than TDD by Paul Oldfield

When I think back to how I've refactored in the past and how I do it now, I think there's something potentially missing in the instruction set for refactoring.

To me, there are two key success factors. First, I always have a "big picture" in mind, and ensure I share this with others on the project. Second, I always work toward separating concerns and getting responsibilities "in the right place" when refactoring.

So for each new fragment of functionality I write, the information architecture, the technical architecture and the design solution may all be merged into one or two lines of code. Then as I write more functionality, there are other 'users' of one or more of these layers, and I need to think how to refactor so the shared design, shared technical architecture or shared information architecture end up as separate concerns - but only as the need to separate them comes about.

It's perhaps with a little chagrin that I, as a fairly committed agilist, have to admit that I really learned how to get the separation of concerns right during several years of BDUF working. Now, I can look back and see that this is a skill I could have learned without doing my work BDUF. But on the other hand, I suspect that heading direct into agile ways of working without learning this sort of skill is missing a trick or two.

It is not a Test Driven Design! by Sadek Drobi

I guess those who followed Fowler's presentation at QCon about Modifiability got a pretty good answer concerning this.
We had a discussion with Jim Coplien about TDD and design, when he stated that "TDD turns your code into procedures wraped into classes". I beleive that TDD doesnt guarantee you any design. It is not a Test Driven Design !

Re: There's more to incremental design than TDD by Geir Hedemark


If you don't use up-front design to create and maintain the big-picture design, and you don't use refactoring to do so, I would expect your big-picture design to be, well, kinda crappy.


But isn't this something the industry has known the last few decades? If you don't do any design up front, you will end up with a very poor design? I agree with you - I can't really see any agile process trying to throw out this piece of ideology.

Along comes "agile whatever". "Agile whatever" solves some problems. One of the problems it does not solve is if you don't have the domain expertise to choose an architecture that at least points in the right direction. It can't help you fix a badly chosen architecture. There are a number of other non-development issues that also are not handled by agile methodologies. It can, however, help with a lot of other stuff, such as premature architecture building and not testing.

So now people seem to be split into two camps.

- the ones who say "agile whatever" does not solve the big problems, therefore we don't need the other stuff either. We want a perfect process or none at all, thank you.

- the ones who say "agile whatever" is the solution to life, the universe and everything because it solves some stuff, and therefore there are no more problems to look into.

I think both these points of view are introspective and not very useful.

Myself, I am an opportunist. I will take whatever I find works, and will probably fail miserably on some other things. The things I fail on I will try to fix in the future - but I will not tell anyone that some external process caused the failure. I was the one who chose to execute a project the way I did.

Will TDD Ruin Your Architecture?! by Martin Jul

There was a big discussion about this at the recent JAOO 2007 conference sparked by Jim Coplien's comment that "TDD will ruin your architecture".

I wrote up some of our findings from the discussion at The TDD Controversy - mostly the stuff we agree on.

For example, test-first is still a Good Thing.

The article also has links to further posts on the subject by Jim Coplien and Roy Osherove.


The article is posted on our blog right here.

The Scale is the Thing by Paul W. Homer

If you step out to your backyard and quickly build a shed, you'll find that you can do it with little or no initial design. We pretty much all know what a shed looks like, and even if we are a little off the results are still usable.

Don't try that with a skyscraper, you are likely to spend years locked up in prison for recklessly endangering (and probably ending) people's lives.

Software is subject to issues of scale as well. If some people come together quickly and build a little system for a couple of months, that is not the same as spending two to five years building and implementing something extremely complex. We absolutely need design to a) save lots of time and b) keep ourselves from getting lost in the woods. Any process that isn't based around a detailed design is exceptionally limited in its ability to be used for medium or large projects. Design doesn't just happen because of a process or because you followed some steps. It is not accidental. To get a design, you need someone who understands 'how' to create one, what needs to be in it, and how to implement it.


Paul.
theprogrammersparadox.blogspot.com/2007/12/natu...

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

17 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT