The Artima Developer Community
Sponsored Link

Weblogs Forum
Agile Methods Miss the Point

12 replies on 1 page. Most recent reply: Apr 12, 2004 8:17 AM by Marco Dorantes

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 12 replies on 1 page
Dale Asberry

Posts: 161
Nickname: bozomind
Registered: Mar, 2004

Agile Methods Miss the Point (View in Weblogs)
Posted: Apr 5, 2004 11:53 AM
Reply to this message Reply
Summary
Elaboration of the seven principles contributing to my success - the Princples of: Enabling Others, Simplicity, No Complaining, Least Work, Least Surprise, Least Damage, and "It Just Works".
Advertisement

Where'd it come from

I was working on my JCM7 presentation Jini and Web Services: Judy Project Overview when I realized that I was making choices about how I developed the Judy codebase. I'm not really sure why I hadn't consciously recognized what I was doing -- especially since I remember following these principles for years... maybe from the project being "my baby", or, possibly, from the complete lack of time I have to give to it. Mostly, I think it came from me thinking about how to describe Judy to my audience. Since software is for, and about, people, I decided to include it in the presentation.

Dogma

One thing bothers me about the "Agile" movement is the fervor of the religious dogmatism from many of the practitioners. Before I get flamed, hear me out... I personally think many of the agile practices solve several problems that have afflicted the industry for decades -- I use them to solve problems myself. Yet, these practices are still fumbling around the most basic tenet. Software is for, and about, people. Fervor and dogmatism, while good at spreading and enforcing "the word", ultimately squashes critical thought (and the people engaged in it). Principles, on the other hand, are only meant as guides. Dogma are inflexible, hard and fast rules and includes the resulting punishment when a person strays.

Back to the Subject at Hand

Focusing on these principles, coupled with shuffling their priorities to meet the needs of the moment, has resulted in a steady progression and happiness with my chosen career - regardless of the methodologies (Waterfall->RAD->RUP->Agile) and technologies (COBOL->C/C++->Delphi->Java->Jini->Web Services) available to me.

The Principle of Enabling Others

"Give a man a fish and you feed him for a day. Teach him how to fish and you feed him for life." At the end of the day, this makes me more productive by focusing on what software development is really about -- the people I work with. Paradoxical, I know, but very powerful.

The Principle of Simplicity

If it isn't simple, then it's wrong. In programming terms, simplicity is relative to the level of abstraction. This principle is fallout from having to maintain, review, or otherwise interact with uncounted lines of crappy, overly-complex code from lazy programmers. I particularly despise having to write sub-optimal code myself to work around the limitations of someone else's [fill in the blank] framework/API/application.

The Principle of No Complaining

Don't complain if you're not willing to fix the problem. Nothing is more destructive nor demoralizing than a contentious spirit. Complainers are lazy, petty, and spiteful with no intention of ever being helpful (although they are usually pretty crafty about trying to make it look like they are).

The Principle of Least Work

Do the least it takes to make the software useful, but, prepare for the future. Do whatever it takes to make the work easier (see enabling others). If someone else has already done it, see if you can use it. This principle is not condoning laziness -- there is already to much work that needs to be done and not enough time to do it.

The Principle of Least Surprise

Always do the least surprising thing. In other words, make it work intuitively. And, don't trust your own intuition. I wasn't able to find who discovered this principle, but it is true on many levels, not just GUI design. Unfortunately we are forced to live with products that fail to follow this principle. Why is so much software so baffling?

The Principle of Least Damage

Firstly, don't let the user do something they don't understand. Secondly, if you do, always give them a way to undo it. Finally, operations should only do one thing at a time in incremental baby steps -- except when the user knows what she is doing. Users should feel safe using the software.

The Principle of "It Just Works"

Never expect or require the user to RTFM. Lead the user to her goal. Encourage the user to explore. Expect the user to say, "wow, it's so easy to use!" Frankly, I'm completely fed up with all those software projects that force me to grab the source from HEAD (just to get a usable distribution) and then requires me to read the source code just to figure out how the application works.

Final Thoughts

If you remember and focus on software (use and development) being about people, then whatever principles you follow will equally lead to your success.


Marco Dorantes

Posts: 11
Nickname: marcodoran
Registered: Feb, 2003

Re: Agile Methods Miss the Point Posted: Apr 5, 2004 3:35 PM
Reply to this message Reply
I agree, guiding principles are key, that is why agile methods have some:

Principles of Agile Software
http://www.agilemanifesto.org/principles.html

Dale Asberry

Posts: 161
Nickname: bozomind
Registered: Mar, 2004

Re: Agile Methods Miss the Point Posted: Apr 5, 2004 5:26 PM
Reply to this message Reply
Indeed, I even have a link off of my home page: http://www.daleasberry.com The problem is that they are missing something... those principles only address "process", not people. I believe the missing people part is what makes it so easy for the "true believers" to trample on others who disagree. I also believe that those principles (and the methods used behind them) do not fulfill the "necessary and complete" aspects of a theory, although that doesn't limit their usefulness.

