Month: October 2020

Testing Sorely Needed

I’m working on an implementation of the dgemm matrix multiply function for the BLAS interface [1] for a Parallel Computation course. While trying to introduce a feature to take advantage of the processor’s cache hierarchy, I ran into a reoccurring issue in my software development career. This time it bothered me more than usual.

In order to complete the feature, four components would need to be added or changed for the program to function correctly. For someone who isn’t habituated to test their code after incremental changes, four changes is basically nothing. “Watch me perform dependency inversion while thrashing every class in the codebase,” says the programmer who had it coming. [2] But for someone who now expects more from himself as a software developer, this was now uncomfortable.

“If I think this through, map it out on paper, and act cautiously, I can probably get it on my first try,” is what I use to say. I knew better this time, and I was correct. It didn’t work the first time.

The problem isn’t that it didn’t work the first time. The problem was that I had made too many changes at once and now it was impossible to pinpoint which piece was failing just by looking at the result of my Frankenstein-memory-access-matrix-multiply.

Three of the four components were mostly self-contained and should have been unit tested. These were also the most complex changes, so they DEFINITELY should have been unit tested. What were the two obstacles that prevented me from unit testing this code?

First, was inexperience. I should own up to my own shortcomings before criticizing the code of other people. Even though I’ve been using C/C++ longer than any other language, there’s a lot I still need to learn. Just in this codebase alone: make files, extern ‘C’ code, and static inline functions [3] all showed me how little I truly know. Furthermore, I’ve never properly tested C/C++ software before with unit and integration testing. So there was no way I was going to slap a testing framework into this codebase without first receiving many well deserved battle scars.

Second, was code structure. Two things seem almost inescapable in software.

  1. If you don’t start a program with the intention of testing, as the program grows, it will probably get too difficult to ever test.
  2. Even when you start out testing a codebase, as the project grows and becomes more complex, it will eventually also get too difficult to test.

This code is strictly academic, for learning purposes only. They thankfully included some handy debugging functionality to the project, but its creators didn’t imagine people would need to properly test this code. From the complexity of how the code is linked together to the static inline functions that make some important components impossible to access, this is not convenient to test.

I write this the day of my well learned lesson. In the coming weeks, I hope to learn a number of things about software testing in general, testing C/C++, and understanding some of the internals that have given me so much grief today.

References:

  1. http://www.netlib.org/blas/
  2. Yea, I’ve done that. Not proud of it. I got what I deserved.
  3. Static inline functions actually made a lot of sense in this context since we’re trying to optimize the code to be wicked fast. Why declare a C function as static inline?

That Which We Need the Most

Six years ago, coming out of high school, I was terrified of public speaking, and honestly not the most comfortable conversationalist. What I needed most, was a voice. But the process of acquiring that voice required facing the fear at the root of my problem. There was no way to skip the hurdle or get around the fear.

Tuesday nights have become a symbol of growth for me. Tuesday nights are when I attend Toastmaster International meetings to become a better communicator. Most first-time attendees are invited to participate in Table Topics, an opportunity to speak for two minutes on an impromptu subject. It would be interesting to get the real statistic on how often first timers decline the opportunity. I have a feeling it’s around thirty percent. After having done a single table topics speech though, I don’t think people decline to speak out of fear ever again. Having seen this process over and over, I developed a simple heuristic that I’ve proudly used in some critical moments in life, though not as often as I would have liked: “If an activity gives me anxiety, it probably means I should do it!”

Carl Jung said it better though:

“That which we need the most will be found where we least want to look.’

It’s beautiful, simple, powerful, and exactly what we need to hear. There’s no better angle, no plan B, no waiting it out, and no way around our fears. There’s only moving forward into the darkness [1].

If I truly adhered to this principle, there’s no telling how much better my life could be. My current plague has been with me since my undergraduate program, the fear to apply for jobs. Writing resumes, outlining my strengths and weaknesses, putting myself out there, reaching out to people, and envisioning what I want out of a career are all activities that have developed monstrous and terrifying characteristics. I tend to keep a safe distance from them.

Is what we fear what defines our actions though? Do we look to our fears and makes Not-To-Do lists each morning? We should probably be asking ourselves what we need out of life. Well a year from now I’ll need a job so that I can support myself and show my girlfriend that she hasn’t wasted the lasted six years of her life. But I don’t just need a job.

What do I need the most? The ability to charter the course of my career. This includes:

  • Being able to market myself honestly – my value and my experiences.
  • Searching for teams and projects that align with my skills, principles, and interests.
  • Reaching out to friends, acquaintances, and strangers to have open and direct conversations about the challenges and needs of a company.
  • Being okay with rejection.

Framed by this critical message, “That which we fear the most will be found where we least want to look”, there seems to only be two options for me:

  1. Waste another year of my life waiting for the fear to go away, only to be faced with the exact same dilemma.
  2. “Do the thing [to] have the power.” [1]

I think I know what I’m doing this weekend.

References

  1. Dr. Jordan Peterson: Knights of the Round Table
  2. Ralph Waldo Emerson

What is software engineering?

