The Reality of System Development
Starting from Zero
The most remarkable thing about this company was that you were completely left to figure everything out by yourself.
More precisely, there was nobody in the company who technically understood this work.
Since there was no one who knew, I had no one to ask questions to.
Project Background
This project was the company's first contracted development work, and it was a control system project.
Meanwhile, except for a few administrative staff and Team Leader T, all employees were dispatched workers specializing in accounting systems for banks and securities companies.
Management Structure
The development director was the president's younger brother, but he too specialized in accounting systems and knew nothing about control systems.
He seemed capable and was often dispatched elsewhere. As an engineer, he had significant disagreements with his brother, the president, about management.
Technical Environment
More troublesome was the fact that Team Leader T had no knowledge of the development environment - Unix, C language, and the proprietary UI system.
The UI portion and most of the UI-related data processing were entirely dumped on me, while he only handled the final data processing parts that didn't involve UI.
For technical matters, I could only rely on manuals and books.
For business matters, I could only ask questions to the client.
Life Before the Internet
There was no internet like today. Even LANs weren't common back then.
Can you imagine a time without mobile phones or email?
That's why people wrote "XYZ" on station message boards back then.
(City Hunter reference, for those who know)
You'd occasionally see people on the Yamanote Line with shoulder bag-like mobile phones.
Ah yes, the president had one of those too...
[Rest of the content remains the same...]
Ah yes, the president had one of those too...
Mysterious Meeting Members
One day, the development director told me to come to work in a suit the next day.
The next day, we headed to a meeting - the development director, Mr. T, myself, and six dispatched workers.
Wait, what?
These people were usually dispatched to major banks doing mainframe system maintenance.
They rarely came to the office and only had experience with COBOL for mainframes...
This whole situation seemed absurd.
Nevertheless, the development director led all eight of us into the client's building.
The contract structure for this work was explained as follows:
[Major Electronics Manufacturer] → [Electronics Manufacturer Subsidiary] → [Prime Contractor (SI Company)] → [Subcontractor (Staffing Company)] → [Sub-subcontractor (My Part-time Workplace)]
We were what's called a "third-tier subcontractor."
The meeting was held at the Electronics Manufacturer Subsidiary's office.
With sales representatives from the SI company and other subcontractors present, there were nearly 20 people.
The development director introduced all eight of us as the development team, and we all bowed.
"Pleased to work with you"
Though I said this, I still couldn't understand the situation at all.
Fictional Progress Charts
A month later, a few days before the next meeting, the development director suddenly told me:
"Make a progress chart for the next meeting."
What on earth was that?
I couldn't even picture the characters for it. I asked the development director.
"What's a progress chart?"
"It's a table with lines showing the progress status!"
"What does 'progress' mean?"
"It's how far along the work is!"
He sketched out a progress tracking table, with functions and personnel listed on the vertical axis and the timeline from November to March on the horizontal axis.
Then, although only Mr. T and I were actually working, the development director wrote in the names of everyone who had attended the previous meeting as responsible personnel.
| Month | Function | 88/11 | 12 | 89/1 | 2 | 3 |
|---|---|---|---|---|---|---|
| Saito | Function A | -- | --> | |||
| A | Function B | -- | --> | |||
| B | Function C | -- | --> | |||
| C | Function D | -- | --> | |||
| D | Function E | -- | --> | |||
| E | Function F | -- | --> | |||
| F | Function G | -- | --> | |||
| Mr. T | Final Data Processing | -- | -- | -- | -- | --> |
Why?
Still confused, I created the document by hand using a ruler and made copies.
Of course, I included progress for all eight people.
I was sent to the meeting alone. I answered all the detailed questions from the client.
"Wow, it's impressive that someone so young can track everyone's progress in such detail."
The client was impressed. Of course - I was doing all the development myself.
"But this Mr. C seems to be behind schedule."
"Well, that's because of this and that..."
I desperately made excuses.
"No, no, I'm not blaming you, Saito. I'm just pointing out that Mr. C is behind schedule."
That's actually me.
At this point, I finally understood the man-month system.
The Truth About Man-Month Business
This work was calculated in man-months.
This meant the project was estimated at 40 man-months (8 people × 5 months).
Though I never saw the estimate, I later heard from the prime contractor's representative that it was contracted for approximately $260,000.
The company's accounting department also told me after I left that it was about $208,000.
By the way, there was no consumption tax back then.
However, in reality, only Mr. T and I (paid $13 per hour) were actually working.
I was effectively doing 35 man-months of work. No, even more than that.
The Burden Placed on a Novice
The job included creating specifications and handling deliveries, but Mr. T didn't do any of this.
The company really taught me nothing.
Since Mr. T was even less comfortable with social interactions than I was, all client interactions were pushed onto me.
With zero social skills or business manners, I was constantly scolded by clients.
The company had strictly ordered me: "Never reveal that you're a student!"
"How can you not know something this basic?"
Yes, I'm sorry. I really am clueless about the business world.
I wanted to ask them how many years of experience they thought I had.
I had never written test specifications before, and no one taught me how, so I wrote them myself.
All documentation had to be handwritten in those days. I created procedure documents for each test item and wrote in the results.
There were hundreds of pages. The number of required test cases was based on the volume of code.
For integration testing, I believe it was 40 items per 1,000 lines.
I wrote 15,000 lines of code in three months, so I must have written 600 pages of test procedures.
Later, I found my test specifications carelessly scattered at the client's office.
I casually picked them up to look.
After a few pages marked with red pencil corrections, someone had written "Idiot" and "Die."
I felt tears welling up in my eyes.
I had drafted these specifications with no real understanding of what I was doing.
Without doubt, to the experienced client employees, the content was worse than garbage.
I wondered who was really to blame...
Nevertheless, the project was eventually completed successfully.
Conclusion
With the profits from this project, the president treated himself to a Porsche.
(End)
Top comments (0)