5 steps of debugging

1. Understand the context
   If you are confronted with a bug, you first have to understand the circumstances. What is the software/system supposed to do? What was the idea of the developer(s)? The more you understand, the better. That’s why its also easier to debug you own code. But for foreign code don’t want to waste too much time, rather you will assume certain things. That brings us to point 2:
2. Verify your assumptions
   While understanding a system, you will also assume certain things. For example if you see a “getSomething” method, you most likely assume that it just returns an existing value. Verify that. I’ve seen many cases where a method does not what it says.
   It’s also likely that the system works as expected and you just forgot to check the system configuration. I already experienced hours of debugging after finding a simple setting that was just there with an unexpected value.
3. Check the logs
   I already wrote about it: logs have the power to reveal internal state and quickly lead you into the right direction. At least they help you to understand the context better.
   Of course its sometimes hard to find the proper logs or sometimes there are none. If you have the ability to add logs to some silent but potentially problematic code, then do that. In the early PHP days this is how we did debugging: an “echo” every 5 lines printing variables. :D
4. Check the input data
   What has an impact on how the system works? Besides Parameters and Configs there is the data itself. Verify that it is properly formatted and accessible. In the age of Unicode it may still happen, that some ISO formatted file or some strange line-brakes break the system.
   But also the content of the files could have unexpected data.
5. Reproduce with minimal setup
   If nothing helps, try to reproduce the bug in a smaller setup. That’s especially true for coding bugs that are hard to reproduce in the productive system. Try to build a small test case that leads to the same error. Due to a smaller setup, the debugging is easier.

Still lost? Well, sometimes you have to dig through the whole mud to fix things. ;)

Most likely those 5 steps are not complete. If you have some more standard steps to go during debugging, let me know in the comments.

From Developer to Software Engineer

The last few years I experienced the difference between software development and software engineering. I guess you heard about the “Definition of Done” before and I’ve seen some of those definitions, but I am still concerned, that the whole picture is rarely seen. As least I haven’t seen it a long time as a developer.

What does it mean to build a piece of software?

As a (fresh) developer you want to start coding as soon as you have a fraction of the basic idea, what the software should do. This is how we use to think, because coding is what we actually do and where we feel productive. However we are not used to questioning the requirements. Maybe there is something wrong already and we would just implement something unnecessary? Did we understand the purpose of the software, how it should be used and what its benefits are for daily work?

Often we ignore those questions and let someone else answer them. Maybe the product manager will take care of it. It’s not our business, how the sales guy will sell it and we barely have to care about how some operator will do the installation and keep it running.

Getting a software engineer means for me to start seeing that whole picture and start taking responsibility for all of those questions. It means to understand the requirements and already start searching for defects there. It means to understand the needs of the other teams and how your decisions influence their work. And finally it means to understand the users need, their environment and their business.

How can we get such a understanding? Well for me it helped to get in touch with those people – not just for a project or the development of a product, but also in daily live: have lunch with them or get out for a beer. Have an open ear for their problems without trying to solve them or doing their job. Just understand them and keep in mind, that your programming decisions might influence their work.

If you fail, at least learn from it

This morning I woke up very early on my own, around one hour before my early alarm, starting to think about a project I messed up 3 years ago and what I have could done better. Wait – What? Isn’t there anything better to think about at that time, like breakfast for example… anyways, this is how my brain works, I guess.

So I thought about the root causes why the project failed and what I could have done better or should have done completly different. Here are some learning I recognized:

1. Have the currage to find the best matching tool (aka never use the hammer for a screw)

Our software was not made for such an scenario, so I started to customize our solution to the requirements of the customer. If I would have taken a look on the requirements and thought about the impact on our software, I would have declined the project or simply used just the relevant parts from our software and combined it with software that already fulfiled the requirements.

2. Find your own decisions were ever possible

At some point I realized, it was too much data, for our software, to get the necessary performance. I needed a database I could put in all the data, our software shouldn’t touch. But I haven’t used much databases at that time, so I asked the customer what kind of database I should use. I took the first one he told me to, without evaluating it or even thinking about it on a conceptual level, althoug I noticed the nescience of the customer. I was such a fool. It was horrible. I was working with a unfitting tool I never really wanted.

The better solution would have been, to find my own decision by finding experienced people and taking the time, to evaluate the necessary software in the context of the requirements. This is the essence of my next learning:

3. Take your time to make a plan – this is much more productive than producing code

4. Be honest about the shit

The most things I did were “motivated” by the preassure I got: the budget was very low, the customer was promised to get first results after two weeks and there was other work to do as well and the requirements never ever fit to the estimations.

If you are in a such a situation – don’t try to handle it. Be serious about your responsablity and tell your boss about it. I think it might even be an option to refuse doing such unnecessary work – it’s better for all. Instead strive for a solution that might work for all.

I know there is the SNAFU principle, but you must be as honest and detailed as possible.

5. If you fail, at least learn from it

The best to do so is to get some distance – for example 3 years ;)… From a distance you’ll get a proper view on the failure and are able to extract the experience from it. The best way however, is to learn from the failures of others, but this is much harder (and another topic).

What would you need for your perfect task planer?

For a while now I am searching for a task planer tool which fits to my needs. But I can’t find one, so I started to think about writing my own tool. I already started working on a mock-up which is representing my basic thoughts, but I fear this might get a huge project; so participate on another comparable project would also be an option for me.

The first step of course is to find out, what I actually need and what are my requirements? With answering this question there is also the possibility to find a matching tool.
However first of all I would like to know how are you organizing your tasks without loosing control and overview?
Which features would you love to see in your tool?

I am currently organizing my tasks with outlook and these are the features I would really love inside a task managing tool:

• getting the information when each task might get finished; this should base on the estimated time I can specify for tasks, also considering my calendar, my daily working time, the need for breaks etc.
• getting the information which task to do next; this one could be calculated on deadlines, priorities and estimated time
• integration with my email account so new emails are automatically considered as a “has to be read task which need 5 minutes minimum”
• tracking my work, the interruptions, breaks etc., so I can improve my workflows and get more productive

Do you know a tool that could satisfy my needs? :)