The Hidden Long-Term Costs of Doing it Right

Ayende wrote a good post about keeping quick hacks out of your programs: No Broken Windows. Go read that and come back.

Keeping your code beautiful has a lot of value. For one, it reduces the likelihood someone will later decide it is a steaming pile of crap and try to rewrite it thereby discarding all of your diligent planning, testing, and bug fixing. But I only agree conditionally with Ayende.

My beef is that the absolute cost differential Ayende cites in this case is too small to be meaningful. The difference between a 1 hour task and a 4 hour task is 3 hours of sleep later in the week. Quite simply, it is within the noise margin of software task estimation. What's not clear is that doing the 4 hour task can have ripple-down effects that are orders of magnitude larger. Choosing the 4 hour task may commit you to an endless cycle of choosing 4 hour tasks.

Let's say you have to render a simple tabular report for your customer. Since you only have one report to display, you decide to do it all in application logic. It's beautiful. So that you don't repeat yourself you reuse existing code for validating input, getting the data and calculating summaries. Moreover, you render the report using the same UI infrastructure and conventions used everywhere else so you can deeply integrate the report with the rest of the UI. The result looks great and feels very polished.

There's another choice though. You can bolt on SQL Server Reporting Services or Crystal Reports to generate the report. Then you can easily offer report downloads in CSV, XLS, XML and PDF which you believed the user will appreciate enough to be worth spending the extra 15 minutes on it. The downside is that no matter how you do it, the reporting feature will probably be a wart in the code and look like a wart to the user. However, let's suppose it's faster to do it this way because everything is already at hand.

So what do you do? Tough call. Here's what actually happened to me on two different projects.

• On one project, I decided to keep everything clean and beautiful. It looked great and shiny and only took me 4 hours to implement a report that got sent via emails. And then I got the request to provide a similar report in the UI with download support. Crud. Oh, and there's this wish list of 5 other reports too. The cost per report was tremendous. Each report was specially tailored for usability. And there is no support for downloads. It was more polished but no one really cared! (I am still backlogged on feature requests!)
• On another project, I bolted on SQL Server Reporting Services. Oh the pain! We had to munge configuration files to link in custom assemblies and it was a real nightmare getting the automated deployment to work. We wrote an abstraction layer to avoid coupling the application too tightly to Reporting Service but of course it's leaky. The reports look awful next to the rest of the site and we can't enhance them with AJAX or anything. Every now and then the house of cards comes a-tumbling down. But you know what? We now have 40 or so different reports available for viewing or download. (And the list keeps growing.)

So beware. The choices you make in the name of beauty and purity can lead you down avenues with non-trivial long-term costs. Just be sure that the rewards of Doing It Right justify the risks. Sometimes Doing It "Okay" is better especially if you aren't developing shrink-wrap software. (But don't ever Do It Wrong!)