Обнажите головы

Без преувеличения легендарный проект Microsoft Flight Simulator закрыт.

Комментарий разработчика, успевшего уйти из компании несколько раньше ещё самостоятельно.

Фантасты не соврали

Раз уже даже NYT написала, то видимо, уже точно можно говорить как о зафиксированном достижении, а не об эксперименте:

Совсем скоро, надо полагать, будет ещё круче. Для сравнения, это всего лишь 2006 год:

Да и вообще всё началось не так давно, в 2001-ом.

Если вдуматься, конечно, дух захватывает.

Brute Force Development

В продолжение предыдущего - встретился хороший термин, Brute Force Development:

I would suggest that BFD is the most widely practiced software development methodology in the world. In fact, I would claim that the majority of organizations and people use this methodology daily and have been since the inception of software development.

[...]

I can hear the Agile folks saying that our methodology is the one that mitigates this risk. While that may be partially true, how do you answer the question asked by the customer, how long will it take and how much will that cost? Oh yeah and at fixed price. And our requirements list is just that, a one pager with bulleted high level fatures items and some of the bulleted items have two words explaining the requirement. Ready to sign up? In the end, in order to make that deadline or not burn through your fixed cost, BFD man. That’s the reality.

[читать полностью]

Т.е. Agile и другие подобные практики действительно не дают такой уж точной предсказуемости и применимы не на всём возможном множестве проектов. По сути, по-настоящему достоверно предсказать можно лишь только то, что уже было сделано, а следовательно, не нужно.

Это, конечно, недостаток существующих методик и повод для их развития, причём не обязательно развития в сторону того же Agile - более чем возможно, что это тупиковая ветвь и для движения вперёд нужно отступить назад - это, в общем, нормально.

Но путать недостаток методики с достоинством её отсутствия и заявлять "чёрный ящик" BFD не как "вынужденную необходимость", а как "эффективный выход из ситуации", ошибочно.

"Не благодаря, а вопреки"

Увидел ссылку на приципиальный во многом спор Сполски и Мартина (их позиции здесь и здесь соответственно). В обсуждении удачно выделена наиболее показательная цитата Сполски:

One of the SOLID principles, and I'm totally butchering this, but, one of the principles was that you shouldn't have two things in the same class that would be changed for a different reason. Like, you don't want to have an Employee class, because it's got his name which might get changed if he gets married, and it has his salary, which might get changed if he gets a raise. Those have to be two separate classes, because they get changed under different circumstances. And you wind up with millions of tiny little classes, like the EmployeeSalary class, and it's just... (laughs) idiotic! You can't build software that way! The way real software works is that you create these very imperfect things, and they work great. They really do. And then you have a little problem, and you go and you fix the little problem, because it's code, and you have an editor, and you edit it. These classes are not going to go wander off flying in the universe all by themselves and need to work perfectly and unchanged until the end of time.

Для меня это выглядит настолько резко ошибочным, что даже сложно сформулировать поначалу, что именно не так ("слишком о многом нужно сказать"). Особенно если учесть, что автор высказывания занимается отнюдь не rocket science, а выпускает лучшем случае бизнес- и даже социальные продукты.

Грубо говоря, такой подход предполагает, что человек и его способности - самое сильное звено в производственной цепочке, а не наоборот. Мне же кажется, чтобы понять некоторую излишнюю оптимистичность (чтобы не сказать наивность) такой позиции, достаточно просто оглянуться вокруг.

CMIS

Коротко о CMIS и интеграции СЭД с его помощью

В том или ином виде развитые внешние интерфейсы для интеграции имеют многие популярные СЭД. И если не считаться с необходимостью писать сопрягающий код (обычных возможностей единой шины и подобных низкоуровневых интеграционных средств в таких случаях на практике совершенно недостаточно), то сама возможность их интегрировать была и раньше.

Предлагаемый стандарт более чем востребован, однако если в итоге всё равно реальная полная интеграция (просто по данным неинтересно, нужно и по логике - непрерывные транзакции между системами и т.д.) будет невозможна без написания достаточно сложного кода, пусть и на специальном языке, то это предложение довольно опасное - "узкое место" никуда не денется, а зависимостей прибавится.

Нужно будет обязательно ознакомиться подробнее.

I'll be bug

Живой жук с радиоуправлением

В том или ином виде такое делали и раньше, но здесь уж очень наглядно, особенно на видео. Интересно, что у жуков есть возможность просто "включить полёт" одним импульсом (так сказать, вызвать подпрограмму), в то время как у мотыльков нужно полностью контролировать движение крыла, строя движение самостоятельно.