Tell us about a difficult work challenge that you’ve recently encountered.

  What was hard about it? 

Were you satisfied with the outcome? What advice would you give to someone else encountering the
same kind of challenge?
The GUI of the real time software I was working on was reporting many zeroes, but some of the data
wasn’t corrupted. The GUI gets data from a server which has memory access to the embedded
computer running the real time software. What made this problem special is that the same GUI and
server binaries were running correctly in the test environment and everything was working before a
software update some years before. People assumed that the problem has to be in the embedded
computer. I started debugging the problem with no assumptions. Firstly, I checked the header files
used by the GUI, the server and the embedded computer: they were all matching. Then I looked at
the GUI and server struct size and they were matching. Then I checked the struct size in the
embedded computer and I discovered that it was different from test environment and the GUI/server.
Turned out that the product was built with different compiler flags that padded chars in a different way.
So I changed the compiler flags and all components started communicating as expected. The hard
part was to think about compiler differences. Compiler flags were ignored because hidden inside a
makefile that “has always worked”. The advice I give is to not have assumptions and to be curious
and analytical.

As developers, we tend to change the way we develop over time.  How have your development
habits changed recently?   Is there anything new that you’re doing that has been particularly
helpful?  Is there anything that you’ve stopped doing because it wasn’t useful?
Having worked with software that has more than 20 years of history, I understood the tradeoffs
required when dealing with legacy code that needs to work on different computers scattered around
the world and not connected to the internet. A clean sheet design is not a panacea, but it would just
create different bugs.
I keep adding more emphasis on the testing phase of development and how the changes I’m
introducing are fitting in the big picture. I am an advocate for a company coding style because it
makes reading the code much quicker. I now avoid rushing through the development phase just to
deliver the code, rather test twice and deliver once. Plus I realised that it’s not realistic to predict future
software features and make the code “very generic”. Therefore, code will need refactoring over the its
lifespan.

Giuseppe Afentoulis

11 Monument Street, 5th Floor › London EC3R 8AF, UK › cboe.com