When developers forget to be developers

Oftentimes, I would be discussing a task with a fellow developer, and when an interaction scenario is brought up, they would say, “Okay, I’ll make sure to test that.” Their implementation seems to be targeted at handling the new functionality that is requested, and they have no plans of handling anything else unless something is detected not to work.

But a developer’s task is to develop a solution that will cover interaction scenarios. While testing is necessary, developers should first develop. 

Some interactions can only be found from the code. This is because they arise from the way the code is implemented, rather than the way the product is used. This is commonly the case for race conditions. While testers can carry out tests where they execute two (or more) functionalities at the same time to see whether everything still works properly, if they do not hit a specific timing, the tests may still pass when there is a bug in the code.

However, a developer can easily detect a race condition from the code, if only they were to think of the interaction scenario in the first place. Then they can handle the scenario properly. 

(I stress the “if” above because it often happens that detecting interactions is overlooked. But that would be a separate discussion…)

To all developers, take note: If a scenario works when you test it, but you don’t know how it works, you did not develop that solution. So remember to do your job as a developer!

The fear of updating existing code

In my code reviews, I often see engineers adding on to existing code even when a simpler solution is to modify it.

For example, take a look at this code:

void update_door_position(position_type position)
{
    switch (position)
    {
        case OPEN:
            set_door_opening(100); // fully open (100%)
            break;
        case SLIGHTLY_OPEN:
            turn_on(30);
            break;
        case CLOSED:
            set_door_opening(0); // fully closed (0%)
            break;
        default:
            break;
    }
}

The function allows us to request three different positions for a door, and it adjusts the door opening accordingly.

But sometimes the initial implementation does not have so many positions. Sometimes the first version of the code is simply this:

void update_door_position(bool open)
{
    if (open)
    {
        set_door_opening(100); // fully open (100%)
    }
    else
    {
        set_door_opening(0); // fully closed (0%)
    }
}

Here the door starts off with only an open position and a closed position, and then comes an additional request: “Sometimes our users would like to open the door just a little bit to let some air through, instead of opening it wide to walk through.”

This is where I see many engineers end up modifying the code into this:

void update_door_position(bool open, bool slightly)
{
    if (open)
    {
        if (slightly)
        {
            set_door_opening(30);
        }
        else
        {
            set_door_opening(100); // fully open (100%)
        }
    }
    else
    {
        set_door_opening(0); // fully closed (0%)
    }
}

Even though this code does the exact same thing as the first chunk of code above, it is bulkier with more parameters to handle. Every time we want to call this function, we have to decide the value of two parameters instead of just one.

But what I find is, if the same engineers were asked to write the code from scratch for the three door positions, many would have written the first code above.

There seems to be a general reluctance to touch whatever has already been written (especially by someone else). Instead, flags are added here and there to achieve new functionality. However, this is not a good practice because it creates a code that is more difficult to read and to maintain. Imagine if more positions were added later for the door; how many flags would we use then?

When editing code, it is better to think about how the code should have been written if the new functionality had been there from the start. When we read code, we want to know what the code does right now, and not how many different phases had been used to add new functionality to the code. So we should write code that gives that kind of information, as simply as possible.