Software Engineering V2

As interesting and captivating as software engineering is, we tend to forget how much we rely on the knowledge of people coming from other domains. Surely in the era of information, everything seems to orbit around computer science. Not quite. One of the first things to become clear is how much information is out there that I don't know. Maybe it sounds a bit pessimistic but I take it as a challenge (I’m a member of the DUT19 team after all).

As an effort to keep us all motivated and up to date the managers organized a meeting where the chiefs of every department presented what was going on in their group. I was particularly interested in the aerodynamic concepts that were brought up. Controlled counterwise vortexes that create a stream of air between them? Awesome.

Obviously a lot of the software for the car is low level, which makes it all the more interesting. This isn’t exactly the kind of code that make a button blink on a webpage nobody cares about. A bug here means a DNF at one of the events at the competition. My first steps were learning from the veterans and trying to understand their thought process in the code written in the previous years. The software department and I did that while also testing the drivers interacting with the peripherals of the boards. Soon enough I’ll be contributing to the software running on the soon-to-be Formula Student champion car. We’ve put together a tight schedule for the coming year. This will allow us to test everything extensively and maybe work on the “could have” features.

Turns out documenting code is quite a big deal. While your idea is quite clear to you, it might not seem so for the developer that is going to read your code years later. I used to roll my eyes when somebody told me to comment something that I deemed obvious. In some cases, there were so many “noise” comments, that i would remove them temporarily just so I can read the code to get a better understanding. I still think that there are trivial instructions that do not need explanation. However when a couple of trivial instructions are bundled together it becomes less and less clear what the purpose of the code is. Moreover, even if it is easy to read and understand it, it will cost you time to do so.

In my opinion, it is a good practice to make sure you understand as much as possible about every bit of your code. Documentation cannot and should not fully explain the inner workings of a method or class or so on. Sometimes the way a function achieves something is relevant to the one using it and therefore understanding it line by line is a good idea. However when your code depends on a large set of libraries and drivers, you would much rather quickly read the documentation.

Working on such embedded software has its challenges but it surely is interesting. Some of the concepts that I’ve learned in some of the CS courses are coming back. Recently, I was looking at the code from the previous years and recognized the Observer pattern used for inter-process communication. I’ve also seen the use of alternating data buffers in combination with semaphores to ensure that two processes cannot modify the same data at the same time. Seeing the value of such techniques in practice really gives you a much better grasp of the concept.