Details, and the Devil

Originally posted on February 17 2012


Devil is in the detail, an old saying that often proves true. It proves true in IT too; it’s a quite common experience. There are, anyway, cases when we do everything we can to meet the devil in person.

In my “other” job, I use a famous BI tool, well known within the community and outside. It massively evolved in the last 5 or 6 years, widening its scope and developing a remarkable architecture.

One feature it used to support was placing breaks in a table based on a hidden column. It was clearly a residual feature. They implemented the breaks, than they implemented hiding a column and, since the application did not break, they left the feature to break on the hidden column in.

There’s no point in breaking on a hidden column, as breaks and subtotals are not immediately recognizable.

Unluckily, that hidden feature could be used to create elegant layouts, with no blank columns and sexy boxes for subtotals.

A marginal feature was abused and become a cornerstone of thousands of reports.

Until it was dropped.

A new development team, more concerned on the beef and the business, more dedicated to reducing costs and speeding up development came in. The feature was dropped in occasion of a major rewrite. Other, more concrete, features were implemented before that elegant but pointless eye candy could be worked around.

Converting existing reports to upgrade the sw version was a pain that many endured because of the large, existing, customer base. Churn costs were high enough to prevent a large drop off.

I’m not advocating that the feature should not have been left in, it was what users wanted and the developers should have had a better eye for the customers. I’m advocating that a lot of work has been done, based on what might be clearly considered a marginal feature, subject to changes and malfunctioning.

Exploiting the sw to the max, using all the advanced features, finding the intelligent trick that brilliantly fixes an issue will likely do more harm than good, in the long term. It will, because small changes disrupt the entire solution. A resilient solution can tolerate small changes with no harm, but tricky and smart solutions are hardly resilient.

Good software should always be used according to its design principles, no forcing and no bending; bad software should not be used at all!

This occurrence is often overlooked, but I crossed it many times in my professional life, and caused a good deal of damage. What do you think about?