Bugs vs. Defects

I really don’t like the word ‘bug’ when describing a piece of (missing) functionality that doesn’t work correctly or has unintended consequences. I much prefer the more accurate word: defects. If you use ‘bugs’, you’re doing yourself, your projects, and your customers a disservice.

It’s a Mindset

The word ‘bug’ brings a cutesy picture of a ladybug or maybe a little grasshopper, or maybe an uglier thing like a house fly or cockroach. Get real and be professional: these are defects. Don’t trivialize your work and its consequences. Call it what it is.

Imagine you buy a car or a house (here we go with the metaphors) – how would you feel if the driver’s door had a flaw whereby the handle or lever would open the trunk on each odd turn, and open the driver’s door on each even turn? What about a defect where your GPS took you to the wrong destination? How frustrating or expensive would it be, for you as the customer, to work around that?

If your software doesn’t do what you intended/written, then you haven’t tested enough. Shipping that product is, by and large, up to you. If your product contains untested/unpredictable behaviour, that’s all on you!

Not Helping

Yes, it’s a nice story about Grace Hopper and the moth at Harvard. Of course, it’s an easy feel-better-about-yourself term that’s used. However, it becomes an uphill battle for those professionals who care about terminology when there are products called Bugzilla and FogBugz in the bug-tracking line of programs. I use both, and both are great at what they do.

Of course, the term ‘bug’ is well engrained into our minds and language, and has even crept into the language of the non-programmer.

Personal Software Process

This reminds me of one of the textbooks at BCIT’s CST program. It’s the Personal Software Process by Watts S. Humphrey. Watts is crazy-focused on software quality. One distinct lesson I got from that particular course was the concept of constantly recording and measuring. Defects per 1000 lines of code (KLOC). The other theme, perhaps in the book, or with that particular instructor, was this idea of ‘defects’, and not ‘bugs’.

Own Your Defects

I’ve come to this conclusion for myself when thinking about flaws in software:

Don’t trivialize those flaws with your words, own them. Call them what they are – flaws and defects!

Consider your behaviour and desires as a customer when you visit:

a) your favourite local coffee shop - you specify what you'd like, rather than how it's made. You care about the outcome, but rarely care about the process/sequences/steps that are followed as it's being constructed.
b) a Subway/Quiznos shop - you care equally about the outcome and the construction. Meats, veggies, bread type, order of placement of each, precise amount of mustard, pickles, etc.

The difference here is: you aren't instructing the coffee barista on how to steam the milk, or when to start brewing the espresso. You don't remind them that their level of ground beans is getting low, or where to store the milk. You are happy to assume they know their job best, and order of operations is properly under their control. They have their efficiencies to care about, and you're happy to let them manage that.

Consider now your desires as a programmer when your task is to find customers with a condition. Let's say we want to use this contrived example:

    Find the customers whose account balance owing is over $5,000. Find the youngest customer in that set. 
 

The Sandwich Model of Algorithms

//find all customers with the appropriate account balance
var owingOver5000 = new List<Customer>();
foreach (Customer c in myCustomers)
{
  if (c.TotalAmountOwing > 5000)
  {
    owingOver5000.Add(c);
  }
} 

var youngestCust;
DateTime youngestBirthdate=null; 

foreach(Customer c in owingOver5000)
{
  //initialize on the first go-round; many ways to do this.
  if (youngestBirthdate==null)
  {
      youngestBirthdate=c.BirthDate;
  } 

  //find the youngest by their age
  if (c.Birthdate < youngestBirthdate) //pretend nobody has the same birthdate ;)
  {
    youngestCust = c;
  }
}
//you now have youngestCust populated (in most cases) 

Very fine-grain operations are explicitly laid out by the developer, and execution path follows exactly what the developer wrote. Defects and all! The number of defects is up to you!

The Coffee Shop Model of Algorithms

Consider now the Coffee Shop model of this algorithm. We'll use LINQ.

var youngestCust = myCustomers
                    .Where(c=>c.TotalAmountOwing > 5000)
                    .OrderBy(c=>c.BirthDate)
                    .SingleOrDefault(); 

It should be obvious to you now, if it wasn't at the start: the LINQ extension methods are doing all the looping for you, and taking care of all the small bits and housekeeping. You, as the customer, don't want to care about how it's found, but rather, you declare what you want.

Outsource Your Loops

I hate to steal Eric Lippert's thought on this, but it's worth saying once more in a different way:

Avoid loops. They’re becoming a code smell. Let built-in methods and functionality do the boring non-value added logic for you.

You should be focused on YOUR business logic or end-goals (i.e. eating your sandwich and drinking your coffee), and less on syntax + language constructs. Take advantage of more declarative constructs provided in your language/framework. LINQ is a perfect example of this.

*this post is a mashup of Luca Bolognese's PDC 2008 F# metaphor and Eric Lippert's post on loops. Apologies to both!

2009 was a great year for me professionally. I've focused on continually learning new things and patterns in software development. There was a fair amount of professional growth, learning, and the realization that there is so much more to learn.

One benefit of taking a new job/position is that it helps you realize how much you don't know. I've taken on a few new skills/technologies, sharpened a few existing skills, and challenged myself to re-evaluate some beliefs or patterns I've held for a while. One exciting event was a presentation to the British Columbia Health CIO Council. The topic was our adoption of the Enterprise Master Patient Index project as part of the Electronic Health Record initiative.

Tech Learnings

ASP.NET MVC

