Timeline and Risk: How to Piss Off Your Software Developers | Rob Walling

Timeline and Risk: How to Piss Off Your Software Developers

Сроки и риск: как взбесить своих разработчиков

Today we’re going to focus on a sentence that will make almost any developer, even a mild-mannered one, want to box up their red Swingline and head to Tahiti for early retirement.

Сегодня мы сосредоточимся на одной фразе, от которой почти любой разработчик, даже самый кроткий, захочет упаковать свой красный Swingline и уехать на Таити встречать ранний выход на пенсию.

I believe that software developers strive to do the best work they can. Most programmers will fight tooth and nail, work evenings and weekends, and scale Mt. Everest on their hands to make sure they don’t let their team down. I am, of course, speaking of teams that don’t have morale problems. While I acknowledge that they exist, they’re not the focus of this article.

Я убеждён, что разработчики стремятся делать свою работу как можно лучше. Большинство программистов будут биться зубами и когтями, работать вечерами и по выходным и взбираться на Эверест на руках, лишь бы не подвести свою команду. Речь, разумеется, идёт о командах, у которых нет проблем с моральным духом. Я признаю, что и такие команды существуют, но они не тема этой статьи.

In the context of a high-functioning team, some developers have the innate gift of self-motivation and strive for their best at all times. For others it’s the team dynamic that keeps their hands on the keyboard. As a developer learns to rely on his teammates and trust relationships form, they make it difficult to coast for fear of letting the group down and the thought of being dubbed the weakest link. This amalgam of competition and camaraderie is what helped companies like Google, Apple and Microsoft dominate their markets and convince their employees to work 90 hours a week and love it.

В контексте высокоэффективной команды одни разработчики обладают врождённым даром самомотивации и всегда стремятся к лучшему. Для других руки на клавиатуре удерживает командная динамика. По мере того как разработчик учится полагаться на товарищей и между ними складываются доверительные отношения, ему становится трудно филонить — из страха подвести группу и из-за мысли о том, что его назовут слабым звеном. Именно этот сплав соперничества и товарищества помог таким компаниям, как Google, Apple и Microsoft, доминировать на своих рынках и убедить сотрудников работать 90 часов в неделю и получать от этого удовольствие.

But getting back to the point: what’s the one sentence that makes software developers angry?

Но вернёмся к сути: что же это за одна фраза, которая злит разработчиков?

You might be thinking it’s the insidious:

Возможно, вы думаете, что это коварное:

“This bug is only reproducible on Opera v0.3 for the Commodore 64, but fix it anyway,” or the always favorite

«Этот баг воспроизводится только в Opera v0.3 для Commodore 64, но всё равно почини его», или вечно любимое:

“We don’t have a design yet, but start building something because our deadline isn’t moving.”

«Дизайна у нас ещё нет, но начинай строить хоть что-нибудь, потому что дедлайн никто не сдвигает».

Nope on both counts.

Нет, ни то, ни другое.

This sentence I speak of is the lesser known:

Фраза, о которой я говорю, — менее известная:

“Build higher quality software in the same amount of time.”

«Делайте более качественное ПО за то же время».

That’s it…only ten words, fewer if you overlook some grammar rules. So why is this sentence so potent?

Вот и всё… всего десять слов, а если закрыть глаза на правила грамматики, то и меньше. Так почему же эта фраза так убойна?

On its own merits, the phrase build higher quality software in the same amount of time will not incite your software developers to riot. But let’s examine the underlying message.

Сама по себе фраза делайте более качественное ПО за то же время не доведёт ваших разработчиков до бунта. Но давайте разберём заложенный в ней посыл.

The Triangle

Треугольник

Quality and speed are two of the three forces in the famous three-sided triangle of quality, speed and cost. It’s a fairly well-known business principle that you can choose two of the three sides of this triangle; anyone who tells you otherwise is trying to sell you something. As an aside, if you buy what they’re selling, send me an email ‘cuz I have some Beanie Babies I’m looking to get rid of.

Качество и скорость — две из трёх сил знаменитого треугольника качества, скорости и стоимости. Это довольно известный бизнес-принцип: вы можете выбрать две из трёх сторон этого треугольника; всякий, кто утверждает обратное, пытается вам что-то продать. Кстати, если вы купитесь на то, что он продаёт, напишите мне на почту, потому что у меня тут завалялись Beanie Babies, от которых я хочу избавиться.

There are many definitions of “quality,” but in this article I’m speaking of software that is well-designed and well-written so as to ensure high availability (high uptime) and make it easy to maintain and extend.

Существует множество определений «качества», но в этой статье я имею в виду ПО, которое хорошо спроектировано и хорошо написано так, чтобы обеспечивать высокую доступность (высокий аптайм) и легко поддаваться сопровождению и расширению.

