Is Quick and Dirty Such a Bad Thing?

I sat in a meeting today discussing a complex customer problem with the team. We brainstormed and quickly determined that a good, clean solution to the problem would take more time than the customer was willing to give.

I suggested that we try to find a partially manual work-around to buy us time to implement the clean solution. The team was not fond of my suggestion but cooperated. One of the developers came up with a “quick and dirty” solution.

It means manually inserting records into our database. After some automated updates, we’d make some additional manual changes and proceed as usual. It’s a little rough but provides 80% of what the customer needs. Now the hard part.

We need to convince the bureaucracy that this approach is safe and sensible. They will surely argue that overriding the logic and controls in a production database is bad practice.

Does the quick and dirty solution make us more agile or turn us into hackers? Does it matter?

Some believe that agile development is less disciplined and less refined than command and control approaches like waterfall. I believe any approach can be elegant or crude; clean or dirty. It all lies in how you go about implementing the process.

I’m just trying to solve the customer problem — fast.

Updated: January 11, 2011 — 10:46 pm