The post has been translated automatically. Original language: Russian
In the early 2000s, I continued to read Joel on Software. Joel Spolsky had already worked at Microsoft, created Fog Creek Software, and was very good at explaining things that developers felt in practice, but could not always formulate.
On February 13, 2002, he published an article The Iceberg Secret, Revealed. Her idea was simple: the customer sees only a small part of the software project. The interface, buttons, and beautiful screens are immediately visible, and much of the real engineering work is hidden beneath the surface.
Today, this idea seems obvious. But one day I saw her literally in person.
When one team has already "done" everything
I had a project where the customer decided to play it safe and hired a second development team at the same time.
At that moment, I was struggling with one function. Moreover, from the outside it might seem that the work is almost standing still: no new beautiful windows, buttons and spectacular demonstrations.
But the function was the cornerstone for the whole system. It implemented the calculation method itself, for which, in fact, the program was created.
While I was figuring out the calculation, the second team was moving much more effectively. They had already drawn the interface, made screens, and could show the customer a tangible result.
At the demonstration, their situation probably looked much better than mine.
They already had a program.
I still had the calculation.
The tip of the iceberg
That's what Joel called the iceberg's secret.
The user sees the upper part of the system. If the interface is ready, the program starts and you can navigate through the screens, there is a natural feeling that most of the work has already been done.
But in software, the amount of visible output is very poorly related to the amount of work done.
You can make a beautiful shell around an unsolved problem in a week. Or you can spend months working on an algorithm that will then look like a single "Calculate" button on the screen.
For the user, this button occupies several square centimeters.
For a developer, it may contain the most difficult part of the entire project.
In my case, the calculation decided everything.
The second team built a Delphi system for Windows. Moreover, as far as I have seen, they largely copied the approach from my previous work.
I went the other way: C++, Linux and Qt of the second version.
But in the end, it wasn't the programming language or even the interface that was decisive. It was necessary to implement the calculation method itself correctly.
My calculation turned out to be correct.
And that's why I ended up fulfilling the contract.
The work of the second team did not suit the customer, despite the fact that at some point they looked much closer to the finish line.
It was a very clear lesson.: the readiness of the interface does not mean anything about the readiness of the system.
The most expensive work is often almost invisible
There is a strange feature in programming. Some of the most difficult tasks produce very little visual result.
A developer can spend several weeks dealing with math, synchronization, performance, or a rare error. After that, the user will only see that the program now outputs one number correctly or has stopped falling sometimes.
On the other hand, a good designer or interface developer can completely change the visual impression of a product in a few days.
This does not mean that the interface is unimportant. It is critically important for many products. But visual completeness and engineering completeness are different things.
And it is very easy for the customer to confuse them.
Why do prototypes cheat
The prototype is especially convincing precisely because it can be shown.
The person clicks a button, the next window opens, and a graph appears, which means the system is working.
And the issues that are not yet visible remain behind the scenes. What happens to the incorrect data? Does the result match the methodology? What will happen under heavy load? How can I restore the system after an error? What will happen to the data in a year?
As long as the product does not face actual exploitation, many of these things can be overlooked.
That is why the phrase "everything is already working for us, there is a little bit left to finish" in development sometimes means that there is still half of the project ahead.
In 2026, the iceberg became even more dangerous
AI has dramatically reduced the cost of creating the tip of the iceberg.
Today, you can get a good interface, database, authorization, multiple screens, and a working demo in a few hours. To an outsider, it may look like an almost finished product.
Previously, at least the speed of development itself gave a little bit of the real amount of work. If a large system appeared in two days, an experienced person understood that he had a prototype in front of him.
Now such a visual result can really be done in two days.
Therefore, it becomes even more important to distinguish between a prototype and a ready-made system.
AI also likes the visible part.
AI makes it especially easy to do things that are well demonstrated: interfaces, forms, standard operations, integrations, and common application code.
But if the value of a product lies in a complex methodology, unique algorithm, or specific domain knowledge, the most important thing may still be hidden.
AI is able to help write an implementation, but it doesn't negate the issue.: Do we understand the task correctly at all?
In my old project, it was possible to quickly create a beautiful interface. But if the calculation method was wrong, all that beauty didn't really matter.
The situation is exactly the same today.
How do I look at the project readiness now?
After such stories, I try not to evaluate the program by the number of screens.
It is much more important for me to understand which major risks have already been eliminated. If the product is built around a complex algorithm, it is advisable to first make sure that the algorithm works. If the main risk is performance, you need to check it. If integration with an external system is necessary, first prove that it is possible at all.
The interface can be done later. And sometimes it really can be done very quickly.
This does not mean that everything always needs to start with the most difficult part. But you need to understand where the real uncertainty of the project lies, and not confuse progress with the number of windows already drawn.
What's left of Joel's Iceberg
More than twenty years have passed since Joel's article, and the iceberg itself has not disappeared.
Only the speed ratio has changed. The visible part of the system can be created incredibly quickly today, so it creates an even stronger sense of readiness.
In my case, the two teams once showed this difference very clearly. While one was already demonstrating the interface, I was still figuring out a single function.
But it was this feature that ultimately decided the fate of the project.
That's why today, when they show me a beautiful prototype and tell me that the product is almost ready, the first thing I want to understand is not how many screens are already working.
I want to understand what is under the water.
В начале 2000-х я продолжал читать Joel on Software. Джоэл Спольски уже успел поработать в Microsoft, создать Fog Creek Software и очень хорошо умел объяснять вещи, которые разработчики чувствовали на практике, но не всегда могли сформулировать.
13 февраля 2002 года он опубликовал статью The Iceberg Secret, Revealed. Её идея была простой: заказчик видит только небольшую часть программного проекта. Интерфейс, кнопки и красивые экраны заметны сразу, а значительная часть настоящей инженерной работы скрыта под поверхностью.
Сегодня эта мысль кажется очевидной. Но однажды я увидел её буквально вживую.
Когда одна команда уже всё «сделала»
У меня был проект, где заказчик решил подстраховаться и параллельно нанял вторую команду разработчиков.
В тот момент я бился над одной функцией. Причём со стороны могло показаться, что работа почти стоит на месте: никаких новых красивых окон, кнопок и эффектных демонстраций.
Но функция была краеугольной для всей системы. В ней реализовывалась сама методика расчёта, ради которой, собственно, программа и создавалась.
Пока я разбирался с расчётом, вторая команда двигалась гораздо эффектнее. Они уже нарисовали интерфейс, сделали экраны и могли показывать заказчику вполне осязаемый результат.
На демонстрации, наверное, их положение выглядело намного лучше моего.
У них уже была программа.
У меня всё ещё был расчёт.
Верхушка айсберга
Именно это Джоэл и называл секретом айсберга.
Пользователь видит верхнюю часть системы. Если интерфейс готов, программа запускается и по экранам можно переходить, возникает естественное ощущение, что большая часть работы уже сделана.
Но в программном обеспечении объём видимого результата очень плохо связан с объёмом выполненной работы.
Можно за неделю сделать красивую оболочку вокруг ещё не решённой задачи. А можно месяцами работать над алгоритмом, который на экране потом будет выглядеть как одна кнопка «Рассчитать».
Для пользователя эта кнопка занимает несколько квадратных сантиметров.
Для разработчика за ней может находиться самая сложная часть всего проекта.
В моём случае всё решил расчёт
Вторая команда делала систему на Delphi под Windows. Более того, насколько я видел, они во многом копировали подход из моей предыдущей работы.
Я пошёл другим путём: C++, Linux и Qt второй версии.
Но в итоге решающим оказался не язык программирования и даже не интерфейс. Нужно было правильно реализовать саму методику расчёта.
Мой расчёт оказался правильным.
И именно поэтому в итоге контракт исполнял я.
Работа второй команды заказчику не подошла, несмотря на то что внешне они в какой-то момент выглядели значительно ближе к финишу.
Это был очень наглядный урок: готовность интерфейса ещё ничего не говорит о готовности системы.
Самая дорогая работа часто почти не видна
В программировании есть странная особенность. Некоторые из самых сложных задач дают очень маленький визуальный результат.
Разработчик может несколько недель разбираться с математикой, синхронизацией, производительностью или редкой ошибкой. После этого пользователь увидит лишь то, что программа теперь правильно выдаёт одно число или перестала иногда падать.
С другой стороны, хороший дизайнер или разработчик интерфейса за несколько дней способен полностью изменить визуальное впечатление от продукта.
Это не означает, что интерфейс неважен. Он критически важен для многих продуктов. Но визуальная завершённость и инженерная завершённость — разные вещи.
И заказчику очень легко их перепутать.
Почему прототипы обманывают
Прототип особенно убедителен именно потому, что его можно показать.
Человек нажимает кнопку, открывается следующее окно, появляется график — значит, система работает.
А вопросы, которые пока не видны, остаются за кадром. Что происходит с неправильными данными? Совпадает ли результат с методикой? Что будет при большой нагрузке? Как восстановить систему после ошибки? Что будет с данными через год?
Пока продукт не сталкивается с реальной эксплуатацией, многие из этих вещей можно не замечать.
Именно поэтому фраза «у нас уже всё работает, осталось немного доделать» в разработке иногда означает, что впереди ещё половина проекта.
В 2026 году айсберг стал ещё опаснее
ИИ резко удешевил создание верхушки айсберга.
Сегодня можно за несколько часов получить хороший интерфейс, базу данных, авторизацию, несколько экранов и рабочую демонстрацию. Для человека со стороны это может выглядеть как почти готовый продукт.
Раньше хотя бы сама скорость разработки немного выдавала реальный объём работы. Если за два дня появилась большая система, опытный человек понимал, что перед ним прототип.
Теперь такой визуальный результат действительно можно сделать за два дня.
Поэтому различать прототип и готовую систему становится ещё важнее.
ИИ тоже любит видимую часть
С помощью ИИ особенно легко делать то, что хорошо демонстрируется: интерфейсы, формы, типовые операции, интеграции и обычный прикладной код.
Но если ценность продукта находится в сложной методике, уникальном алгоритме или специфических знаниях предметной области, самое важное по-прежнему может быть скрыто.
ИИ способен помочь написать реализацию, но он не отменяет вопроса: правильно ли мы вообще понимаем задачу?
В моём старом проекте можно было быстро сделать красивый интерфейс. Но если методика расчёта неверна, вся эта красота не имела особого значения.
Сегодня ситуация точно такая же.
Как я теперь смотрю на готовность проекта
После таких историй я стараюсь не оценивать программу по количеству экранов.
Для меня гораздо важнее понять, какие основные риски уже сняты. Если продукт строится вокруг сложного алгоритма, сначала желательно убедиться, что алгоритм работает. Если главный риск — производительность, надо проверить её. Если интеграция с внешней системой — сначала доказать, что она вообще возможна.
Интерфейс можно сделать потом. А иногда его действительно можно сделать очень быстро.
Это не значит, что всё всегда нужно начинать с самой сложной части. Но нужно понимать, где находится настоящая неопределённость проекта, а не путать прогресс с количеством уже нарисованных окон.
Что осталось от айсберга Джоэла
Прошло больше двадцати лет после статьи Джоэла, а сам айсберг никуда не исчез.
Изменилось только соотношение скоростей. Видимую часть системы сегодня можно создавать невероятно быстро, поэтому она ещё сильнее создаёт ощущение готовности.
В моём случае когда-то две команды очень наглядно показали эту разницу. Пока одна уже демонстрировала интерфейс, я всё ещё разбирался с одной-единственной функцией.
Но именно эта функция в итоге решила судьбу проекта.
Поэтому сегодня, когда мне показывают красивый прототип и говорят, что продукт почти готов, я прежде всего хочу понять не то, сколько экранов уже работает.
Я хочу понять, что находится под водой.
Share