Dale Asberry

Posts: 161
Nickname: bozomind
Registered: Mar, 2004

Re: Agile Methods Miss the Point Posted: Apr 5, 2004 5:29 PM
Reply to this message Reply
...and...

The Agile principles require buy-in from others. My principles only need to be followed by me.

Jason Yip

Posts: 31
Nickname: jchyip
Registered: Mar, 2003

Re: Agile Methods Miss the Point Posted: Apr 6, 2004 4:24 AM
Reply to this message Reply
I don't think it means what you think it means...

I'm a bit confused by those principles only address "process", not people because of what's on http://www.agilemanifesto.org/, specifically:

Individuals and interactions over processes and tools

I actually think it is important to have some principles that require buy-in from others because when it comes down to it, we need to work with those other people.

I don't actually have a problem with the principles that you list. Reminds me of The Art of Unix Programming. However, I would suggest that the zealots you've encountered have not understood the value above and therefore don't really understand the "Agile movement", if you will.

Regarding software development being about people, Alistair Cockburn has been involved in XP/Agile since the beginning and one of the things he proposed was that people are non-linear first-order components in software development:

http://alistair.cockburn.us/crystal/articles/cpanfocisd/characterizingpeopleasnonlinear.html

Marco Dorantes

Posts: 11
Nickname: marcodoran
Registered: Feb, 2003

Re: Agile Methods Miss the Point Posted: Apr 6, 2004 7:49 AM
Reply to this message Reply
Let me say that your post is very right on target with software design and people orientation. Not so the post title, the title is a crime.

The single key aspect of agile methods that convince me is precisely their people orientation.

Look at XP values: communication, simplicity, courage and feedback.

Look at Kent Beck talk in a previous XP conference about the "L" word (love)

Look at:

Avarice: The Fifth Value?
http://www.xpuniverse.com/2003/schedule/Kent

PeopleOriented
http://martinfowler.com/bliki/PeopleOriented.html

PrinciplesOfXP
http://martinfowler.com/bliki/PrinciplesOfXP.html

Dale Asberry

Posts: 161
Nickname: bozomind
Registered: Mar, 2004

Re: Agile Methods Miss the Point Posted: Apr 6, 2004 9:51 AM
Reply to this message Reply
Well, I guess that I need to apologize for the title... Maybe it should have been "Agile Zealots Miss the Point". That's more in line with what got me thinking about making this post. Also, I appreciate the great links that you've provided.

Thanks!

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: Agile Methods Miss the Point Posted: Apr 6, 2004 10:54 AM
Reply to this message Reply
Hmm... is that me? An agile zealot? I don't know. I did write one of my most forceful blog entries the other day here on Artima. But, frankly, it was hard won experience and I almost posted something like it a month ago, but I thought "hey, everyone will think I'm a zealot." :-)

Here's the tricky thing. There are some important things that just have to be said. They'll turn some people off and other people on. It's hard to know what the ratio will be when you post. But, the alternative, leaving things unsaid, isn't all that appealing to me.

What I do think is unfortunate is how you've dichotomized things in your post. I don't think zealotry is a black hat/white hat issue. For one thing, most of the people that I know that are really passionate about agile methods are very strongly into the human side of development. Frankly, I spend more time on people issues when consulting than technical issues. Unless you deal with them, they are a ball and chain on organizations. When you have a team that is aligned, with people who are comfortable with their roles and feeling capable, really able to solve problems, practices aren't going to do much. Fortunately, practices can help a team move along in that direction, along with some interpersonal work.

The problem is that these things are much harder to talk about.. working with the guy who feels that his skills are totally out of date and doesn't want the rest of the team to know, the manager who is frustrated beyond belief because her team can't deliver software fast enough but it seems that the rest of the organization has tied her hands. So yes, people issues are also critical, but it they are often personal and harder to talk about in public. I'm sure some zealots don't know that, but this one does.

Dale Asberry

Posts: 161
Nickname: bozomind
Registered: Mar, 2004

Re: Agile Methods Miss the Point Posted: Apr 6, 2004 12:05 PM
Reply to this message Reply
It is absolutely not you. Your blog wasn't posted until after I had figured out what to say in mine. Your post only clinched it, er, I mean, uh... [awkward silence]

Only kidding! I actually am feeling the same pain as you but from two sides - from those that don't care (or understand, or ...) and those that have idolized Agile solutions. In both cases, I think the problem stems from an unwillingess to put hard work in where it counts. Writing software is hard for the first group because they lack coding skills or they have to cope with organizational disincentives. The second group is unable to cope with people. I certainly wouldn't characterize your post(s) as zealotry.

