Developers often get accused of 'Gold plating'. They take a requirement and don't deliver on time because they are too busy adding in the additional functionality that they think they need to deliver a single requirement. It's a criticism I often have of myself.
Sometimes however that plating is their for a reason, usually because you've worked on a project before that didn't have it and felt the pain afterwards. The additional functionality not in the spec is needed, lets refer to it as 'Nickel plating'.
For example, I've recently been working on implementing the ability to use a standard Report Definition Language in order to describe reports. We already have an internal format, which is spread over quite a few tables and loaded into a two tier object hierarchy, and we also have the same object hierarchy xmlSerialised. In this case my requirement was to patch RDL definitions into our reporting process.
Step 1 : Test driven conversion of existing object to support many sections in a report
I would like to thank Tom for his fantastic suggestion on this piece of work. I took one class, and moved it into three. I created a Superclass 'MultiSectionReport' to support the 'many' relationship, with many instances of a new 'ReportSection' class. Most of the functionality moved out of the 'Report' to either the superclass or the many class The functionality in the Report was basically a means of pretending there was only one Report in a MultiSectionReport.
All existing code touched only the original class which appeared unchanged in functionality and interface. Rework occurred until all existing unit tests passed.
Step 2: TDD RDL as XML into C# objects
First I created a few unit tests to go from the RDL Xml into an RDL object model.
Why introduce an interim format, you've just doubled your work?
A little while ago I worked on a system at a previous employer that had to interface with another system. The format for data exchange was Xml and they controlled the Schema. I chose to implement an object hierarchy that matched their schema, and from there I would map to our object model. When the schema changed our interim object model changed, but that was contained in one dll. It was a simple release.
Another piece of work evolved where an Xml Schema was used to map from the front end GUI to the database. Every time a new control was needed on the front end, a new column was added to the database. This wasn't a simple release.
In my opinion the interim format is essential.
|
So the interim format is definitely out of scope, but in my experience its required. This has to be 'Nickel plating'.
Step 3: TDD C# RDL.Report into RDL XML
At this point I had a set of secondary objectives
- A requirement to convert some existing reports into RDL reports
- A future need to edit the RDL and store it back in XML.
Now at this point I had to admit that my work was starting to take an uncomfortably long time with the project schedules around me.
Step 4: TDD C#RDL.Report into C# existing report model
This piece of work caused a considerable frustration. My biggest problem was that my earlier work for step 1, required further work to support other features that we needed in the RDL.
Step 5: Integration
Later came the truth points, first we integrated the new reports in web mode. The full web UI was not available but with some breakpoints and calling of the appropriate methods, Hiren simulated an tabbed environment. It Just Worked. The completely rebuilt reporting mechanism worked for legacy and new reports.
Then came the questions,
"That's great, but I want to export the RDL."
I referred to a Unit Test which did just that. This meant that Step 3 was justified.
XmlDocument doc = RDLParser.WriteRDL(rdlReport);
Then we discussed some features that aren't supported in RDL e.g. Formatting #,##0