00:00:05 Введение в тему поддерживаемости программного обеспечения цепочки поставок.
00:01:22 Объяснение, как программное обеспечение может ухудшаться со временем на примере Microsoft.
00:03:01 Обсуждение различий в поддерживаемости продуктов Microsoft и другого программного обеспечения.
00:04:16 Объяснение, почему программное обеспечение должно меняться со временем из-за изменений в вычислительном оборудовании и вопросов безопасности.
00:07:50 Обсуждение перспективы, с которой следует рассматривать поддерживаемость, и проблемы рассмотрения её с точки зрения выживания поставщика.
00:09:08 Совместимость Microsoft с более чем миллионом принтеров как пример масштабов задачи.
00:10:07 Как дизайн программного обеспечения влияет на его поддерживаемость и необходимость создания ПО с высокой поддерживаемостью.
00:11:07 Важность анализа стимулов поставщиков для обеспечения поддерживаемости программного обеспечения.
00:13:03 Поддерживаемость — это вопрос дизайна, и сохранение технологической массы является ключевым для получения поддерживаемого продукта.
00:16:00 Обсуждение важности поддерживаемости программного обеспечения.
00:17:00 Стимулы поставщиков для обеспечения поддерживаемости программного обеспечения.
00:19:00 Как определить поддерживаемое программное обеспечение.
00:21:02 Симптомы непригодного для поддержки программного обеспечения.
00:23:13 Заключительные мысли о важности поддерживаемости программного обеспечения.
Резюме
В интервью Kieran Chandler и Joannes Vermorel обсуждают важность поддерживаемости программного обеспечения, особенно в программном обеспечении для цепочки поставок. Vermorel утверждает, что поддерживаемость — прежде всего вопрос дизайна, который часто упускается из виду компаниями, сосредоточенными исключительно на выживании поставщика. Он отмечает, что программное обеспечение со временем становится непригодным для поддержки из-за изменений в технологиях и энтропии, и подчеркивает важность совместимости, безопасности и простоты в дизайне ПО. Vermorel также предостерегает от использования эффектных пользовательских интерфейсов и предлагает тщательно ставить под сомнение планы разработчиков относительно поддерживаемости для обеспечения долгосрочной жизнеспособности.
Расширенное резюме
В этом интервью Kieran Chandler и Joannes Vermorel обсуждают проблемы поддержки программного обеспечения для цепочки поставок и то, как хороший дизайн может повлиять на его долговечность. Vermorel объясняет, что хотя программное обеспечение не изнашивается как материальные объекты, оно распадается со временем из-за энтропии и изменений в технологическом ландшафте. Компании, такие как Microsoft, добились успеха благодаря сильной приверженности долгосрочному существованию своих продуктов, что позволяет сегодня открывать и использовать старые документы.
Vermorel отмечает, что способность Microsoft обеспечивать долговечность своего программного обеспечения обусловлена их огромными инвестициями в обслуживание и вниманием к совместимости. Он сравнивает это с Linux, который, хотя и более стройный и логично организованный, не предлагает того же уровня обратной совместимости. Vermorel признает, что программное обеспечение для цепочки поставок еще более сложно из-за его распределенной природы и множества движущихся частей.
Поддержка программного обеспечения для цепочки поставок осложняется тем, что вычислительное оборудование постоянно развивается. Хотя виртуализация может помочь смягчить некоторые проблемы, это не идеальное решение. Кроме того, способ взаимодействия пользователей с программным обеспечением постоянно меняется, например, с увеличением распространенности сенсорных экранов и дисплеев с высоким разрешением. Старое ПО может не быть адаптировано для этих современных систем, что делает его менее интуитивным и потенциально небезопасным.
Vermorel утверждает, что поддерживаемость программного обеспечения часто упускается из виду и неправильно понимается. Типичная забота — будет ли поставщик существовать в будущем, но он считает, что это слабое основание для подхода к проблеме. Он указывает, что наличие существующего поставщика — это бонус, но не гарантия поддерживаемости. На самом деле, у некоторых поставщиков есть извращенный стимул создавать продукты, непригодные для поддержки, чтобы продавать новые версии.
Интервьюируемый подчеркивает, что проблему поддерживаемости следует рассматривать под другим углом. Он объясняет, что сложное программное обеспечение, например, корпоративные системы для цепочки поставок, содержит миллионы движущихся частей и над ним одновременно работают множество компаний. Эти системы постоянно подвергаются обновлениям и изменениям, чтобы оставаться совместимыми с различным оборудованием и операционными системами. Обеспечение совместимости становится огромной задачей, как иллюстрирует пример совместимости Microsoft с более чем миллионом принтеров.
Он утверждает, что по умолчанию программное обеспечение не является поддерживаемым, если оно специально не спроектировано для этого. Он также подчеркивает, что внимание должно быть сосредоточено не только на выживании отдельного поставщика, но и на всей экосистеме компаний, участвующих в цепочке поставок. Vermorel считает, что поддерживаемость — прежде всего вопрос дизайна, особенно в сохранении технологической массы.
Чтобы завоевать клиентов с помощью демо-версий, компании часто используют новейшие и самые передовые технологии для визуализации данных, пользовательского опыта и аналитики в реальном времени. Это создает эффект “вау”, который может быть аргументом в продажах. Однако Vermorel бросает вызов такому подходу, приводя в пример устаревшие ERP экраны, напоминающие текстовые терминалы начала 80-х годов. Несмотря на их внешний вид, эти экраны невероятно быстрые, отзывчивые и имеют минимальные зависимости, что делает их высокоподдерживаемыми и эффективными.
Vermorel подчеркивает, что не каждый слой программного обеспечения нуждается в инновациях, так как важнее обеспечить стабильность в таких областях, как управление календарем или хранение паролей. Он также отмечает, что инженерное программное обеспечение имеет богатую историю, из которой можно извлечь уроки, и поддерживаемость должна быть приоритетом. Однако клиенты и потенциальные заказчики часто упускают этот аспект, сосредотачиваясь больше на том, будет ли компания существовать в будущем, чем на поддерживаемости ее ПО.
Чтобы определить, является ли программное обеспечение поддерживаемым, Vermorel предлагает обратить внимание на стимулы, предлагаемые поставщиком. Например, поставщик, взимающий большие сборы за внедрение и сосредотачивающий доходы в начале проекта, может иметь стимул повторять эти сборы как можно чаще. В свою очередь, Lokad взимает ежемесячную плату без обязательств, что гарантирует, что компания будет иметь заинтересованность в результате и делает поддерживаемость приоритетом.
Vermorel также подчеркивает важность решений типа Software as a Service (SaaS), поскольку они гарантируют, что поставщик несет ответственность за обслуживание собственного программного обеспечения. Он предупреждает о технологической сложности, когда компании хвастаются многочисленными передовыми компонентами, которые могут стать кошмаром в обслуживании из-за их индивидуальных жизненных циклов. Вместо этого он предлагает, чтобы простое, поддерживаемое решение было приоритетом для специалистов по цепочке поставок.
Vermorel объясняет, что, несмотря на инвестиции компаний в системы цепочки поставок, они со временем часто становятся непригодными для использования из-за различных сбоев и проблем, которые возникают. С увеличением числа сбоев программное обеспечение становится труднее обслуживать и эксплуатировать. В итоге пользователи отказываются от функциональности системы и возвращаются к использованию таблиц Microsoft Excel в качестве обходного решения.
Он сообщает, что такая ситуация распространена в отрасли и отражает симптомы решения, которое стало полностью непригодным для поддержки. Vermorel предупреждает, что эффектные пользовательские интерфейсы не обязательно гарантируют хорошо функционирующий продукт и могут даже скрывать потенциальные проблемы с поддерживаемостью. С другой стороны, устаревшие пользовательские интерфейсы также могут служить тревожным сигналом, указывающим на отсутствие обслуживания и обновлений со стороны поставщика.
Чтобы избежать ловушки непригодного для поддержки программного обеспечения, Vermorel советует компаниям тщательно ставить под сомнение планы разработчиков относительно поддерживаемости и разбираться в ключевых дизайнерских решениях, которые способствуют долгосрочной жизнеспособности ПО. Он подчеркивает, что без тщательного учета поддерживаемости программное обеспечение в отрасли по умолчанию оказывается непригодным для поддержки.
Vermorel заключает, отмечая сходство между программным обеспечением для цепочки поставок и системами высокочастотной торговли в финансах, указывая, что оба часто используют текстовые пользовательские интерфейсы. Хотя такие интерфейсы могут выглядеть устаревшими, они эффективны и легко поддерживаются благодаря минимальным зависимостям и оптимизированному дизайну.
Полная расшифровка
Kieran Chandler: Эй, когда инвестируешь в программное обеспечение для цепочки поставок, ожидается, что оно прослужит компании десятилетиями, а не просто несколько лет. Однако с точки зрения поставщиков, быстро меняющийся технологический ландшафт означает, что его поддержка — задача не из легких. Таким образом, сегодня мы обсудим поддерживаемость и почему она вызывает такие трудности, а также поймем, как на нее может влиять хороший дизайн. Это интересная тема, и поддерживаемость — это то, с чем обычно не ассоциируют программное обеспечение. Программное обеспечение на самом деле не разрушается. Так в чем же суть?
Joannes Vermorel: На самом деле, программное обеспечение действительно разлагается. Да, это не механический износ, когда после использования происходит стирание и износ, и вещи становятся физически хрупкими до такой степени, что ломаются. Программное обеспечение — это не то же самое, но оно действительно распадается со временем. Это может показаться весьма удивительным, потому что некоторые из крупнейших и самых успешных компаний по разработке ПО, скажем, Microsoft, были невероятно успешными именно благодаря безумной приверженности долговременному существованию своих продуктов. Это буквально свидетельство успеха Microsoft, что в наше время можно открыть документ Microsoft Word, отредактированный в 1995 году, и до сих пор его распечатать. Это невероятно, но также то, что многие не осознают: Microsoft была достаточно уникальна в этом отношении, обладая этим мышлением долговременной приверженности своим продуктам. Если попытаться использовать решения любого их конкурента — а в наши дни люди даже не помнят, что у Microsoft Word и Excel было много конкурентов — ничего из этого не сработало бы.
Итак, давайте признаем, что программное обеспечение разлагается, и в основном оно разлагается из-за энтропии, из-за того, что ландшафт постоянно меняется. Оборудование меняется, и программное обеспечение — это очень составной продукт. В своей основе, чтобы что-либо запустить, обычно требуется задействовать десятки компонентов, поставляемых десятками компаний, и эти компоненты естественным образом не поддерживаются на должном уровне со временем. Когда что-то меняется, нет явной причины, по которой все остальные компоненты останутся полностью совместимыми и правильно интегрированными с изменившейся частью.
Kieran Chandler: Да, я имею в виду, что технологический ландшафт действительно меняется и меняется очень быстро. Так что же именно сделала Microsoft правильно? Почему им удалось повлиять на долговечность своего программного обеспечения?
Joannes Vermorel: В основе своей, они действительно заботились об этом и делали безумные инвестиции в эту сферу. Многие жалуются, что Microsoft Windows слишком раздут, что в нем так много всего, а если взять операционную систему Linux, то она гораздо стройнее, лучше организована и в целом более логична. Это правда, абсолютно правда. Но попробуйте запустить программу, написанную для Linux 25 лет назад; она не запустится. Игры, которые я покупал в подростковом возрасте в 90-х для Windows 95, до сих пор работают. Так что, я считаю, это наглядно демонстрирует суть.
Kieran Chandler: Можно делать вещи правильно с, я бы сказал, безумной приверженностью. И если вы прочитаете блоги Microsoft о том, что они делают для обеспечения поддерживаемости, можно сказать, что они идут на безумные меры, буквально. Но для программного обеспечения цепочки поставок вы не можете ожидать такого же уровня приверженности, просто потому, что рынок не так велик, и у вас просто нет компаний, которые бы шли такими обширными путями для этого. Плюс, у вас есть еще одна проблема: программное обеспечение для цепочки поставок также очень, очень сложное, потому что оно, как правило, распределенное, и в нем много, много движущихся частей. Так что это делает поддерживаемость еще более сложной. И теперь вопрос: почему вообще происходят какие-либо изменения, и почему нельзя просто заморозить программное обеспечение и пользоваться им вечно?
Joannes Vermorel: Ответ таков: во-первых, само вычислительное оборудование меняется, так что нельзя сказать, что эта вещь будет работать вечно. То есть, да, теперь можно использовать виртуализацию, чтобы смягчить большинство этих проблем, хотя виртуализация часто не является совершенно идеальной эмуляцией оборудования, которым вы пользовались раньше, так что она может помочь. Но помимо оборудования для вычислений, есть ещё то, что, например, способ потребления экранов изменился. Сейчас на экранах гораздо больше пикселей, они могут быть сенсорными, и есть много вещей, которые ведут себя не так, как старые системы. Иногда даже бывают странные системы, где исчезают клавиши на клавиатуре. Так что, если программное обеспечение было разработано для определенной клавиши, это могло быть очевидно в то время, но теперь, когда клавиши нет или раскладка клавиатуры изменилась, это становится гораздо менее интуитивным.
И затем, это лишь одна часть проблемы, которая развивается относительно медленно, а потом ещё и все вопросы безопасности. Большинство исторически созданного программного обеспечения совершенно не было рассчитано на современные угрозы, с которыми мы сталкиваемся сегодня. Это создаёт огромное давление, требующее, по сути, изменить кучу вещей во многих программных компонентах.
Kieran Chandler: То есть, люди всегда хотят использовать новейшие технологии в своих рабочих местах. Скажете ли вы, что это более доминирующая проблема или это больше связано с безопасностью и тем, что использовать их было бы небезопасно?
Joannes Vermorel: Сначала, поддерживаемость — это такая проблема, о которой менеджеры по цепочке поставок в основном не задумываются, а когда задумываются, они рассматривают её под углом, который, как я считаю, чрезвычайно слаб, а именно: останется ли поставщик на плаву или нет. И мое утверждение таково: поддерживаемость ни при каких условиях не зависит от выживания поставщика. Да, наличие поставщика, который все еще существует, можно считать плюсом, но этот плюс не так уж велик, потому что, давайте посмотрим правде в глаза, многие поставщики имеют колоссальный извращенный стимул создавать что-то абсолютно непригодное для поддержки. Как еще они смогут продать следующую версию? Если вернуться к тому, почему я обычно говорю, что эта проблема даже отсутствует, то дело в том, что вы не рассматриваете ситуацию под правильным углом.
Kieran Chandler: Нужно представить себе, знаете ли, сложный программный продукт, например, корпоративную систему управления цепочками поставок. Представьте систему, в которой буквально миллионы движущихся частей, и десятки компаний одновременно вносят изменения в те или иные компоненты по самым разным причинам. Иногда необходимо обеспечить совместимость с новым оборудованием, что может случайно создать несовместимость с каким-то устаревшим оборудованием. Возможно, требуется поддержка новой операционной системы, ведь, например, Linux постоянно меняется, Windows тоже постоянно обновляется, и вы, по сути, хотите быть совместимыми с последними версиями. Но, внедряя поддержку новейшей системы, вы можете случайно создать несовместимость с устаревшей.
Kieran Chandler: Чтобы дать вам представление о масштабах задачи, я читал в публикации Microsoft, что в какой-то момент Microsoft обеспечивала совместимость с более чем миллионом принтеров. Подумайте сами: миллион принтеров с различными драйверами, наборами команд, разным оборудованием и так далее. Сколько инженерных усилий требуется, чтобы обеспечить совместимость с миллионом устройств. Это почти безумие. И потом всегда находятся люди, говорящие: “Ах, Windows — это отстой. Я только что подключил мой 17-летний принтер, Epson 7.1.6 point B, словацкое издание, и угадайте, Microsoft не на 100% совместима с этим устройством, которое, очевидно, является эталоном.”
Joannes Vermorel: Но, шутки в сторону, у вас есть это огромное программное обеспечение в области цепочки поставок с множеством движущихся частей. База данных, на которую вы опираетесь, постоянно обновляется, сетевые протоколы, которые вы используете, постоянно совершенствуются, а веб-сервер, на котором вы работаете, тоже постоянно обновляется. У вас так много движущихся элементов. И по умолчанию, если вы специально не разработали ваше ПО так, чтобы оно было высокоподдерживаемым, оно таковым не станет. Суть цепочки поставок в том, что это больше игра в долгую. Мы должны думать не только о том, останется ли поставщик на плаву, но и о всех тех людях, с которыми поставщик взаимодействует. Итак, насколько можно быть уверенным в том, что эти другие компании будут здесь и в будущем? Опять же, факт присутствия компаний меня мало волнует. Это не правильный способ мышления. Если у вас есть поставщики, которые остаются, но у которых есть яркий стимул делать продукт непригодным для поддержки, чтобы продавать больше, достигли ли вы на самом деле прогресса в поддерживаемости или наоборот двигаетесь в обратном направлении? Вам нужно анализировать ситуацию, исходя из стимулов, которыми руководствуются люди. Еще что: я считаю, что поддерживаемость в основном определяется дизайном. Но о каком именно дизайне идет речь? И здесь, по моему мнению, все сводится к сохранению технологической массы.
Kieran Chandler: Видите ли, если вы хотите, чтобы ваш продукт демонстрировал действительно крутые демонстрации, что вам нужно? Вам нужна самая современная библиотека визуализации данных, самая современная UX-библиотека. Если вы хотите иметь эффектную аналитику в реальном времени, вам нужна новейшая подсистема для этого и так далее. Ваш стимул завоевывать клиентов через демо — это произвести эффект вау. Например, многие мои клиенты говорили, что их экраны в ERP выглядят как текстовые терминалы, просто черно-белый чистый текст. Они говорили: “О, нам действительно нужно что-то с этим делать.”
Joannes Vermorel: Я оспариваю это, потому что, когда я смотрю на эти терминалы, которые выглядят так, словно мы вернулись в начало 80-х или конец 70-х, я вижу, что люди, использующие их, невероятно быстры и отзывчивы. Экран крайне минималистичен, содержит всего несколько команд, которые нужно знать наизусть, и это все. Нет никаких отвлекающих элементов; все предельно утилитарно. Люди достигают с их помощью невероятной производительности. Да, они выглядят невыглядно, но они крайне поддерживаемы, ведь у них буквально нет никаких зависимостей и уж точно нет зависимости от веб-браузеров, которые постоянно меняются.
Так что, если вы взглянете и на самую древнюю часть цепочки поставок, и на самую передовую часть высокочастотной торговли в финансах, то увидите, что пользовательские интерфейсы схожи. Если вы посмотрите на тех количественных трейдеров, использующих ультрасовременные системы, их интерфейс снова выглядит как текстовый терминал. Это довольно странно: эти люди находятся на пике технологий, а их интерфейс выглядит совершенно устаревшим. Это противоположно тому, что обычно можно ожидать от голливудских интерфейсов.
Kieran Chandler: Это кажется довольно раздражающим, ведь все хотят использовать самые современные технологии. Так вы утверждаете, что наличие высокоподдерживаемого продукта в конечном итоге означает, что он не может быть на передовой инноваций?
Joannes Vermorel: Если вы стремитесь к инновациям с точки зрения поддерживаемости, почему бы и нет? Я не говорю, что мы не достигли прогресса в этой области — мы достигли. Просто это не вызывает эффекта вау. Когда у вас налажены очень четкие стратегии версионирования и компоненты, которые вы выбираете, имеют интересные философии, например, гибкость или ориентацию на поддерживаемость, это замечательно.
Мы используем некоторые компоненты с открытым исходным кодом, созданные именно с такой философией. Говорят, что существует манифест: эту проблему изучали последние 20 лет, и мы сошлись на том, что, по нашему мнению, является наилучшим компромиссом в плане дизайна. Теперь всё, что мы будем делать с этим компонентом — это производить должное обслуживание, чтобы с точки зрения безопасности не возникло серьезных проблем.
Kieran Chandler: Что касается совместимости, никаких случайных проблем не возникает, и мы не будем постоянно заново изобретать себя. Итак, вы говорите, что это разочаровывающе, что это противоположно инновациям. Но все же, нужно ли внедрять инновации на каждом уровне вашего программного обеспечения? Вы собираетесь постоянно переосмысливать, как работать с календарем или хранить пароли, например, если не случится криптографическая атака, требующая обновления? То есть, вам нужно выбирать то, где уже есть стабильность.
Joannes Vermorel: Инженерия программного обеспечения — не новая дисциплина. За плечами у нас около 50 лет истории, из которой можно почерпнуть знания. Но проблема в том, что, поскольку клиенты или потенциальные заказчики не обращают на это внимания, они задают наивные вопросы вроде: “Вы все еще будете на плаву?” вместо того, чтобы спросить: “Каков у вас стимул обеспечить поддерживаемость вашего программного обеспечения, а не действовать наоборот, чтобы я купил вашу следующую лицензию?”
Kieran Chandler: Так на что же должен обращать внимание специалист по цепочке поставок? Какие признаки указывают на то, что программа действительно поддерживаема по сравнению с программой, которая, возможно, немного устарела, а люди просто ленятся?
Joannes Vermorel: Во-первых, я бы сказал: просто посмотрите на стимулы, ведь это не так уж технически. Например, если вы покупаете лицензию или что-то подобное, и поставщик взимает значительные сборы за внедрение, это означает, что его доходы сосредоточены на начальном этапе проекта. А затем происходит просто уменьшение того же, то есть, буквально, нисходящая тенденция. У поставщика существует структурный стимул повторять эти высокие сборы за внедрение так часто, как только возможно.
Теперь посмотрите на Lokad. Мы взимаем ежемесячную плату без обязательств, и, как правило, окупаемся через два года. Поддерживаемость фактически представлена в виде фиксированной суммы, поэтому затраты на поддержку съедают маржу Lokad. Когда я позиционировал Lokad, я решил, что у нас есть своя доля риска, что мы платим цену за наличие непригодного для поддержки программного обеспечения, и это дает нам огромный стимул создавать что-то поддерживаемое. Из этого нет прибыли, и, наоборот, как поставщик, мы можем потерять деньги, если система не будет поддерживаемой.
Таким образом, модель ежемесячной подписки, при которой вы обеспечиваете, что ваш поставщик теряет деньги вначале, является очень хорошим, здоровым началом, которое закладывает основу проблемы, и поэтому система будет поддерживаемой. А затем вы должны убедиться, что поставщик отвечает за обслуживание своего собственного ПО, что по сути и является сутью модели «Программное обеспечение как услуга (SaaS)». Если система непригодна для поддержки, это, прежде всего, проблема поставщика, а не ваша как компании, занимающейся операционной деятельностью.
Kieran Chandler: Говоря о программном обеспечении для цепочек поставок, я часто вижу слайды и презентации конкурентов, демонстрирующие все составляющие их решения. Кажется, у них 20 сверхсовременных, сложных подсистем, таких как TensorFlow, Apache Spark, Kafka, MongoDB, React, Redux и многие другие. Они утверждают, что их решение находится на передовом уровне, но когда я это вижу, мне кажется, что его обслуживание станет настоящим кошмаром. У каждой компоненты свой жизненный цикл, и нет никаких гарантий, что они будут работать вместе в долгосрочной перспективе. Можете привести примеры, когда вы сталкивались с непригодным для поддержки программным обеспечением и проблемами, которые этому способствовали?
Joannes Vermorel: На уровне симптомов можно заметить, что когда люди отказываются от программного обеспечения, они переходят к использованию Microsoft Excel и таблиц для управления цепочками поставок. Не то чтобы крупные компании не покупали системы управления цепями поставок; возможно, за последние несколько десятилетий они приобрели даже три такие системы. Эти системы включают модули сложного прогнозирования, пополнения запасов, оптимизации ассортимента и управления промоакциями. Однако после первоначального внедрения, которое поддерживалось поставщиком, люди начинают сталкиваться с ошибками. Со временем эти ошибки накапливаются, и система становится труднее в обслуживании.
Kieran Chandler: Итак, что происходит, когда они отказываются от программного обеспечения?
Joannes Vermorel: Когда люди отказываются от программного обеспечения, они полностью отказываются от функционала и возвращаются к использованию таблиц Excel. Они решают выбрать, с чем бороться, и сосредотачиваются только на одном — экспорте данных в таблицу Excel. Они отказываются от надежд, что что-либо еще будет работать, кроме функции экспорта в Excel.
Kieran Chandler: Таблицы — и это история, которую я наблюдал во многих компаниях. Это буквально симптомы решения, которое стало полностью непригодным для поддержки.
Joannes Vermorel: Ладно, если подытожить сегодняшнее обсуждение, основная мысль такова: не всё, что блестит, является золотом, и, возможно, стоит относиться с осторожностью к тем компаниям, у которых эффектный пользовательский интерфейс, ведь в будущем могут возникнуть проблемы с поддерживаемостью. Опять же, я не говорю, что безобразный интерфейс — это решение. Если вы имеете дело с поставщиком, чей продукт выглядит так, будто он из 90-х, скорее всего, он уже настолько непригоден для поддержки, что поставщик даже не смог обновить свой интерфейс. Нет какого-то жесткого правила, но мой совет — оспаривать даже внутреннюю разработку, программное обеспечение, создаваемое внутри компании. Вам действительно нужно бросать вызов тем, кто отвечает за разработку. Каков ваш план по обеспечению поддерживаемости? Какие ключевые дизайнерские решения вы принимаете сейчас, чтобы гарантировать, что ваше программное обеспечение будет поддерживаемым? И если у людей нет четкого представления о том, как их дизайнерское решение влияет на будущую поддерживаемость, то, как правило, можно предположить, что программное обеспечение окажется непригодным для поддержки, ведь это состояние по умолчанию для продуктов, создаваемых в этой отрасли без должного внимания к поддерживаемости.
Kieran Chandler: Ладно, мы завершаем. Это всё на эту неделю. Спасибо, что были с нами, и до встречи в следующем выпуске. Спасибо за просмотр.
