I’d like to discuss shitty developers. Because there’s a rule that’s being violated out there by more than half the devs I’ve ever worked with, and it goes like this: developers are lazy, so we try to find ways to make our work easier.
The problem is some devs are so god damned lazy, they just churn out shit and don’t bother to even notice they’re wasting a ton of time.
Harmony Central
I would like to discuss Harmony Central in great detail someday, but that’s just not in the cards. I am so sad that my old employer, Musician’s Friend, made the decisions they made regarding that site, because the community was pretty awesome at one time, and kept getting shit on.
That’s another story for another day. The more important point right now is that the developers who originally made the site… were truly awful. Long-time visitors might recall the pre-2005 user reviews. Each section (guitar, bass, mics, etc) tended to look slightly differently from the other sections, and the review submission process wasn’t consistent.
When I took on the task of building a “temporary” replacement for the user reviews, I discovered why it was so bad. The original developers had a giant (~10k lines) Perl script to run the process of a single section’s reviews. Each section had its own copy of this script. Each section’s copy of the script differed in very subtle ways. Instead of building a suite of functions, like a smart dev would, these two jackasses (sorry guys, you were pretty cool but that code was inexcusable) copied and pasted shit around and then changed it to suit the new section. Different scripts would have slightly different bugs, and it was impossible to maintain because the scripts totaled about 100k lines of Perl.
And that wasn’t the only issue. The review process involved raw text files. Submit a review for a guitar, a line was added to “guitars.txt” with the info. This meant two reviews hitting at the same time could corrupt the file, as there was no file locking… and of course, adding file locking would have meant changing a ridiculous amount of code thanks to duplicated scripts.
Raw text files also meant that moderating the review could only happen when nobody was submitting a review. And moderation was just another level of awful itself. It was often command-line, and required a great deal of attention to detail to verify things like the spelling of “Gibson”. The review “app” didn’t even bother to store which line of the text file was being examined. Instead, the first line was always whatever was “active”. Skip to the next review? Rewrite the file with the first line moved to the end. Approve a review? Process line one, rewrite the file with all lines but that first one.
By using all this text-based trickery instead of a database with transactions, errors could cause data loss or data corruption. And the process was so painfully manual and error-prone that they spent something like ten hours a week just to process pending reviews and/or fix bad reviews they accidentally published.
For some categories, the moderation process had a web UI, but not for all. For some categories, the moderation scripts stuffed data into a database, but for some it just churned out a static HTML page.
What I wrote to replace it was pretty bad, but it didn’t take much thought to come up with a simpler, smarter, faster, and safer system. And my system had a single web interface for all functionality, so moderators, not programmers, could process reviews.
Looking at their code for that system as well as the rest of the site, one thing was clear: they were churning out code very fast, never stopping to ask if they could save time by learning better ways to write code. It took some effort, yes, but we saw a phenomenal improvement in dev productivity when we fixed some of the low-hanging fruit.
So, please, shitty devs: stop just churning out code. Try new approaches. Research best practices. Learn your tools.