Importance of Business Cases

Today, I was looking at some code that for the life of me, I couldn’t make head or tail what was going on. I was trying to resolve some bugs that were the result of some events that were crossing each other in such a non-logical way that I couldn’t see through the smoke and mirrors of the events. Not even the good old “Debug.WriteLine(“I’m here.”);” across all the events, and recording them out in to a journal, helped me.

Then it struck me. I’d got so used to not writing tests, as this was a WinForm development piece, that I lost the value of what writing tests meant to me. TDD, and testing in general, placed the importance of the behavior of software, way before writing the software solution. I was trying sitting there trying to figure out the complex event model without any cases of what it was I was trying to solve or see the behavior.

A quick step back, and I wrote out the use cases from the very edge of the system, down on a piece of a paper. Starting with the most simple, I flexed the software to try and fulfill the business case. Low and behold, they failed. Then determining the exact step the case was beginning to fail, I could resolve the system to fulfill the case. Iteratively then working through each of the cases I had listed, they were all eventually fulfilled. A quick smoke test of all the features around the points changed and all was well. Boy do I miss TDD, and this is why UI development frustrates me a little. There was no way for me in WinForms to add tests to the model I was working in. I was always going slow, thinking about regression, and constantly retesting the software with a real run.

Today’s lesson – always always hold the business cases right where you can see them – in tests! If you can’t write the tests, then at least write them down in front of you, reminding yourself that what you are developing is to fulfill those cases. It sounds pretty simple, and quite obvious. But it really is easy for a developer to get lost in technical details and complexity of a system, which of course, is a code smell in itself…

This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s