My opinion of ASP.NET MVC went from 'terrible idea' in 2007 to 'awesome' today. At first I just did not get ASP.NET MVC; I thought it was classic ASP all over again, and I totally balked. I was looking for asp:GridViews and trying to output server controls. Then I got it. What really nailed it for me was Dino Esposito's talk at DevConnections in Fall 2008 where he made clear the distinction of ASP.NET (the HTTP runtime) and WebForms (the abstraction of state and page lifecycle). I’ll frequently use Hanselman’s Motorcycle vs Car analogy.

Not to knock on WebForms, because it’s provided a lot of benefit to me, my projects,  and my customers for years. WebForms provides so much abstraction with its incredible productivity gains, but feels a bit dirty when it comes to control-over-HTML.

I dove into ASP.NET MVC, and the NerdDinner sample app was a huge help in many respects. I followed up by purchasing the Hanselman/Haack/Guthrie/Conery MVC book, which is a great resource.

I was lucky enough to develop and implement 3 MVC apps, and have 2 personal projects using ASP.NET MVC. I am excited to use ASP.NET MVC for projects where I care about markup and testability. More from Dino on ASP.NET MVC.

LINQ

A major tool to discover and learn more about in 2009. Upcoming investment in the dead-tree edition of LINQ In Action http://www.manning.com/marguerie/. I am finding it fun to have a list of objects and write a LINQ query. It makes coding that much easier! I started with the 'query' syntax, but much rather prefer the 'dot notation' syntax. The 'query' syntax for joins, however is much easier to read and write. 

jQuery

No question JavaScript has been a help in my web projects, but a pain to work with in the browser at development-time. Most of my logic has been server-side, but I know I can do better to give the user a better experience in using my apps. jQuery has been fun to start learning, and it's satisfying to be able to use a few lines of code with terse syntax to have your form elements behave as you want. The usability of the jQuery libraries is stunning. Truly this is a 'for-developers, by-developers' library, like they've anticipated your needs. I have yet to have a need and not have jQuery have a solution. I am looking forward to more jQuery in 2010.

Systems Integration & Health Care Messaging

A major learning for me was around integrating different existing systems. I had gotten used to creating greenfield solutions or solutions where both/all ends were totally under my control. I had smaller integration subprojects where, for example, I was taking waterslide orders from an Excel document, and creating new records in my app. In that case, my solution was the consumer of that data.

In my recent integration projects, the source and end consumer is a downstream system that I don't have control of. Actually my project is the broker/intermediaries between the source and destination. Further complicating things, there are 3 systems within this intermediary, each on different technology stacks. So the learning for me was to be the middle-man, and to work with constraints on both side of that data transfer.

Unit Testing

In my projects previous, I'd tried to create unit testing projects to help keep my code meet its requirements, and to keep code changes from deviating away from those requirements. Only recently have I begun to rely on unit tests to ensure my changes don't break.

With VS 2005, I was using NUnit to test my business logic in .dll assemblies. At the time I had lots of code in code-behind, and of course, that's difficult to put under test. Fast forward to today with Visual Studio's Test Project, I've abandoned NUnit. After writing a (large ? 70+ tests) set of unit tests for this particular set of web service logic have I finally proved to myself the value of unit tests. The payoff moments came when my implementations had to change (LINQifying some algorithm), and when new requirements/feature were added.

From here on out, any important logic will be under test. I feel a book purchase upcoming:  The Art of Unit Testing by Roy Osherove

Large Scale Applications

I've had the pleasure of taking on two large scale health care applications this year. One had its technical requirements well laid out (mostly), and the other was a collaborative effort with my counterparts 500km away. Some lessons learned around large projects: 

• large numbers/skills/discipline/remoteness of team members make for interesting and different challenges on each of those attributes
• scalability will come back to bite you if you haven't prepared!

Project Successes

Looking Toward 2010

My answer to New Years resolutions is: why wait until the turn of the year to set goals for self-improvement? What were you doing throughout the year?! In any case, my list of professional goals this year are:

• Learn A New Language! I have been listening to the endless talk of Ruby and Python. I fully value the concept of 'knowing more than one and many languages', both in software and in life. So this year, I'll be taking on (one of) Ruby, Python or F#. The great thing about these languages is that they're dynamically typed. F# is a first-class .NET language, but it's not clear whether IronRuby and IronPython will be first class languages in Visual Studio 2010. I am looking forward to F# in that it's a functional programming language. I will be learning WHEN to use a functional language, and I will be posting my findings. My first intro is Luca Bolognese's PDC 2008 video presentation: "An Introduction to Microsoft F#".  'let' doesn't mean assign a value to a variable, but bind a value to a symbol!
• Deploy More Personal Projects! There's nothing worse for a developer with ideas than to NOT convert on them. Smaller designs, shorter iterations, deploy more. Cost isn't an issue, really!
• Find A Good Webhost. I think I've already done this with SoftSys. Their .NET 3.5 hosting packages include SQL Server, which is my #1 requirement for hosting. Goodbye DiscountASP!
• Move This Blog to SubText! I feel that BlogEngine.NET was an upgrade over DasBlog. Both aren't being actively developed and maintained. After having used SubText for my internal blog, I feel comfortable enough with SubText and *its continued development*! It requires SQL Server 2005 / Express.
• Do These Things Better: Document changes. Make more graphs.

How Are You Improving ?

What professional challenges and successes did you have? How are you striving to be better in what you do? Are you ‘sharpening the saw’ in regards to your professional skills?