This was the prompt of a small assignment in my software engineering course. At first, I was skeptical of such a trivial assignment, but it actually captivated my attention and helped me reflect on an important work experience. What this question is really about is understanding the responsibilities and expectations of the professionals and their work in this industry. And that, is no trivial matter.

Though I’m not able to fully answer this question yet, what I have thus far lies in an experience I had in my short time at Northrop Grumman and in a textbook.

I had the opportunity to get to know about other projects at the Northrop facility. One of them was digitalization of the cockpit for the UH-60L Black Hawk helicopter (UH-60V).[2] Developing software that controls the flight of military aircraft requires adherence to strict guidelines and regulations, namely DO-178B. For this reason, the software developers on the UH-60V team don’t do any programming, at least not in the way computer science students instinctively think about programming. They use Model-Based (or Model-Driven) Development and the SCADE software suite. For users of SCADE, their models are their documentation (at least one form of it) and their code. SCADE generates code using the developed models and the code it generates is certified to be DO-178B Level A.[3] “The levels are defined in term of the potential consequence of an undetected error in the software certified at this level.” [4] And Level A means, if there is an error in the code, there is more than likely a “catastrophic” outcome.[4]

There are many industries that software is developed for, each with its own set of regulations that need to be followed, some more strict than others. Developing software to keep aircraft in the sky has some of the strictest regulations. “Software Engineering” in this sub-industry means almost zero hand-written code. I don’t think projects are prohibited from coding, but the hoops that must be jumped through to prove that the code is error free and meets DO-178B Level A standards makes it financially impractical to introduce coding. With SCADE and Model-Based Development, they can provide the level of quality that is expected by the customer and do so on budget.

As a kid straight out of school, this was foreign to me. It didn’t look anything like the software engineering I’d seen. But I got to know people on that team and they shipped great software.

In his book, Software Engineering: A Practitioner’s Approach, Roger Pressman describes the realities and challenges of software in the twenty-first century before defining software engineering. Below are the summaries of those challenges and their takeaways [1]:

  • Software is now in such high demand that there are many forces pushing and pulling the direction of a project. “We need to understand the problem before building a solution”.
  • The requirements demanded by customers becomes more and more complex each year. “Design is a pivotal activity”.
  • More people and organizations are relying on software and to a higher degree than ever before. “Software should exhibit high quality”.
  • Software projects can see long term growth in their user base and increased demands in their capabilities. “Software should be maintainable”.

Pressman began with the challenges we will face developing software to prevail upon us that software projects won’t succeed on accident. Software will need to be ENGINEERED.[1] He puts an emphasis on the verb engineering. Pressman uses the diagram below to highlight the importance of various aspects of software engineering.[1]

The foundation of software engineering, Pressman teaches, is a focus on quality. A focus on quality, dictates the processes, methods, and tools that we’ll use to reach that standard of quality. And what’s better, if our focus is building quality software, then over time we’ll iterate and develop better processes, methods, and tools than what we already have.

So why did the Black Hawk team’s version of software engineering look so different from my preconceived notions? Because all I saw were their processes, methods, and tools. And if I’m being totally honest, all I really saw were their tools. What I didn’t see was the massive part of the iceberg hidden underneath the surface of the water: their processes and definition of quality. If you start with a focus on quality, then everything else can be great software engineering.

References:

  1. “Software and Software Engineering.” Software Engineering: A Practitioner’s Approach, by Roger S. Pressman, 7th ed., McGraw Hill, 2010, pp. 12–16.
  2. “UH-60V Black Hawk Integrated Mission Equipment Package.” Northrop Grumman, www.northropgrumman.com/what-we-do/air/uh-60v-black-hawk-integrated-mission-equipment-package/.
  3. “SCADE Suite: Integrated Model-Based Design & Development Environment.” Ansys, www.ansys.com/products/embedded-software/ansys-scade-suite.
  4. “Airborne Software Certification Explained.” Open, www.open-do.org/about/software-certification-101/.

For All Our Lives

An excerpt from “The Old Man and the Sea” by Ernest Hemingway:

“Do you remember when [Dick Sisler] used to come to the terrace? I wanted to take him fishing but I was too timid to ask him. Then I asked you to ask him and you were too timid. I know. It was a great mistake. He might have gone with us. Then we would have that for all of our lives.’

I can’t count the times I let fear and timidity get the best of me. This hits all too close to heart.

This passage sprang to mind while writing an email to a friend. I did not need anything from him. I had only wanted to write to him and thank him for all that he gave me while working on a project together: hope, a new attitude, curiosity, and a stronger work ethic. I let the thought of writing to him linger for far too long…three months really. Only after finishing the email did I recognize what I could have lost had I not written to him.

While attempting to relive moments of my life through this message, all the missed opportunities were quick to surface. And it’s certainly a powerful lesson to learn in one’s youth, but focusing only on the missed opportunities doesn’t seem to do myself, or the message, justice.

I’m simply grateful that I get to have this conversation with myself each morning:

“Do you remember the days when we’d get to Chemistry lecture early and enter through the back hallway so we could get a seat in the front? There was always that girl I wanted to get to know, but I was too timid to say hello to her. Then I asked you to approach her and you did. I know. It was the greatest thing we ever did. She was amazing. And now, we have each other for all of our lives.’