December 2015 – Tech leadership

Is there an acceptable error rate?

As a group, engineers are obsessed with quality. This I believe is what has made us great and helped us make big contributions to human progress. But this obsession isn’t always healthy and in fact on one particular area, errors it maybe downright damaging.

In this case we talk of errors in terms of bugs. A bug can simply be defined as a flaw in software that causes it to produce unexpected results.

Under this definition then quality is measured under the benchmark of number of bugs in the software. That is where we lose it.

This view of quality coupled with obsession to quality leads to engineering teams spending an obscene amount of time hunting for bugs. And even worse, the hunting is done in a linear fashion, ie from class to class in an arbitrary order say by alphabet.

Hunting bugs like this is wasteful and benefits no one, to understand why, we must look at the nature of bugs.

Developers make same mistakes

You and your team are not snowflakes! If there is an error you made, it has probably been made before by another team that uses the same tools that you do. It would be a wise investment to research on this errors to become more aware of their existence in your own codebase or even better yet to avoid making it in the first place.

Pareto principle

The Pareto law states that 80% of the effects come from 20% of the sources. In this case only 20% of the bugs in your code will lead to downtime and other such non desirable events.

Identifying and focusing on this critical bugs ensures that you get the most bang for your buck.

As a corollary, the same law implies that if you find a class or module with bugs, its far more likely that other bugs can be found therein.

Silver bullets

There is absolutely no single principle, method, language or even paradigm that will magically make your bugs disappear. This may seem like an affront on modern practises TDD, BDD, DDD etc but actually it’s a confirmation that if there did exist a particularly effective approach, you would know about it.

So we have concluded there can be quality with an acceptable error rate for some parts of the code, but then how can we redefine quality?

A good way to think about it would be to think of the purpose of the software. In this case we consider bugs not in their own right, but in the context which the bug has an impact on reliability of the product.

Understandably this approach is harder, you can’t just count the reds to greens, but ultimately it will lead to more productive use of our engineering resources.

What is your philosophy on bugs? Talk to us on the comment section below.

Objects can do more than bark

When we talk about OOP and classes to most fresh developers the first thing that comes to mind is a dog. This is because years of training has tought us that a class is a representation of an object, an object with behavior and state. Such as a dog, a dog that barks.

You maybe thinking that this kind of zoological analogies for engineering principles is too simplistic, and you would be right!

While classes in programming can be used to model real life objects this is not what they we’re designed for, in fact this use happens only in fringe cases!

So then what are classes to be used for?

To find the answer to that we must dig way down to The heart of software engineering.

Did you guess it? Yes classes we’re built with the explicit mission to manage complexity!. Incredible isn’t it? Maybe not so much, lets look at some ways in which classes are used in practise.

Encapsulation

As good engineers we know that our code is likely to change especially for tricky areas. In such cases it makes sense to write a class that exposes an interface that is much easier to understand in context and forget about the details pertaining to implementation.

Examples of details to hide include:

Complex algorithms
Database access routines
Business logic

Reduce complexity

For especially complex routines, it makes sense to break them apart into simpler routines and then package all of them into the same class. That way it’s easier to understand each of the individual components of the algorithm in isolation.

Global data

Global data is evil! While most languages have made advances in preventing use of it, for obdurate developers there is always a way. For this cases, classes can provide a way to package all data needed globally into a single class and then use an existing pattern, say Singleton to access it.

NB: Singleton is considered by some to be an anti-pattern. Hector Matos gives a more extensive treatment on the subject here http://krakendev.io/blog/antipatterns-singletons

Packaging relating functionality

Most languages provide a standard package for mathematical and statistical functions. You may however have certain special needs for your own software in which case you can package the functions in one class.

Some examples would include:

Rate calculations
Financial functions
Engineering functions

Control

Classes are especially suited for control of knowledge in your application. Building a class to say control access to outside services or provide meta data greatly simplifies design.

You may want to build a class that say:

Validates information
Controls external devices

In the above mentioned cases, thinking of classes in the primitive real world object sense is not only useless it can actually be harmful.

How do you use comments in your own design? Tell us in the comment section below.

Dealing with elusive bugs

We all have been there before, you make an update to the code, hit refresh and get the dreaded Error Exception. No error message. No way to track what you did wrong.

The sensations that follow can only be described as horrid as you scramble to sort the issue yet you still end up in the same place. Stuck. At this point you start doubting why you even joined this horrid field, with its horrid deadlines. Maybe, just maybe you really are not cut out to be a Software Engineer.

Well the good news is that you are not alone, in fact I am going to discuss how I deal with this very issue myself. The bad news is there is no magic bullet. With that said lets start exploring, but first a story.

In southern Mynammar, locals still hunt monkeys for food. Now if you have ever dealt with monkeys you understand this animals are rather intelligent beings. Yet the burmese invented a very simple trap to catch them.

The design of the trap consists of a hollowed out coconut tied down. The coconut has a small hole through which a monkey can squeeze its hands in. Rice, a delicacy to the monkeys, is put inside the coconut.

The monkey slides in its hand through the small hole and takes in its fill, however it now can not remove the hand.

The hunter then is at leisure to come in and take his game.

Back to our stuckness. We tend to be a bit like the monkey. In solving our problem, we hang on to an idea of the solution. Enticed by it, we don’t let it go even when we feel intuitively know nothing is coming of it. We tug and tug. But what if you we’re to advice the monkey, would you tell it to continue to tug?

Getting unstuck

Retrace where you have been. How did you come up with this solution? What informed the decision
Write the reasons down. And I mean physically, not in your head!
Stare at your list
Take a break. Minimum 30 mins. Ideally a nap would be even better.
Come back and start writing other possible solutions
Start with the first idea, i.e the one that got you stuck
Write all the other ideas as they flow. This is not the time to judge write whatever comes to mind no matter how stupid

While not a guarantee, its likely that another potential solution will come to you, this one more suited to your problem.

Have you been in such a situation before? How did you handle it? Talk to us in the comment section below.