As we've looked at before, simplicity is a funny word. Sometimes hard to understand. Always hard to accomplish.
As Software Architects, one of our greatest responsibilities is to vacuum up the chaos and distill it into a rational and valuable (even pleasant) reality. One of the keys to success on this dimension is simplicity, which I tend to think of in the following ways:
"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." (Antoine de Saint-Exupery)Finally, as I'm defining it, the goal of simplicity is nicely summed up in the following quote from Paul Preiss, President of IASA, in a recent webcast, "A Guide to the Architecture Profession":
"Simplicity--the art of maximizing the amount of work not done--is essential." (Agile Manifesto)
"Treat every problem as if it can be solved with ridiculous simplicity. The time you save on the 98% of problems for which this is true will give you ridiculous resources to apply to the other 2%." (Dr. Paul MacCready)
"80% of the results come from 20% of the effort." (Pareto Principle or 80/20 rule)
"Our responsibility is to build as little software as possible to add shareholder value."Let's get out there and build less software! Oh, and lets simply do it with less effort!
![[hot]](http://bsonderg.googlepages.com/star_on.gif){kind=small}
Save This Page
1 comment:
For years I've had as one of my email .sigs, "The best way to have fewer bugs is to implement less code." (Ron Jeffries) Also, a classic Blaise Pascal quote seems fitting here; "I have made this letter longer than usual, because I lack the time to
make it short."
Sadly, many developers and architects seem to think more, bigger, more complex code is somehow better. I've seen time, and time, and time again, in the name of the almighty "code reuse" windmill, frameworks that get written and are fundamentally hard to use. People will write 100k of framework code to abstract out 15k of work. And this is better because it "...provides a consistent interface...". Blah. It also provides a PROPRIETARY interface that requires training and teaching, whereas what you are abstracting away is understood by most everyone. (Huge data access layers on top of Hibernate, for example.)
Indeed the apparent paradigm of J2EE supports this - all these frameworks that do not even the simplest thing without gobs and gobs of XML.
I think the Java space at least is partially moving away from that - backlashes to config-heavy frameworks (struts, JSF, [almost every other J2EE "standard"]) in favor of lighter approaches (Wicket, Stripes, Spring (even Spring is reducing its config!)).
Rails and the whole "opininated" software idea has pushed a lot of this; do one thing really really well, and allow the user to config other things as they need.
Post a Comment