Реклама партнера — Название партнёра
UNIT.City — місце, де люди працюють... КРАЩЕ! Обирай свій простір просто зараз 👉

When mainframes met personal computers: the wild 1991 that changed Ukrainian IT forever

The early 90s. One personal computer for the entire team, 16-hour workdays, hunger as the best motivator, and a technological revolution that not everyone noticed at first. It was in these wild conditions — between mainframe logic, FoxPro 1.01, the risk of going to jail, and programmers who had to go "to the market" — that a team was born, which out of chaos created a product and a company that outlasted everyone else.

Leave a comment
When mainframes met personal computers: the wild 1991 that changed Ukrainian IT forever

The early 90s. One personal computer for the entire team, 16-hour workdays, hunger as the best motivator, and a technological revolution that not everyone noticed at first. It was in these wild conditions — between mainframe logic, FoxPro 1.01, the risk of going to jail, and programmers who had to go "to the market" — that a team was born, which out of chaos created a product and a company that outlasted everyone else.

Volodymyr Mikhailov, co-founder of IT-Enterprise, talks about the revolutionary transition to PCs that cost two KamAZ trucks, the first RAD frameworks, the emergence of ERP architecture, and the birth of an IT company. What follows is his direct speech.

A few months after the start of the project at Vinnytsia Experimental Machine-Building Plant No. 45, in February 1991, the plant received the first 20 IBM PC 286 personal computers and an ARCNet network with a fantastic data transfer speed of 2.5 Mbit/s over coaxial cable.

The project manager from the Customer suggested that we change the technical platform of the project from IBM 370\ADABAS\Natural to a network of personal IBM PC 286 without changing the delivery dates and with all risks transferred to us (no prepayments, payment upon launch).

We didn't know any operating system, programming language, or database on the IBM PC. There were two months left before the first stage of the project was due. The desire to program network tasks on personal computers was such that, without hesitation, we agreed. Now I would consider it madness, but it was a chance to move forward together.

The customer gave us one personal computer, which cost as much as several KAMAZ trucks. Putting this treasure in the institute and leaving it overnight without security would be a real suicide, because at that time no one had yet abolished the article of the Criminal Code "Misappropriation of socialist property on an especially large scale." In order not to end up behind bars and to secure the working tool, a decision was made: Oleg Shcherbatenko took the computer to his home for a week, until room 417 in the 18th building of the KPI was put on remote security.

FoxPro 1.01: Love at first sight and 25 years of addiction

Choosing a programming system among Dbase IV, Clipper and FoxPro, we settled on FoxPro 1.01, which had a unique Rushmore optimization of database queries. In addition, FoxPro was not a simple programming language, but a RAD (Rapid Application Development) development system. This was both a lucky ticket and our curse, because FoxPro lasted for another 25 years.

I was forced to master a new operating system, a new programming language and a database in a week. Over the next month and a half, I had to develop modules for maintaining regulatory and reference information, technical preparation of production and connectors to mainframes on my own. At the end of April 1991, we handed over to the Customer a software product running on a network of personal computers, which immediately began to be used in production to fill the database with design and technological data. When running the control example, the Customer asked how many programmers we have? We modestly said that we have 15 programmers, and the Customer believed it.

By the end of 1991, we had developed a comprehensive production management system for a large machine-building plant, which consisted of modules for regulatory information, technical preparation of production, inter-shop production planning and accounting, intra-shop planning of assembly and mechanical-preparation production, warehouse accounting, technical and economic planning, etc.

In 1992, all of this was transferred to 24-hour productive industrial operation on a single centralized database and operated on a network that connected all remote production units, departments, and warehouses.

Our team then consisted of four people: me and Oleg Shcherbatenko and two students: Oleksandr Skrypin and Konstantin Shurek. The entire development project was carried out on ONE personal computer, which was used alternately for 16 hours a day.

Hunger is not an aunt and 3 more success factors

Why were we able to do this? First of all, motivation. I really wanted to “eat” in the literal sense of the word. Failure to complete a project stage on time automatically caused non-payment and the collapse of the family budget. Completing a project stage on time allowed us to earn 5 thousand each (payment for 4 years of work of a junior research fellow at KPI).

Secondly, the mindset of “I see the goal, I don’t see the obstacles” and understanding Fred Brooks’s statement: “The same program can be written in 3 hours, 3 days, 3 weeks, and 3 months. And it’s not a fact that a program written in 3 months will be better than a program written in 3 hours.” If the head of IBM’s programming department says this (and he is a 100% guru), then it is so, that is, programs should be written in 3 hours.

Thirdly, we already had experience in implementing two previous projects with similar functionality on ADABAS. That is, the project was ported to personal computers from mainframes. And this was the key point that distinguished us from most programmers of that time. When all the companies around us initially implemented single-user programs, we did not understand at all why we were doing such nonsense - in our heads we had centralized multi-user systems on mainframes with a single centralized relational database, and in our idea of ​​a personal computer it was an access terminal to a central database with local information processing. This, by the way, is the answer to the question of why everything was implemented in this way in IT-Enterprise and the database was always single and centralized.

