Navigating Incorrect Software Practices in the Early 1980s

Core Development Concepts
1

In 1980, I had a memorable encounter with a manager who naively tried to apply high-level programming principles to assembly language.

I was part of a company focused on creating industrial control systems, specifically coding in 8085 assembly for embedded devices. After my manager attended a seminar on “structured programming,” he became adamant about eliminating all GOTO statements from our codebase.

The issue was that assembly language relies heavily on jumps and branches. When I attempted to explain this to him, he issued me an ultimatum: remove every jump instruction within two weeks, or face consequences.

In response, I devised a clever solution. Instead of using direct JMP commands, I utilized:

; Instead of: JMP TARGET_ADDR
; I opted for:
LXI H, TARGET_ADDR  ; Load the target address into HL
SPHL               ; Transfer HL to the stack pointer  
RET                ; Return to the "new module"

; Plus, I included elaborate module headers
.TITLE "Data Management Module 2.1"
.SUBTTL "Enhanced Calculation Subsystem"

The program functioned just as it should, albeit with some added steps and detailed documentation. I embellished it with impressive titles and descriptions.

My manager was ecstatic! He genuinely believed I had revolutionized chaotic code into a structured design masterpiece. The system was released, and I moved on to new endeavors.

Fast forward three years, a new developer reached out, utterly confused by the code I had written. Upon sharing the story with him, he was in stitches. It turns out they had dismissed that manager ages ago.

Does anyone else have stories about dealing with management that lacked technical understanding?

2

Oh man, this brings back memories! Had a boss in '82 who wanted “user-friendly interfaces” for our PDP-11 control system. Guy thought we could just throw windows and menus on everything like a desktop app. I spent weeks building fake ASCII menus that did nothing but keep him happy while the real work happened in interrupt handlers underneath. Sometimes you just gotta give them the show they want!

3

This resonates with my experiences as well. During the late '70s, I was involved in developing microprocessor firmware and faced a similar situation. Our department head returned from a conference with a newfound obsession for modern software engineering practices, oblivious to the hardware limitations we faced. He struggled to understand the fundamental differences between assembly language and high-level programming. The refusal from management to acknowledge their lack of knowledge only exacerbated the challenges we encountered. Your workaround was indeed clever—providing what they believed they needed while maintaining code functionality. I also made it a point to document these kinds of adjustments, as it significantly helped future developers. Ultimately, it was disheartening to see so much time spent on unnecessary programming complexities instead of optimizing our systems. These situations taught me that sometimes, surviving the corporate environment involves navigating and creatively fulfilling unachievable expectations.

4

that’s hilarious! but didn’t you worry about maintainability? what happened when other devs had to debug that stack pointer trick? manager situations always create this weird tension - keep the boss happy vs. write sensible code for whoever comes next.