Performance or Perfection

20 May 2005

Just finished reading The psychology of learni
ng, as recommended by Adam Connor.

I agree with Jeff Hunter’s take on the essay. I am defin
itely aligned with the perfection-oriented camp. I’m someone who likes to play the latest tools and technologies. For example, I don’t hide the fact that
I actively prefer a persistence layer implemented in hibernate versus CMP. However, this isn’t because I’ve read a negative story about entity beans or a
positive story about these alternative persistence engines, its because I’ve been through battles on both sides. I also agree that not everyone should ne
cessarily be perfection-focused. Its a situational requirement not to be offset by the fact that you will always need people that can get the job done and
aren’t going to concern themselves with the perfect implementation.

…I have heard people argue about the amount of memory a particular tool requires, whereas the additional memory required might represent a cost equiv
alent to a few hours of work at most. A favorite idea is to label a particular tool with a name suggesting what it ought to be doing, and then arguing that
it is doing more than that. For instance, a text editor that is capable of automatic indentation would be accused of being a “kitchen-sink” tool because
after all it does much more than allowing the user to just edit text.

Everyone knows that the best developers use nothing but notepad. I was the self-described king of html development using nothing but a text editor….duri
ng the mid-nineties. Back then there was nothing better that combined efficiency and quality. Now, I’m not a dreamweaver junkie or anything, but I recog
nize the value proposition these tools present. If I did any sort of serious web development now a days, I find it unlikely I wouldn’t be more productive
in a new tool after investing time to learn it. That being said, its amazing how many people I talk with that still brag about using dated tools while at
the same time disparaging anyone who is using newer tools/technologies they aren’t familiar with.

Another more develop-focused story, we once had a developer who swore by using Emacs for java development (I’ll prefix by the notion that I have _very_ lit
tle Emacs experience). This was just plain jane Emacs, no java-specific extensions or plugins. Meanwhile, the rest of the team was hapily (and productive
ly) using NetBeans or Eclipse. Did he see a reason to switch? Nope, he was content to opening every file under the sun, memorizing the API, and commentin
g even the most redicious lines of code because his editor wasn’t configured to do the simple things a java developer would expect. No variable/class auto
-completion and crappy (imho) syntax highlighting made for a very unproductive development environment.

The morale to this story is that theres a fine line when it comes to balancing perfection and performance. The job still needs to get done, but when there
are clearly better tools either currently available or coming down the pipe, I’m of the believe that its often better to be the early adopter and cut your
teeth on something before it becomes mainstream.

Take the EJB 3.0 specification, it’s incorporating a number of the aspects already provided by persistence frameworks like hibernate and containers like sp
ring. If management was of no concern, should a developer today be content to work with dated EJB 2.x technologies, or should they be proactive in their s
earch for a better technology? (or maybe even just a reference implementation of EJB 3.0…).