Re: Should I leave behind beautiful code or readable code?

[gloryhack]

I have relatively recently decided that I'm not going to dumb things down any more. While I'm definitely not of the mindset that code that is hard to write should be hard to read, I believe that there's nothing to gain by assuming that the maintenance programmer is a dolt, and much to lose by encouraging the underqualified to futz around in working code.

I've one client in particular who drove this decision. They want to be more or less self maintainers, so I made everything as simple as I could for them. The result is that after several years many things are in terrible disarray, still working but not well. Revision control? Forget it. I find out about changes either when they don't work and have to be corrected at a moment's notice, or when new projects intersect with damaged code and much of the damage has to be undone to restore carefully planned interoperability.

So, my vote is for writing the best code even if it's beyond the neophyte and maybe stretches the limits of the moderately skilled. If the owner wants to turn the kid next door loose on it, fine -- either the kid next door or the owner will learn a valuable lesson, depending upon how well it works out.

I think there may be easier ways to populate hashes than your cool map/split...