Friday, July 12, 2013

Tip: enter the mindset of tracking bugs

Having a good tracking of bugs helps a lot. People can easily search for previous bugs, help other people commenting the possible causes and have a clear understanding of the support workforce needed to solve the issues.


Unfortunately, not everybody tests his/her code. Testing is fundamental to facilitate debugging and quality check of you software. No matter what is the dimension of the companies, there are simple step you should always have in your workflow:

-Precommit test: small subset of test that check the main functionalities of your software. It has to compile your code with all the possible configuration allowed to be used but the complete execution should not be longer than 30 minutes.
-Nightly test: bigger subset to run it in the night
-Weekendly test: typically an huge set of tests are run here to stress your code.

It's important also that all the main branches that are going to be released are covered by this tests.

Tip: Compare different branches

If you work in a company with a structured workflow and source control, you can really helpful to compare different branches of the same project between them. Happen to me that I spent 3-4 days working on a test issue that turn out to be solved in the main branch of development. So compare the failing code with another one, or previous revision if the failure appeared only recently, can be a good starting point.

Tip: Don't trust your assumptions

Everybody have assumptions and most of the time we think that those are satisfied. But sometimes that's not true and double-check them is always a good step if the problem seems to rely on magic (but magic doesn't exists)

Wednesday, July 3, 2013

Tip: we are not alone

This is a technical tip that can help when we join a project and something goes wrong but all the code seems clear. Happen to me ones that I was executing two print of the same variable within a distance of few lines and no line was modifing this variable. While I was expecting the print to be the same, I was continuosly get two different values. I spent a lot of time trying to find if was a memory corruption but in the end the issue was due to thread scheduling that overwrites the variable. When we debug, we can have the impression that a single thread is present, but most of the time is not. Even worse if when (as in this example), debugging the program will make the issue disappear due to changing in timing. So basically, if you suspect that multiple threads can run because you don't know perfectly the code, it's always a good idea to instrument your debugging printf with the thread id of the process. In this way you will see more clearly which thread is writing on the console making you understand better how the threads are scheduled.

Tip: Explain to others your finding

The first tip is a general tip that applies to mostly every field where you need to solve a problem. Basically sometime you really need to explain the ideas of a possible solution to someone to really understand it yourself. This can also work using writing but of course the colleague can give you also useful input and ideas. This helps mostly people that like me have a general picture of the whole system but with a not clear knowledge of the specific code we are working on due to inexperience with that code. People that like me prefer a picture rather then a text explaination tend to use more the side of the brain typically used for artistic and visual skills. Unfortunately programming is not a visual rappresentation of an algorithm but a sequence of logic steps. Forcing yourself to explain or write down what's happening in the system helps to convert the wide but opaque visual image you have in your brain to a more specific logical view where all the connection between elements gets explained. It will be like seeing a painting from the distance and discover that is actually a mosaic when we move near to it, where small pieces are connected together to form a single shape.

Tuesday, July 2, 2013

It's doing the wrong thing but everything looks fine....seems magic!!!

I'm working for 1 year for a big company in the embedded engineering field and I have faced some bugs that make me tell to colleagues: "It's doing the wrong thing but everything looks fine....seems magic!!!".
Unfortunately or not, there is no magic. Everything happens from a reason and there are few many cases where this is due to HW issues. Often the bug depends on particular time or configuration that makes it appear or disappear simply adding a safe printf. Also a stressfull day is not the best friend when facing these issues and probably it is better to have a break or simply tackle it the day after. In this way, all the "polarization" your mind has about how the things are (not) working are kind of released and a fresh mind can easily find new views of the problem. Asking for help is also a good way have a new point of view and ideas to solve the issue.
 I will publish time to time some "tip" about what to look at when facing a difficult bug and how to approach them, hoping that sharing what turned to be my solution can help someone on their debugging journey.

Thursday, April 11, 2013

21st Century C - Book Review

In few words this book is a collection of brief introductions of all the aspects regarding programming in C using methods and tools gained probably from the author experience with open or closed source projects. First, this is not a book about C programming language. It is a book for people who start to program in C and want to learn how to start using it in a proper and efficient way to create something more than programming exercises. The main idea that the author want to tell is that C is not only a system level programming language and can be used for other general purpose applications. The book is splitted in 2 main parts: the former talks about setting a C environment that automates most of the tasks as compiling, documenting, testing, releasing, source control and process flow. The latter is about tips of the C language that can be usefull to speed up the work.

The first part is the more detailed and covers most of the aspects of compiling C programs

- Chapter 1: Set yourself for compilation
- Chapter 2: Debug, test, Document
- Chapter 3: Packaging your project
- Chapter 4: Version Control
- Chapter 5: Playing nice with others

Those chapter titles explain most of the content of this first part of the book. They try to guide the reader to have a functional environment that covers all the
steps of the software development.

The tools briefly descripted in this chapter are:

- compilers for different OSes.
- GDB for debugging
- Valgrind for memory problems checking
- Doxygen and CWEB for automated documentation
- Shell, make and Autotools for automatic and easy compiling
- Git for source control
- Tips for write understandable and clean code

The second part of the book is about bits and pieces of the C language:

- Chapter 6: Your Pal pointer
- Chapter 7: C syntax you can ignore
- Chapter 8: Obstacles and opportunities
- Chapter 9: Text
- Chapter 10: Better structures
- Chapter 11: Object-oriented C
- Chapter 12: Libraries

This chapter contains mostly some tips about pointers, string, sintax and data-structure management. It covers some high-level stuff like databases and network connection but really briefly.

In my opinion the author tries to explaino too many things in one single book. He wants to give to C more visibility to the Application Engineers that typically use high abstraction. At the same time he wants to give guidelines about the environment and give hint on some pieces of the language. Except for the first part that covers enough the argument proposed in the chapter title, the second part seems to be a collection of blog tips glued together chosing within the most strange aspects and missing of C. I think as a programmer but even more as bad DIY mechanic that the tool is the most important part of the job. It's fine to use C if you really need to use the performance and the feature it only has, if you don't need those simply don't use it. Java, C#, Python and so on are more easy to use for some applications and should be used instead. Probably application engineers can benefit from this book to have some idea or have a start with C. Newstarters in C and programming can found it useful but they will need to integrate with other resources all the brief description given for some tools (I suggest to read Pragmatic Programmer)