With that in mind, let’s look at what happens if you keep cost the same, meaning you don’t hire more developers, but want to develop higher quality software.

С учётом этого давайте посмотрим, что произойдёт, если оставить стоимость неизменной — то есть не нанимать больше разработчиков, — но при этом захотеть разрабатывать более качественное ПО.

You could ask your developers to work more hours. This would likely work temporarily, at least, since more time usually translates into increased productivity. It’s debatable whether someone performing work as concentration-intensive as programming is able to function well after a solid 8+ hours, but I’ll give you the benefit of the doubt on this one. Even so, studies have shown that “continuing scheduled overtime has a strong negative effect on productivity.” So for the short term we can bring out the whip and expect a slight jump in productivity, but assuming we want something that lasts longer than a few months and don’t want to experience a McDonalds-esque churn rate (because that would inevitably increase our cost and decrease the quality of our software), let’s throw this option out the window.

Можно попросить разработчиков работать больше часов. Какое-то время это, вероятно, сработает — по крайней мере временно, ведь больше времени обычно даёт больше производительности. Спорно, способен ли человек, выполняющий настолько требовательную к концентрации работу, как программирование, хорошо функционировать после плотных 8+ часов, но в этом вопросе я дам вам фору. И всё же исследования показали, что «продолжительные плановые переработки оказывают сильное негативное влияние на производительность». Так что в краткосрочной перспективе мы можем достать кнут и ожидать небольшого скачка производительности, но если нам нужно что-то, что продержится дольше нескольких месяцев, и мы не хотим столкнуться с текучкой кадров в духе McDonald’s (потому что это неизбежно увеличит нашу стоимость и снизит качество нашего ПО), давайте выбросим этот вариант в окно.

Another option would be to hire better people. This has a decent probability of increasing quality over time, but it’s not a solution one can implement overnight. With a team of 20 developers you’re probably looking at nine to twelve months to clean out less-productive developers and fill it with solid talent, assuming you have a few less-productive members on your team. However, if your development team is already a group of “coding machines,” or if your goal is to implement something immediately then another avenue must be explored, even if you decide to pursue this one for the long-term. Training and/or mentoring is a variation of this option with similar advantages, but a similar time-horizon.

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

Another alternative would be to simply make your people work harder.

Ещё одна альтернатива — просто заставить ваших людей работать усерднее.

Hmmm…this is an interesting one. If you buy what I said at the start of this article, that most developers are already working at or close to their best due to personal or social reasons, then this hypothesis doesn’t quite pan out. How can someone who’s already working at a high level of productivity all of a sudden work harder? Making someone work harder simply by asking them to is…well…hard to understand.

Хм… вот это интересно. Если вы принимаете то, что я сказал в начале статьи, — что большинство разработчиков уже работают на пределе или близко к нему в силу личных или социальных причин, — то эта гипотеза не очень-то работает. Как может тот, кто и так работает на высоком уровне продуктивности, вдруг начать работать усерднее? Заставить человека работать усерднее, просто попросив его об этом, — это… ну… трудно понять как.

And that’s why telling someone to build higher quality software in the same amount of time is insulting, because you’re essentially telling them they’re not giving it their best effort. That they’re screwing off.

И именно поэтому говорить кому-то «делай более качественное ПО за то же время» оскорбительно: ведь по сути вы говорите ему, что он выкладывается не в полную силу. Что он отлынивает.

And that makes people mad.

А это людей злит.

How do I know this? Because someone said it to me the other day. Not just me, in fact, our entire development team.

Откуда я это знаю? Потому что на днях такое сказали мне. И не только мне — на самом деле всей нашей команде разработки.

Better Software

Лучшее ПО

A non-technical manager told us that we have to build better software in the same amount of time, and even included the phrase “No excuses.”

Нетехнический менеджер заявил нам, что мы должны делать лучшее ПО за то же время, и даже добавил фразу «Никаких отговорок».

Needless to say morale has seen a slight decline in the days following as developers express their feelings of defensiveness. People who’ve been giving it their best suddenly feel taken for granted and frustrated, especially the ones who’ve been working extra hours, solving project issues in their spare time, and running performance tests on the weekend. When you’re already working hard it’s difficult to hear someone tell you to work harder.

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

The talk was prompted by a recent issue where some high-availability systems were down for the better part of a day. These systems were written over the past 4+ years under perilous death-march schedules, with little QA because we were in a hurry to get them out the door. When they went down people panicked, and rightfully so, since many of our customers were foaming at the mouth.