>>Here's the tricky thing. There are some important things that just have to be said.<<

Wise words.

>>What I do think is unfortunate is how you've dichotomized things in your post.<<

I let my frustrations with some zealots get the best of me and it colored my whole entry. After reading a couple of the comments, I realized that the principles I am espousing are in many ways orthogonal to Agile principles. They are additional tools that a developer can add to her belt.

Matt Gerrans

Posts: 1153
Nickname: matt
Registered: Feb, 2002

Re: Agile Methods Miss the Point Posted: Apr 9, 2004 12:02 PM
Reply to this message Reply
First a couple of nits that require picking:

1) > "At the end of the day..."
Press releases (2004): At the end of the day... we're fed up with clichés.
Plain English supporters around the world have voted "At the end of the day" as the most irritating phrase in the language.
http://www.plainenglish.co.uk/pressrelease.html

(based on your usage, you get the benefit of the doubt: you were intentially using this cliché sarcastically in contrast to the well-worn bromide by which it was preceded)

2) Did anyone else notice that all the complaining about "...uncounted lines of crappy, overly-complex code from lazy programmers..." is immediately followed by The Principle of No Complaining?

Okay. Sorry, I couldn't resist! ;-)

It seems like many people equate or confuse Agile with XP. I was under the impression that they were not the same thing. This association is probably bad for the Agile philosophy, because it is not inconceivable that XP will be a fad that passes.

I thought that Agile was more of an approach or philosophy, wereas XP is a methodology. Of course, XP is perhaps heavily influenced by the Agile ideas, but makes it's own interpretations and dogma, just as many modern religions (Catholism and Protestantism, or Sunni and Shiite) are derived from the same base legends, but diverge in their specific dogmas. (I'll leave it to the reader to guess whether the pun is intentional or not).

Or am I wrong? Does XP == Agile?

Dale Asberry

Posts: 161
Nickname: bozomind
Registered: Mar, 2004

Re: Agile Methods Miss the Point Posted: Apr 9, 2004 4:33 PM
Reply to this message Reply
> First a couple of nits that require picking:
>
> 1) > "At the end of the day..."
> Press releases (2004): At the end of the day... we're fed
> up with clichés.
> Plain English supporters around the world have voted "At
> the end of the day" as the most irritating phrase in the
> language.
> http://www.plainenglish.co.uk/pressrelease.html

Ouch... I normally do a good job of catching cliches.

> 2) Did anyone else notice that all the complaining
> about "...uncounted lines of crappy, overly-complex
> code from lazy programmers..."
is immediately followed
> by The Principle of No Complaining?
>
> Okay. Sorry, I couldn't resist! ;-)

Caught again!

> I thought that Agile was more of an approach or
> philosophy, wereas XP is a methodology. Of course, XP is
> perhaps heavily influenced by the Agile ideas, but makes
> it's own interpretations and dogma, just as many modern
> religions (Catholism and Protestantism, or Sunni and
> Shiite) are derived from the same base legends, but
> diverge in their specific dogmas. (I'll leave it to the
> reader to guess whether the pun is intentional or not).
>
> Or am I wrong? Does XP == Agile?

I think, maybe, that this is what I was aiming for.

Paul Rivers

Posts: 24
Nickname: paulrivers
Registered: May, 2003

Re: Agile Methods Miss the Point Posted: Apr 9, 2004 9:30 PM
Reply to this message Reply
Some of us actually get a little zealous about agile methods habitually only because when we were going to school, everyone said "You need to design your application up front, or you're an idiot." It was always the "right" way to right software - write the design first. We've just heard that so often, but then wasted sooooo much of our time on "correct design" (the best is when you design everything, then find those wonderful fundamental assumptions you made were wrong, so you throw your entire design away), the strong reaction for agile methods is a backlash against the old crap.

(Seriously, every other programmer I've met who's over 45 loves to go on and on about the "right way" to write software is to design first. Maybe it's because they started coding in assembly - where you really did have to design first, because there was no debugger and printing output usually worked..., unless you messed something up...(which is exactly why you needed to print in the first place))

Marco Dorantes

Posts: 11
Nickname: marcodoran
Registered: Feb, 2003

Re: Agile Methods Miss the Point Posted: Apr 12, 2004 8:17 AM
Reply to this message Reply
But you know that XP is about continuous design, as a making-decisions activity, where the closed loop back control process for this design is tiny and new design decisions are made based on that feedback, so the school teaching is still correct at least in essence. Very often, my case is that my initial understanding of the teaching usually was wrong.
But how could I expect complete knowledge from school? Practice is needed to get there.

The same feedback process permeates agile methods, one differentiator between agile methods is the length of that feedback process for design.

Flat View: This topic has 12 replies on 1 page
Topic: Implementing the Null Object Pattern using AOP Previous Topic   Next Topic Topic: One Awesome IDE -- CodeGuide

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use