Discussion on: Software Simplicity Perspectives http://itknowledgeexchange.techtarget.com/customapps/software-simplicity-perspectives/ Mon, 08 Sep 2008 03:31:00 +0000 http://wordpress.org/?v=wordpress-mu-1.2.1 By: Walter47 http://itknowledgeexchange.techtarget.com/customapps/software-simplicity-perspectives/#comment-12 Walter47 Mon, 01 Oct 2007 20:04:04 +0000 http://itknowledgeexchange.techtarget.com/customapps/software-simplicity-perspectives/#comment-12 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 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

]]> By: Applause14 http://itknowledgeexchange.techtarget.com/customapps/software-simplicity-perspectives/#comment-8 Applause14 Fri, 21 Sep 2007 09:27:46 +0000 http://itknowledgeexchange.techtarget.com/customapps/software-simplicity-perspectives/#comment-8 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. 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.

]]>