Thursday, June 2, 2016

A (Software) Bug's Life

A local recruiter pinged me today with:
Specifically, we need someone very skilled working through a Linux OS and programming using C Language. This is for a 4 to 6 week assignment with a medical device company in Oakville, ON. They’re currently at the integration stage of a project, but have a section of code causing issues so they would like an expert that can come in, analyze the code and recommend/implement changes to be made.
Which got me reflecting on bug classes:
  • Segfaults/memory leaks: These (as the blog title suggests) are relatively* easy to debug as the code "speaks" about its defectiveness: it crashes, Valgrind flags a bunch of problems, ElectricFence does some brutal boundary checking. Coverity (or Klokwork) will catch some problems.
  • Logic errors: The code does not do what it's designed to but in a corner-case sneaky kind of way. A good QA department [which many times shines by its non-existence] will catch most of them. Sometimes the customer screaming on the phone focuses the mind.
  • Architectural flaws: The code is unsuited for the problem at hand either because it's old and wasn't designed for the current purpose or because the Architect was an imbecile [it happens]. These are the worst as they require the whole circus of refactoring/rearchitecting and lots of NRE for testing.
-ulianov

* = After 16 years of doing that :(