And of course, the FoxPro 1.01 system itself, which for the first time on the market included the FoxView application for creating programs, full-fledged SQL and the FoxReport report designer. This would now be called a new Framework. The need to deliver the project on time forced us to understand this and immediately write in a new way, using a new programming style. By the way, the absolute majority of programmers who switched to personal computers in these years did not use it, but continued to write programs in the style of previous technologies, that is, "buy a tractor and attach a horse to the front to pull it all."

History is cyclical: why the IT revolution of the 90s is similar to the AI ​​revolution of the 2020s

The emergence of new frameworks allowed creating completely different software products, and the creation time became 10-15 times shorter. In previous technologies, 70% of development teams consisted of programmers who spent months writing “program points”, which in SQL were replaced by one SELECT statement and several UPDATE statements and were written in an hour, and spent months writing paper reports, which were also created in an hour using CrystalReport or FoxReport. In the early 90s, all these “programmers” were either forced to master new approaches or go to the market to trade. At that time, it was believed that programmers were no longer needed, because new programming systems “programmed themselves” for them.

Doesn't it remind you of anything? Something very similar to what is happening now, when the IT industry thinks that AI will write all the code for programmers. and they can all be reduced. And so? And no. It will be possible to reduce herds of Juns if we try to solve problems in the old way. But creating software products in a new style requires developers with a completely different qualification. That is, the software products themselves become different, are created using other frameworks, as happened at the time when the IT Enterprise was emerging.

The misunderstanding by many programmers of the simple idea that software products are becoming different gave rise to Frankenstein products in which complete copies of old systems were created in new programming languages ​​(there was a product in PL/1 and all of it was stupidly rewritten in FoxPro or Delphi without changing the architecture). And in addition to them, these unfortunate programmers tried to sell customers modules such as "Dialog Viewing of Reports on the Display" or the module "Mouse Operation on the Display".

It's funny to see this from the perspective of the 21st century. Why aren't you laughing now when old products are sold on the market and "new" modules for these "AI for solving something" products are sold separately, which look something like a separate "Mouse on the display" module?

The lack of understanding by customers in 1991 that new frameworks had appeared opened up fantastic prospects. We were contracting to create new products that, using the old technology, would have required 20 programmers, and we were developing them with two programmers using the new frameworks.

This is how the process of initial capital accumulation in IT teams began. Where did IT Enterprise come from, you ask? From this technological revolution in programming in the early 90s.

In the next series: what helped us defeat the IT "dinosaurs" in factories, why refrigerators and bed linen became money, and how barter chaos forced us to move from programming to the roles of business analysts and architects.

For those who missed it
Read the country's main IT news in our Telegram
Read the country's main IT news in our Telegram
On the topic
Read the country's main IT news in our Telegram
Also Read
«Наша думка може бути суб'єктивною для вас». В Insoft Global відмовилися давати фідбек Project Manager після співбесіди
«Наша думка може бути суб'єктивною для вас». В Insoft Global відмовилися давати фідбек Project Manager після співбесіди
«Наша думка може бути суб'єктивною для вас». В Insoft Global відмовилися давати фідбек Project Manager після співбесіди
«IT Generation схоже на «Гру в кальмара». В мережі з'явилися відгуки кандидатів, які пройшли перші етапи відбору державної програми
«IT Generation схоже на «Гру в кальмара». В мережі з'явилися відгуки кандидатів, які пройшли перші етапи відбору державної програми
«IT Generation схоже на «Гру в кальмара». В мережі з'явилися відгуки кандидатів, які пройшли перші етапи відбору державної програми
Зібрали для вас думки потенційних студентів IT-шкіл.
«Віктор жалкує про зроблене». В DataArt відповіли на матеріал щодо проросійського айтішника
«Віктор жалкує про зроблене». В DataArt відповіли на матеріал щодо проросійського айтішника
«Віктор жалкує про зроблене». В DataArt відповіли на матеріал щодо проросійського айтішника
1 comment
Професії у геймдеві. Хто такий левел-дизайнер і як ним стати?
Професії у геймдеві. Хто такий левел-дизайнер і як ним стати?
Професії у геймдеві. Хто такий левел-дизайнер і як ним стати?
Ми продовжуємо нашу рубрику, присвячену професіям у геймдеві. Тема нового матеріалу в ній — левел-дизайн. Його вважають підвидом геймдизайну, але все-таки практично кожна студія хоче окрему людину на позицію левел-дизайнера. Адже у цій спеціальності вистачає своїх нюансів та особливостей. Розібратися з ними всіма нам допоміг досвідчений левел-дизайнер зі студії Fractured Byte Дмитро Нестеренко. Також він веде свій блог Game Designer Notes про геймдизайн в цілому, в якому розбирає багато цікавих нюансів розробки ігор.
1 comment

Have important news to share? Message our Telegram bot

Key events and useful links in our Telegram channel

Discussion
No comments yet.