Regarding Quality vs. Schedule

May 5 around 11 am mountain time

Ed Gibbs, a software development manager from Sacramento, wrote about a presentation Bob Martin attended “where the speaker had just about given up on ever getting better code quality, because businesses didn’t value it.”

His claim that crappy code is inevitable is based on the notion that crappy code is cheaper than clean code, and that therefore businesses will demand the crap every time. But it has generally not been business that has demanded crappy code. Rather it has been developers who mistakenly thought that the business’ need for speed meant that they had to produce crappy code. Once we, as professional developers, realize that the only way to go fast is to create clean and well designed code, then we will see the business’ need for speed as a demand for high quality code.

I’m in the business of web-based software and website development where clean code is paramount but deadlines always seem to win. There just aren’t enough hours in the day and days in the month to get through all the requirements. The process usually works like this: business development sells the job, design chews through the schedule, development is a rush, and quality assurance is an after thought. And, as Bob and Ed clearly point out, this is certainly not the best way to develop software or websites.

(Thx, Tim)

DomReady

May 2 around 12 pm mountain time

I was working on an existing site earlier this week that doesn’t use jQuery and desperately needed a quick, effective and efficient “on DOM ready” handler. I started pull apart and reconstruct jQuery’s jQuery.ready(); method, but stumbled on “DomReady” — the smallest subset possible from jQuery to support dom Ready event. I ran it quickly through Dean Edwards’ Packer and was off. No library needed.