Solving development problems like a pro

If you’re a software developer, I’m pretty sure you ran into a problem that you didn’t know how to solve. Ranging from bugs to firewall issues, the number of possible problems is immense and somehow as developers we need to fix every problem that comes our way.

That doesn’t mean we are helpless and are just waiting for an issue to come along that is too difficult to solve so we can finally admit that we are terrible developers. Every problem can be solved. You just need the right tools under your belt. Both at my work and in the community I get asked a lot of questions by people who are stuck on a problem. Although I love to help I would like to share the approach I always take when tackling a new and difficult problem. I hope some of the following ideas help you when tackling a new problem. If not, just ignore my ramblings 😉

How would you solve this?

Let’s take two examples that I came across last month.

Someone had to write C# code to interface with an IoT device through an API. The API returns an encoded string that you need to parse to get sensor data from the device. There was some sample JavaScript code available that was difficult to read and used bit shifting to parse the string. The developer had already converted a lot of the JavaScript code but was running into issues where he got incorrect results. He thought this had to do with the bit shifting part.

Another situation. A developer was working on a Java application. The application was then compiled into a Docker image and deployed to OpenShift on Azure. Locally everything worked perfectly. However, the deployed application couldn’t be accessed remotely.

Both developers spend quite some time trying to get everything to work and eventually asked for help.

If they would approach you, knowing only the tiny description you’ve had, how would you help them?

Break it down!

I’m not saying I’m an expert and I can solve everything. But I do have an approach when problems like this happen and that is to break things down.

Calling an API, decoding a string that contains multiple sensor inputs and validating the result is a complex task. Building, Dockerizing and deploying an application to an orchestrator is complex but on a whole different level. Both tasks have a lot of elements that all work together. You can’t pinpoint the issue by simply looking at it.
My approach with these types of problems is to make the problem smaller. Break it down, take away as many variables as possible until you can oversee the problem and understand it.

OpenShift

Take the OpenShift deployment. I have no experience with OpenShift so I was flying blind but we were still able to fix the problem. Start with the variables you know of. You have a custom application on an unknown platform running in the cloud. Locally it works. Start disassembling the problem. Is the problem in your code? Is it in the configuration of OpenShift? Does it have something to do with Azure?

Then rank these problems in order of likelihood. The program works locally so it looks like the issue has something to do with the OpenShift or Azure configuration. Now start taking away variables. To proof the problem is not with your code, just take a sample application that you know works and deploy it. Still can’t access it? Then you’ve eliminated your application as the culprit. If it does work, the problem is with your application and you can start on that avenue.

In this case, the sample application did work! So we suddenly knew the problem was with our application or at least the configuration. After inspecting the configuration files, we noticed that we mapped the wrong external and local ports. Quick fix and everything worked.

String parsing

Now on to the IoT project. Here we also have a lot of moving components. Do we call the API with the correct info? Do we get the correct result back? Is the error in parsing the string? If so, which part? I encouraged the developer to take a step back and stop fiddling with the code in the hope that some change would lead to the right result.

Checking if the API gave back the right result is easy. Just install Fiddler and inspect the HTTP traffic. This wasn’t the issue. The decoding of the string remained. We had some sample data where we could see which input should lead to which output.
Then came the most important step: create a unit test. The first unit test was more of and end to end test where we took a complete string and validated the complete output. Of course this test failed.

[TestMethod]
public void TestExamplePayload()
{
    // 01010002310500070daa1100
    var message = CreateJsonInputWrapperMessage("0100f402380400170502070dee1000f6010a1102");

    var decoder = new MessageDecoder(message); 

    DecodedModel result = decoder.GetModel("0100f402380400170502070dee1000f6010a1102");

    Assert.AreEqual(24.4, result.Temperature);
    Assert.AreEqual(56, result.Humidity);
    Assert.AreEqual(23, result.Light);
    Assert.AreEqual(2, result.Motion);
    Assert.AreEqual(null, result.Co2);
    Assert.AreEqual(3566, result.Vdd);
    Assert.AreEqual(2, result.Occupancy);
    Assert.AreEqual(24.6, result.IrInternalTemperature);
    Assert.AreEqual(26.6, result.IrExternalTemperature);
}

We then took one variable that we wanted to verify. We disabled the rest of the code and created a unit test for that single value. One by one we added a variable. This helped us go through the converted JavaScript/C# code and really understand what each part did. One by one the unit tests started turning green and in the end we discovered that the whole bit shifting part wasn’t necessary since he already used a byte array and C# did the conversion automatically.

Conclusion

Solving large, complex problems is hard. Solving small, simple problems is easy. Whenever I get confronted with a difficult problem I do the following things:

  • Identify the different components
  • Sort the components on which I think is the most likely suspect
  • Eliminate components

So next time you come to me with a problem I’m definitely going to help you. But maybe I’ll first point you to this blog post 😉

What do you think? Does this approach help you in solving problems? Do you have a different strategy? Please leave a comment!

Update In the meantime, my colleague Mart de Graaf posted an article about what he learned from the IoT issue. Nice read, especially for starting developers.

Share

Leave a Reply

Your email address will not be published. Required fields are marked *

Post comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.