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.
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.
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:
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.
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.
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.
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).
> 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.
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))
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.
Previous Topic
