Scribd Logo
Upload

Welcome to Scribd!

  • 10 views

    11 Monument Street, 5 Floor London EC3R 8AF, UK

    Uploaded by

    aka ziz
    The GUI of software was reporting zeroes, but some data was not corrupted. The problem was traced to different compiler flags used in the test and production environments, which padded chars differently. This caused a mismatch between struct sizes. The challenge was to think beyond initial assumptions and check for compiler differences. The advice is to not make assumptions and be curious and analytical in problem solving.

    Copyright:

    © All Rights Reserved
    Download as DOCX, PDF, TXT or read online from Scribd

    11 Monument Street, 5 Floor London EC3R 8AF, UK

    Uploaded by

    aka ziz
    10 views1 page
    The GUI of software was reporting zeroes, but some data was not corrupted. The problem was traced to different compiler flags used in the test and production environments, which padded chars differently. This caused a mismatch between struct sizes. The challenge was to think beyond initial assumptions and check for compiler differences. The advice is to not make assumptions and be curious and analytical in problem solving.

    Original Description:

    Original Title

    Untitled

    Copyright

    © © All Rights Reserved

    Available Formats

    DOCX, PDF, TXT or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    The GUI of software was reporting zeroes, but some data was not corrupted. The problem was traced to different compiler flags used in the test and production environments, which padded chars differently. This caused a mismatch between struct sizes. The challenge was to think beyond initial assumptions and check for compiler differences. The advice is to not make assumptions and be curious and analytical in problem solving.

    Copyright:

    © All Rights Reserved
    Download as DOCX, PDF, TXT or read online from Scribd
    Download as docx, pdf, or txt
    10 views1 page

    11 Monument Street, 5 Floor London EC3R 8AF, UK

    Uploaded by

    aka ziz
    The GUI of software was reporting zeroes, but some data was not corrupted. The problem was traced to different compiler flags used in the test and production environments, which padded chars differently. This caused a mismatch between struct sizes. The challenge was to think beyond initial assumptions and check for compiler differences. The advice is to not make assumptions and be curious and analytical in problem solving.

    Copyright:

    © All Rights Reserved
    Download as DOCX, PDF, TXT or read online from Scribd
    Download as docx, pdf, or txt
    of 1

    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

    You might also like