Ben Tomasini Welcome Guest | Login or Register

I almost sent my new laptop computer back to Dell.  It was taking 15 minutes to boot up, a disc was stuck in the drive, the hard drive light was on constantly, and it was super slow.  I was following the instructions from the Dell tech on how to re-image the system using the built-in recovery partition, but that wouldn’t even work.  So the tech was proceeding to send me a shipping box.  Just one more thing to try - press the optical drive eject while in the BIOS setup screen.  Viola.  Out pops my Nintendo Mario Kart Wii disk.  “Huh.  Been looking for that,” I thought.  It was surely inserted by one of my boys.  Probably Aaron.

There you have it.  Wii games cause Dell computers to go wonky.

I recently did a talk with a group of IT professionals on Agile Development practices.  It must have not sounded like a normal Agile talk because the organizer came back and asked if I wanted to change the title for the transcript.  The new title is “Software Simplicity: Doing More by Coding Less”.  The basic premise is that, in aggregate, the biggest determinant of software quality is the number of lines of code required to meet a business function.  Think of business and utility function as an asset and lines of code as a liability.  I believe this for both the simple fact that more lines of code mean more bugs, and the more subtle fact that less lines of code reflects a more deft approach to software.  Software is a craft where quality usually goes up when one hits the delete key because a better design has made bad form out of certain verbosity. Every line of code must prove its worth.  Pack your apps with less, not more.  To borrow from XP: YAGNI.

The theme of this talk arose from recent work I have been doing getting a large team up to speed on a relatively large project.  The main challenge of the project was the number of people involved.  I found two keys to success:

(1) Model a super clean application with a good application stack:  The abstractions should be not too opaque (I still think SQL is a good thing), but not too thin (Something is wrong if I have to close a JDBC connection or pull a parameter from HttpServletRequest).  My favorite is: Struts2, Spring, Spring Security, iBatis, running jetty under Maven.  The code should be as minimal as possible and impeccably clean.  You cannot elimate entropy in the process, but at least you can keep the energy state high and organized to start to positively influence the end state.

(2) Mentor mentors.  Start with a small group. Work together.  Lean from each other.  Make the stated goal for the this prototypical team to produce work like it came from a single developer.  Add more developers when the base of mentors can support it.  Keep the mentoring cycle alive throughout the entire project.

Nothing magical, kinda boring.  But it works.