Проходя мимо кинотеатра, наш читатель Руслан понял, что кина не будет. И кинщик тут был ни при чем.

Воздух был пропитан возбуждением. Смену веков бум интернет-компаний встретил в полной силе. Пузырь все надувался и надувался, казалось, он непобедим! Консалтинговая компания, на которую работал Крис Дж. заполучила самый большой контракт, который у нее когда-либо был. Впервые за ее существование контракт выражался семизначным числом. Цель? Создать дочерний сайт для крупного инвестиционного банка, который будет поставлять свежайшие новости и аналитику инвестиционного мира.

Клиент сразу же дал понять: он хочет, чтобы все было сделано, как следует, поэтому деньги не имеют значения. В конце концов, на дворе пик пузыря. Вместе с компанией Криса были наняты и вовлечены практически в каждую деталь проекта лучшие консультанты из IBM и Sun. После того, как большая часть анализа была закончена, пришло время обсудить требующееся железо.

Сегодняшняя статья переведна товарищем из Новосибирска по имени miroff, который уже 6 лет специализируется на управлении сложностью, интеграции гетерогенных систем и реанимации проектов с технологическими проблемами.

Жизнь Джерми была хороша. Он только что осел на хорошей работе с интересными коллегами в приятном, только что перестроенном офисе. Его кубикл располагался на идеальном расстоянии между лифтами, туалетом и торговыми автоматами. Босс признавал его, коллеги не стеснялись помогать, так что это была работа, которой он был искренне доволен.

Руководство компании Дэвида не очень доверяло традиционной производственной последовательности отправить/пересобрать/развернуть. По их ощущениям, для этого требовалось слишком много шагов, и прорва времени. Организации требовалось внедрять изменения — в частности исправления ошибок — гораздо быстрее. Поэтому для решения проблемы они внимательно изучили процесс разработки, и аккуратно внесли в него необходимые изменения. Шучу. На самом деле они решили внедрить инновационную методику - «SQL Предложения».

Начальники пришли к выводу, что, так как большая часть их приложения манипулировала данными в базе данных, то большинство багов возникает в результате неправильных SQL запросов. Скорее всего, там было что-то вроде использования LEFT JOIN вместо INNER JOIN, или > вместо >=. Они решили, что раз уж в их приложении уже была база данных, — вы уже поняли к чему все идет — почему бы тогда не хранить все SQL запросы в этой базе данных?

Пока физики и философы всего мира безуспешно ломают головы, изучая природу времени, компьютерщики, похоже, уже давно по нему путешествуют. Простые смертные могут наблюдать следы этих перемещений повсеместно. В бесчисленных множествах программных продуктов и сопутствующих им товарах народного хозяйства. К сожалению, подобные временные перемещения доступны в основном только вовлеченным в информационные технологии людям. Зато как все просто. Достаточно вставить в код волшебное //TODO: и готово. Дальше можно уже ничего не реализовывать, не наращивать плоть кода или логики, а смело выпускать продукт как есть. В любом случае в будущем все равно кто-то рано или поздно залепит эти дырки, следовательно, их наличие в прошлом роли не играет. А люди, не способные понять время, лишь расстраиваются, натыкаясь на ссылки в будущее. Им, жителям настоящего, видимо будущего не понять.