Home > IT Blogs > Custom Application Development: Buy, Build or Ignore? > Software Simplicity Perspectives
>>VIEW ALL POSTS  

Custom Application Development: Buy, Build or Ignore?

« Buy, Build or Ignore? — What does THAT mean?
One-Size-Fits-??? »
Sep 20 2007   4:15PM GMT

Software Simplicity Perspectives



Posted by: Joe Coley
Agile, Custom software development, CIO, Software Quality

I’d like to call special attention to one of the written principles contained in the “Agile Manifesto” relating to simplicity,  “Simplicity–the art of maximizing the amount of work not done–is essential.”  Yes, I agree with this statement.  I also think that “feature creep” is a primary foe of simplicity, but that is perhaps for another post. 

However, I wonder how many other developers such as I have experienced the “lack of simplicity” in creating software that is ultimately “simple” for the end-user.  I don’t think that “simple” for the end-user is necessarily “simple” for the developer…and once again I turn to communication as a key ingredient.  I find myself constantly asking the question “What will make this easier for the user?”

Fellow NEDC developer Garret Mott has published an excellent white paper called “Software as a Conversation“.  I believe this is excellent reading for developers who are concerned about keeping simplicity in their application program “conversations”.  Garret’s perspective in this paper can easily serve as a reminder to developers to perhaps “visualize” themselves as the user when designing.

AddThis Social Bookmark Button     Comment     RSS Feed     Email a friend

Comment on this Post


You must be logged-in to post a comment. Log-in/Register

Applause14  |   Sep 21 2007   9:27AM GMT

Joe, thank you for publishing a link to the Agile Manifesto. It hit vibes with me synonymous with my personal philosophies of coding software and delivering same. They are:
[1] Always code *Compound Simplicity rather than complexity.
Many times I know how to code an advanced syntax but avoid it completely in order to make my intent clear. I will go out of my way to code in a “I can see your intent and manner of delivery” fashion rather than “What do the seven embedded elements with open and close parentheses do?” approach. Compound Simplicity involves careful laid out steps to produce a result where any of the steps can be augmented or changed for future business rules too.
[2] Chevy Chase|Caddyshack: “be the ball!”
I always imagine myself as both the owner of the company, and the user of the software as well as the recipient of the software results when I design systems. This leads me into some heated ideological exchanges when a company assigns an IT department to write a sales system, for instance, but I try to stick with my resolve, and when I can, I try to involve the department that will deploy the software prior to it’s release.

So, in the long and short of it, I thank you so much for linking and publicizing the Agile Manifesto, I have read Mr. Mott’s whitepaper, and I have signed up as a supporter for the manifeso. Nice way to start a day: have a great one. Peter.


 

Walter47  |   Oct 1 2007   8:04PM GMT

Yep, yep, yep. Simplicity for the user does not usually equate to Simplicity for the programmer. There is a balance, for those who follow me in future programmic changes, that I must take my ego out of development.
It’s not about me, but the good of the company.

Jack