Making the extra effort
Warning: rant ahead!
I’m now the sole developer working on arguably one of the largest projects for our company, and things are going well. However, I keep falling into traps and pitfalls created by one of the projects last programmers.
One of his “favourite” tricks seems to be creating a business layer method that populates an object based on data retrieved from a database. Nothing odd there.. but it’s when you have the need to re-use one of his functions that you end up falling right into his carefully seeded trap!
For example, we have an object called “CustomerSite”, which as the name suggests, has various properties that pertain to a customer’s site – 15 individual properties to be exact.
Whilst writing an additional management page for the project today, I had the need to get a “CustomerSite” object from the database, based on the site code.
A quick look through our data access methods reveals a pre-written method “GetCustomerSiteBySiteCode”. Excellent; No need to write a new stored proc and no need to write the retrieval C# code!
However, in hindsight I knew this particular programmer had written both the retrieval method and the stored proc, so I should have checked ahead of time, but alas I did not…
So I fire up my new shiny page and all goes well, right up to when my codebehind calls the “GetCustomerSiteBySiteCode” method. At which point, my page throws a wobbly with invalid use of null errors throwing hand over fist.
Initially, I start checking the database to make sure the data is actually fine for the customer site I selected. With that being fine, I check my code to make sure I’m not doing anything daft. Happy that I’ve not, it’s time to place a breakpoint and step on through…
It’s at the point I step into “GetCustomerSiteBySiteCode” that I realise I’ve been stung; Despite the “CustomerSite” object having 15 properties, only TWO of them are being set by this method – the rest are simply set to null.
After altering the method to actually populate all 15 properties, I checked the stored procedure, to find two select statements, the first with all fifteen fields commented out with the note “Probably want to include these fields later, but haven’t the need to use them yet.”
To quote Peter Griffin “This really grinds my gears”. It was the programmer who created the “CustomerSite” object to begin with, and it’s always had all 15 properties from the get go. It’s simply a case of laziness and lack of forethought; there’s every reason to believe that this method would be called elsewhere, especially as when he was working on the project, it was a multi-person project.
Grr.