Разговор про ничтожную стоимость ошибки, как в программировании. Я участвовал в одном проекте лет 20 назад - да, можно быстро править алгоритмы, да, можно на ходу использовать отладочные прошивки, да, разрешённой альтернативы у нас этим 8 stratix-ам вообще не было. Но вот издержки должны учитываться и не следует убеждать начальство, что они ничтожны)) Майкрософт просто отлаживался на бесплатных пользователях не неся никакой ответственности, а попробуйте крупному корпоративному клиенту продать что то необкатанное, а потом ещё быстро не починить. По мне так эта фраза является очень вредной как в обычном программировании, так и в технологиях вокруг плис, которые, как следует из статьи, становятся всё ближе к разработчику без пары десятков тысяч на вход)
"Ничтожно низкая стоимость ошибки" - может это всё таки только желаемое, с учётом даже не до конца описанных технологий?)) Да и в обычном программировании эта низкая стоимость наблюдается только в бесплатных сервисах и приложениях, где, по большому счёту, на пользователя наплевать и необходимость немедленно устранять ошибку отсутствует.
Если плис используется в более менее сложной массовой аппаратуре, то даже на тестирование этой аппаратуры уходят существенные ресурсы - автоматизация, симуляция, помещение, стойки, логи, люди. Ошибка требует исправления, верификации, и, как правило, полного цикла тестирования перед выводом в релиз, это меняет графики текущей разработки, сдвигает сроки.
Всё таки ниша FPGA, на мой взгляд, не очень изменилась за 25-30 лет - малосерийное и специальное применение там, где неэффективно использовать ASIC и готовый контроллер-чип.
Но в остальном очень интересная и информативная статья, 20 лет назад ничего подобного не проприентарного для полного цикла проектирования не было.
Никто не любит стандарты - ни пользователи, ни продажники, ни поддержка, ни программисты, особенно когда уже что то накриативили. Хороший пример с +7 и 8, особенно когда номер используется как логин.
Мне довелось участвовать в интернациализации телефонии одного продукта , так на это ушло года 3 в 3 или 4 релизах; и хотя требование о её введении было с самого верха нашей конторы, практически все пытались откосить от участия - внедрения. БД забита старыми номерами, пользователям неудобны номера с плюсом, операторы не поддерживают международную нумерацию (хотя сами могут прислать звонок в таком формате), какая то библиотека не парсит +, клиент имеет базу номеров с 8, тестеры не знают как сгенерировать номерной план, часть клиентов вообще не хочет что то у себя менять. Поддержка требует сделать чтобы нормально работало как раньше, продажники её поддерживают и эскалируют в менеджмент, тот их тоже поддерживает, пока не вспоминает про требование трёхлетней давности. Телефонисты предлагают сделать всё на их сисках и больше ничего не ломать.
Поэтому да - стандартов следует придерживаться изначально при выработке требований и спецификаций, и чтобы это проходило быстрей и мягче, кому то изначально хорошо бы их изучать и суммировать в мурзилке по внедрению.
Мне кажется причиной этого кажущегося "перевода ресурсов" является технологическое отставание и организационно-финансовые преграды в освоении новых технологий. Ну, к примеру, DSP - в нашем городе его освоил только небольшой коллектив, питаясь подачками местной оборонки. Как результат - через 7-10 лет и нескольких успешных проектов на нескольких НИИ стали появляться молодые специалисты по теме, руководство вникло в терминологию и специфику. Кажется странным, но две ведущие коммерческие конторы освоить эти технологии так и не смогли, они занимались аутсорсом и хотели просто купить специалистов на проект, но их к продаже не было, а они не рискнули потратиться на образование и исследования.
Коллективчик превратился в дизайн центр для нескольких несвязанных НИИ. Почему в самих этих НИИ не смогли сами всё это освоить? Ограничение и уравниловка зарплат, накладные 900%, финдисциплина на целевое расходование средств по госзаказам - а других нет. Отсутствие, видимо, руководящих указаний об освоении технологий - в вестнике в 90х им про виндовз писали, с не про DSP. А вот нанять маленький коллективчик, чтобы там что то посчитали и показали демку - вполне и по деньгам, и по правилам. Правда был ещё один материальный фактор - в этих НИИ закончилась рассыпуха, на которой они творили свои изделия, пришлось крутиться.
Разговор про ничтожную стоимость ошибки, как в программировании. Я участвовал в одном проекте лет 20 назад - да, можно быстро править алгоритмы, да, можно на ходу использовать отладочные прошивки, да, разрешённой альтернативы у нас этим 8 stratix-ам вообще не было. Но вот издержки должны учитываться и не следует убеждать начальство, что они ничтожны)) Майкрософт просто отлаживался на бесплатных пользователях не неся никакой ответственности, а попробуйте крупному корпоративному клиенту продать что то необкатанное, а потом ещё быстро не починить. По мне так эта фраза является очень вредной как в обычном программировании, так и в технологиях вокруг плис, которые, как следует из статьи, становятся всё ближе к разработчику без пары десятков тысяч на вход)
"Ничтожно низкая стоимость ошибки" - может это всё таки только желаемое, с учётом даже не до конца описанных технологий?)) Да и в обычном программировании эта низкая стоимость наблюдается только в бесплатных сервисах и приложениях, где, по большому счёту, на пользователя наплевать и необходимость немедленно устранять ошибку отсутствует.
Если плис используется в более менее сложной массовой аппаратуре, то даже на тестирование этой аппаратуры уходят существенные ресурсы - автоматизация, симуляция, помещение, стойки, логи, люди. Ошибка требует исправления, верификации, и, как правило, полного цикла тестирования перед выводом в релиз, это меняет графики текущей разработки, сдвигает сроки.
Всё таки ниша FPGA, на мой взгляд, не очень изменилась за 25-30 лет - малосерийное и специальное применение там, где неэффективно использовать ASIC и готовый контроллер-чип.
Но в остальном очень интересная и информативная статья, 20 лет назад ничего подобного не проприентарного для полного цикла проектирования не было.
Никто не любит стандарты - ни пользователи, ни продажники, ни поддержка, ни программисты, особенно когда уже что то накриативили. Хороший пример с +7 и 8, особенно когда номер используется как логин.
Мне довелось участвовать в интернациализации телефонии одного продукта , так на это ушло года 3 в 3 или 4 релизах; и хотя требование о её введении было с самого верха нашей конторы, практически все пытались откосить от участия - внедрения. БД забита старыми номерами, пользователям неудобны номера с плюсом, операторы не поддерживают международную нумерацию (хотя сами могут прислать звонок в таком формате), какая то библиотека не парсит +, клиент имеет базу номеров с 8, тестеры не знают как сгенерировать номерной план, часть клиентов вообще не хочет что то у себя менять. Поддержка требует сделать чтобы нормально работало как раньше, продажники её поддерживают и эскалируют в менеджмент, тот их тоже поддерживает, пока не вспоминает про требование трёхлетней давности. Телефонисты предлагают сделать всё на их сисках и больше ничего не ломать.
Поэтому да - стандартов следует придерживаться изначально при выработке требований и спецификаций, и чтобы это проходило быстрей и мягче, кому то изначально хорошо бы их изучать и суммировать в мурзилке по внедрению.
Мне кажется причиной этого кажущегося "перевода ресурсов" является технологическое отставание и организационно-финансовые преграды в освоении новых технологий. Ну, к примеру, DSP - в нашем городе его освоил только небольшой коллектив, питаясь подачками местной оборонки. Как результат - через 7-10 лет и нескольких успешных проектов на нескольких НИИ стали появляться молодые специалисты по теме, руководство вникло в терминологию и специфику. Кажется странным, но две ведущие коммерческие конторы освоить эти технологии так и не смогли, они занимались аутсорсом и хотели просто купить специалистов на проект, но их к продаже не было, а они не рискнули потратиться на образование и исследования.
Коллективчик превратился в дизайн центр для нескольких несвязанных НИИ. Почему в самих этих НИИ не смогли сами всё это освоить? Ограничение и уравниловка зарплат, накладные 900%, финдисциплина на целевое расходование средств по госзаказам - а других нет. Отсутствие, видимо, руководящих указаний об освоении технологий - в вестнике в 90х им про виндовз писали, с не про DSP. А вот нанять маленький коллективчик, чтобы там что то посчитали и показали демку - вполне и по деньгам, и по правилам. Правда был ещё один материальный фактор - в этих НИИ закончилась рассыпуха, на которой они творили свои изделия, пришлось крутиться.