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.

---

Talk Back!

Have an opinion? Readers have already posted 12 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Dale Asberry adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

R. Dale Asberry been hacking since 1978, professionally since 1990. He's certified in Java 1.1 and has a four digit MCP number. He discovered Jini at the 2000 JavaOne and has been building incredibly cool, dynamic, distributed architectures ever since! Over time, he's discovered several principles that have contributed to his success - they are the Princples of: Enabling Others, Simplicity, No Complaining, Least Work, Least Surprise, Least Damage, and "It Just Works".