The little things do matter

I, I mean, my friend, just wrapped up an article on object stereotypes.  At the last minute I decided to use an example from a system I worked on several years ago and many employers ago.  I think it was a great illustration of a particular design concept, but it’s a better example of why small design decisions can have dramatic consequences for a company.  Let’s hope that everybody involved with this system has moved on onto a happier place, and is wiser for the experience.  Just to start up the old argument about the relevance of architects on a project, I think the decision I’m criticizing here would be below the purview of many architects, but yet it had some sweeping consequences.

Here we go, a little bug goes kachewww!

  •  A very complicated business process is kicked off when a physical scanning device sends a socket message
  • Listening to the socket and the business processing is effectively the same piece of code.  IP addresses are hard-coded into the VB6 code.
  • The very complicated business process can NOT be simulated except in a testing lab that is set up with physical scanners.
  • Developers cannot adequately unit test the code, so more bugs make it into testing
  • The code does not exhibit separation of concerns, so it is very easy for a developer to cause regression bugs, which aren’t easy to catch because…
  • Developers cannot efficiently unit test the code!
  • Testing is very laborious, making all projects in this codebase more expensive because of the increased time to adequately test the system.
  • Testing is very laborious, so the testers cannot adequately run enough test scenarios to completely test the system in the allotted time, which means…
  • An alarming number of bugs occur in production…
  • Leading to lost productivity in the factories…
  • Leading to lost revenue and decreased profitability…
  • Leading to angriness, bad feelings, and bad morale all the way around…
  • Leading to many good people leaving the division or the company…
  • Leading to a general loss of ability in the I/T division
  • Possibly contributing to the company trying very hard to move all software development overseas? — that might not be justified, but I wonder if the offshoring plans would really be there if the I/T organization was achieving better result.

Oh yeah, at the time I was involved, there were not automated unit tests or deployment automation that could have made regression testing cheaper and test migrations easier and quicker.  Given better project automation, maybe the design wouldn’t have been so bad.

Morale of the story?  You need to apply real design skill at the point of attack, regardless of whatever that person(s) happens to be called.  Pay attention to the little design decisions too. 

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at http://codebetter.com/jeremymiller.
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Joseph Gutierrez

    Have you dealt with this scenario?

    Do you find yourself having to fork your code when you change the scanner hardware?

    I was maintaining a system that had apx. 7 forks due to various hardware changes. maybe 5% of the code was different from each fork.

    The reason? No regression tests. We couldn’t tell if the new software changes were backwards compatible with the old hardware.

    So, now if we needed to make a change to common code, there would be duplication 7x. Scratch that 8x.

    No friggin’ regression tests.