Поводом для разговора стал недавний инцидент, когда некоторые высоконадёжные системы лежали бо́льшую часть дня. Эти системы писались на протяжении более чем 4 лет под рискованными графиками «марша смерти», практически без QA, потому что мы торопились выпустить их в свет. Когда они упали, люди запаниковали — и не зря, ведь многие наши клиенты были в бешенстве.

As a result management expressed their concern with the situation, indicating that something had to be done as we move forward. As I was listening I understood “Make better software; reduce risk of failure.” As most developers would agree, this is a great approach, and one that several members of our team have been advocating for for quite some time. I became excited at the thought of ensuring we have ample QA and including more safeguards in our code. But my parade soon ended in a blizzard when I heard “I don’t want to hear excuses about how things are going to take longer. We can get things done fast AND better.” And that’s when I realized I needed to write this article.

В результате руководство выразило обеспокоенность ситуацией, указав, что в дальнейшем нужно что-то предпринять. Слушая, я понимал это как «Делайте ПО лучше; снижайте риск отказов». С чем согласится большинство разработчиков, это отличный подход, и за него уже довольно давно ратовали несколько членов нашей команды. Я воодушевился при мысли о том, чтобы обеспечить достаточный QA и добавить в наш код больше предохранителей. Но моё ликование вскоре накрыло метелью, когда я услышал: «Я не хочу слышать отговорок о том, что это займёт больше времени. Мы можем делать всё быстро И лучше». И вот тогда я понял, что мне нужно написать эту статью.

But wait, there’s a little more.

Но погодите, это ещё не всё.

A comparison was made between our software and the software of a large financial organization (think Wells Fargo or Washington Mutual). If you’re thinking “I can’t remember the last time one of those guys was down for an extended period of time,” you’re right; they typically aren’t down, and when they are it’s not for very long. But an interesting thing I’ve learned in the past few years is that the software development cycle for these guys is loooooong, to the tune of 2-3 times what our timelines run.

Было проведено сравнение нашего ПО с ПО крупной финансовой организации (представьте Wells Fargo или Washington Mutual). Если вы думаете «Я не припомню, когда в последний раз кто-то из них надолго ложился», вы правы; они обычно не лежат, а если и лежат, то ненадолго. Но интересная вещь, которую я узнал за последние несколько лет, — это то, что цикл разработки ПО у них дли-и-инный, раза в 2–3 длиннее наших сроков.

In other words, they’ve decided to take the “time” side of their pyramid and make it really big in exchange for a really big “quality” side. And good for them, because they’ve obviously made a wise choice, as indicated by their availability.

Иными словами, они решили взять сторону «времени» своей пирамиды и сделать её очень большой в обмен на очень большую сторону «качества». И молодцы, ведь они явно сделали мудрый выбор, о чём свидетельствует их доступность.

Now that we’re faced with the same dilemma it’s time to pay the piper and admit we need to lower our risk while at the same time admitting to ourselves the sacrifice that it will ultimately require: time.

Теперь, когда перед нами встала та же дилемма, пора платить по счетам и признать, что нам нужно снизить риск, одновременно признав и ту жертву, которую это в конечном счёте потребует: время.

The Moral

Мораль

There are at least two morals to this story

У этой истории есть как минимум две морали.

The first is that you will eventually reap what you sow, so don’t compromise your design. Fight tooth and nail and push out timelines if you have to. This is not going to be easy, so good luck. Let me know if you discover any secrets because I would love to hear them.

Первая: рано или поздно вы пожнёте то, что посеяли, поэтому не идите на компромиссы в проектировании. Бейтесь зубами и когтями и отодвигайте сроки, если придётся. Это будет нелегко, так что удачи. Дайте мне знать, если откроете какие-то секреты, — я был бы рад их услышать.

The other is that reducing risk takes time. At this point I should add that it’s our responsibility as technical folk to educate those who don’t know this. A concept that appears so clear to us may not be apparent to a person outside if the IT department. We’re the only people that truly understand the complexity of the systems we build and the ramifications of spending too little time on design or QA.

Вторая: снижение риска требует времени. Здесь стоит добавить, что это наша обязанность как технических специалистов — просвещать тех, кто этого не знает. Концепция, которая кажется нам столь очевидной, может быть совсем не очевидна человеку вне IT-отдела. Только мы по-настоящему понимаем сложность систем, которые строим, и последствия того, что на проектирование или QA тратится слишком мало времени.

Reducing risk is a lot like having insurance – if you elect to have it you have to pay for it.

Снижение риска очень похоже на страховку: если вы решаете её иметь, за неё придётся платить.

Send this article to a manager or co-worker who’s tried to convince you otherwise.

Отправьте эту статью менеджеру или коллеге, который пытался убедить вас в обратном.