DEV Community

Cover image for The Dark Side of Japan's Early 1990s Software Development - Young Engineers as Disposable Resources
Taka Saito
Taka Saito

Posted on

The Dark Side of Japan's Early 1990s Software Development - Young Engineers as Disposable Resources

Recently, I've been hearing many young engineers say, "I only do design work, with no implementation experience." This highlights one of the major challenges facing today's IT industry in Japan.

Implementation is crucial.

In Japan, there has long been a tendency to equate "coders" with "programmers" while looking down on programming as a profession. There was even a time when programmers were expected to transition to System Engineers after just two years of experience due to low pay rates. While this was problematic in itself, I fortunately took a different path, having opportunities to work with brilliant programmers worldwide. I've even met true geniuses in the field.

I hope my experiences can help young engineers seeking to forge their path in implementation.

Memories of a Brutal Workplace

My career spans from consulting to operations - what we now call a full-cycle, full-stack engineer. I've experienced DevOps too. But of course, it all started with programming.

This was during the transition from the Showa to Heisei era, when TV commercials boldly asked, "Can you fight for 24 hours!?" It was a time that allowed me to experience numerous challenging situations.

How challenging?

Let me share one example from when the bubble economy burst. I still remember a shocking conversation with a staff member at a large corporation where I was temporarily assigned:

"Mr. Saito, I'm quitting today. Thank you for everything."

"Oh, really?"

"Yes, I wasn't feeling well, got some tests done, and the doctor warned me to quit immediately due to concerning internal organ readings..."

He was tall, fair-skinned, and what we'd now call "handsome" - I believe he was part Northern European. He continued:

"Actually, before this job, I was a host at a host club."

"Really?"

"But this job is tougher than being a host..."

What kind of system development environment could be tougher than working as a host, where you're expected to drink champagne like water?

Contract Relations and System Structure

Contract Flow

Contract Flow

System Overview

System Overview

Inadequate Development Environment

The development environment for this project was so poor that it made work extremely inefficient. Without enough PCs capable of compilation for everyone, we had to write code on old PCs, copy it to development laptops via floppy disks, and then compile and link (make). Terms like "build" and "deploy" didn't exist back then - well, maybe Turbo-C used "Build"... Either way, it was so bad that I brought my newly purchased EPSON PC-486 (desktop) and color monitor (CRT) from home to the workplace.

Bizarre Development Environment

The most perplexing aspect was designing the system while debugging it. This was before the word "agile" even existed.

System Development Model

Engineers would create rough specifications, immediately program them, and jump straight into integration testing. Naturally, errors were rampant. Reviews? Non-existent. Who even understood the complete specifications?

"So-and-so quickly put together a demo version, showed it to the client, who said 'This is fine! Just tweak it a bit and you can release it soon!' And that's how development started haphazardly. Then they ran short on people, so we were brought in, but we'd never written C before, so we're reading introductory books while trying to write programs, and we just can't do it..."

What kind of situation is this?

Bizarre Team Composition and Development Language

While this system was being developed using MS-C on MS-DOS, most programmers only knew COBOL. Why was such a development team assembled? The shocking reason: the prime contractor's president declared, "C and COBOL start with the same letter, so they must be similar," and assigned young COBOL programmers to the project.

C Language and COBOL

C language, which can directly manipulate memory, and COBOL, which specializes in business logic, are fundamentally different.

C Language

A low-level language that enables efficient programming through direct memory manipulation using pointers and structures. Historically, many struggled with understanding pointers, making it a "cheat" language mastered only by those who could overcome the pointer barrier.

// Memory manipulation example
int *ptr = malloc(sizeof(int));
*ptr = 42;
printf("Memory at %p contains %d\n", ptr, *ptr);
free(ptr);
Enter fullscreen mode Exit fullscreen mode

COBOL

A business-oriented language specialized for processing large volumes of records with English-like syntax. I remember a colleague who boasted, "You only need to know 'MOVE', 'GOTO', and 'PERFORM' to code in COBOL!"

