Today DZone published an article "The Next Level of the Don't Repeat Yourself (DRY) Principle." I believe the author makes some great points.  In the Java world, we've functionally decomposed a significant portion of our software complexity into reusable libraries and frameworks - Spring MVC, OSGi, Apache Jakarta, Google Guava, etc.  But we're still assembling these tools into very complex applications - but we're not fundamentally improving the larger components.  The dream of having components slide together into places like LegosTM to build larger applications just hasn't occurred yet.  The practice is still more art than science.  Understanding that is key to fixing it.  We're still not much more advanced than we were 30 years ago.  Why is this?  

In the Unix world, you can take inputs and munge them to create new forms of output.  Tools like awk, sed and perl come about to help you do things in such a way that if you know how to use them, and their power, you can accomplish your job faster than in a tool like Excel.  Exclude vast swathes of data with egrep and regexes:  cat file | egrep -v "data|that|I don't|want".  We haven't yet moved these terrific semantics into the GUI world, into the mouse world.  This comes back to a previous argument I made that we are designing our software wrong - in a GUI world, grep should work across all apps universally.  A CTRL-G should bring up a box that lets me extract or exclude all the data I want matching a pattern.  It should be supported by the OS, not each application.  

 

There are several problems with DRY at a higher level

  1. There's little support for it at the OS level - operating systems have been designed for end-user ease of use, and through many iterations of development.  It's been many years since anyone has stepped back and done a clean-room implementation (though iOS is one such implementation in the mobile world). 
  2. No one has settled on what rules for flexibility are.

 

Katamreddy writes that "If an architect or developer got a requirement to build a reusable component, it would be great if he/she can publish his/her approach (and code if possible) so that the other developers across the Java community can use the approach/code instead of reinventing the wheel."  Well we do that.  But what we don't do is make it easy to reuse components - to plug them together.  Our XML interfaces get so utterly complex that they become fragile - the exact opposite of what XML was meant to accomplish.  When XML becomes another programming language, all you've done is shift the repeating from code to configuration - you're not really solving the complexity problem. 

 

Fact is - I don't think anyone has solved this - and that's going to be the real advance in computing - when someone figures out how to make it easy for Joe Blo to wire up Excel to a job processing engine that processes his inputs in new ways that he defines to a plant designer who can wire up 1000 machines and their associated sensors by dragging and dropping components to someone like me, who wants to fundamentally change his workflow by taking component 1, component 2 and component 3 and creating a new mashup application that is the greater of the 3 of them.