IDENTIFICATION DIVISION.
PROGRAM-ID. SALES-REPORT.
WORKING-STORAGE SECTION.
01 TOTAL-SALES PIC 9(8)V99.
PROCEDURE DIVISION.
    PERFORM UNTIL END-OF-FILE
       READ SALES-FILE
       ADD SALE-AMOUNT TO TOTAL-SALES
    END-PERFORM.
Enter fullscreen mode Exit fullscreen mode

How Did the Crisis End?

We managed to create massive amounts of code and meet the release deadline. However, the system frequently froze at the service counter. Hiding behind a pillar, I watched reception staff angrily calling the development room, silently apologizing in my heart.

Nevertheless, we managed to fix the bugs and achieve stable operation within a week. Midway through, my contract was changed from the prime contractor to direct with the manufacturer, but I didn't want to continue with this project, so I left at a convenient stopping point. The reason? Simply because I was young, the manufacturer's payment regulations meant I could only receive half the estimated amount at most. However, having a direct contract with the manufacturer was good for my reputation, and I didn't want to leave before achieving stable operation, so I stayed until then. While equal pay for equal work is advocated today, such concepts didn't exist back then.

Salary Situation Symbolizing Japan's IT Industry Decline

At the time, my hourly rate was 8,500 yen (about $73 at 1990 exchange rates). In contrast, in 2024, similar work typically pays around 5,000 yen ($33) per hour.

Why have wages decreased despite over 30 years of technological advancement and inflation? This dramatic wage difference symbolizes the decline of Japan's IT industry. In markets like the United States, experienced engineers can earn over $200 per hour. Meanwhile, Japan continues to be eroded by what's called the "Lost 30 Years" of deflation, affecting wages and economic vitality.

The First AI Boom and Prolog

By the way, are you familiar with Prolog? It was a celebrated language during the first AI boom of the 1980s. A declarative language that builds programs by defining rules of logic and inference, it was considered proficient at AI-like processing for drawing conclusions.

% Define family relations and deduce grandparents
parent(john, mary).
parent(mary, bob).
grandparent(X, Z) :- parent(X, Y), parent(Y, Z).
% Can automatically answer "john is bob's grandparent?"
Enter fullscreen mode Exit fullscreen mode

Characterized by the ":-" symbol for defining rules, as a novice, I couldn't grasp Prolog's potential and couldn't imagine it being practical. However, the concept of "describing rules" would prove useful in my later work.

Muscle-Headed Management

In autumn 1988, at a certain company's new building unveiling ceremony, I was shocked by the president's (or chairman's) smug speech:

"This is the era of Prolog! Programs can be written in one-tenth the code compared to COBOL! We will develop all our systems in Prolog!"

Switching everything to Prolog just because it requires one-tenth the coding... What?

Vendors Who Grew by Consuming Engineers

  • Switch everything to Prolog because it's 10 times more productive than COBOL
  • C and COBOL start with the same letter, so they must be similar

Such simplistic thinking was incredibly muscle-headed, short-sighted, and disregarding of human rights... Programmers and SEs are human beings, not commodities or disposable tools.

Back then, and even now, software vendor management is dominated by those with sales backgrounds. These vendors are essentially dispatch companies or human trafficking businesses, willing to do anything for sales. While this might be the essence of sales, the consequences invariably fall on the development team, and I believe this has come full circle to affect today's Japan.

I spent just a month and a half at that chaotic workplace. During that time, half the development staff quit like falling dominoes. Some suffered physical breakdowns, others mental illness. I still remember leaving the site before the building locked down, looking at the lights of the Fukutoshin Line construction site from the taxi, heading home with indescribable feelings. How many companies grew large by crushing and consuming the bodies and minds of countless young people?

Those who would now be called "corporate slaves" were then called "corporate warriors." Because toxic work environments were the norm, there wasn't even a term for "black companies" (exploitative employers). Those who survived were considered excellent human resources. This is the mindset of today's 50+ generation. I was once one of them too.

As represented by BIG Motor, haven't those stuck with their Heisei-era success experiences continued their Showa-era methods even in the Reiwa era?

Couldn't this be considered one factor that has effectively reduced the working population and shaped today's Japan?

The president or chairman of a certain company proudly declared on stage:

"We hire 400 people every year!"

But their total employee count hadn't changed in 10 years. A senior colleague muttered under his breath.

Top comments (0)