?

Log in

No account? Create an account
 
 
26 February 2017 @ 05:38 am
Committing code often  
I asked a developer on my team to commit code frequently: at least once per day or more.
Even if feature is not ready - commit parts of this feature, prototypes, or even mixture of draft code and draft notes.

The developer objected that:
1) Not every feature fits into one day of development. (I agree with that).
2) Commiting raw code, and especially committing raw notes - effectively publishes them.
And publishing raw ideas - makes them to prematurely solidify, which, in turn, negatively affects future research, because there is a bias toward solid ideas, while alternative solutions are more likely to lose even if they are good.
(I kind of agree with that effect, but only partially. Publishing ideas solidify them a little, but that effect is more positive than negative).
3) Commiting/publishing raw notes violates developer's privacy, because raw notes represent unfiltered train of thoughts.
(My thinking is that since these notes were created as an attempt to find a solution to a work problem - there raw notes are very unlikely to contain any personal secrets. Raw notes can still contain weird thoughts or even silly mistakes, but that is OK - there is no need to be ashamed of mistakes in early research thoughts).

My main reasons to have code committed frequently is:
1) Check that work goes in the general direction that is likely to satisfy business goals.
2) Review new research and code in reasonably small chunks, so that code reviewer is able to understand them.
3) See not only final polished solution, but also mistakes and research dead ends along the way. That helps learning more.

What do you think: is trying to commit code at least once per day - too frequent or a good goal?

Originally posted at: http://dennisgorelik.dreamwidth.org/125416.html
 
 
 
стриш-ш-ш (ш-ш-ш!)lxe on February 26th, 2017 10:51 am (UTC)
"Per day" is extremely rare. A single commit per day means the developer spent time doing something else (e.g. thinking the architecture out, prototyping (where's the prototype then?), having a good time with his wife and kids, reading Facebook, etc.).

One refactoring/naming/formatting operation, one commit.
One purely additive change, one commit.
One "safe deletion" change, one commit.
One implementation change, one commit. (i)
One contract change (e.g. method or template signature), one commit.

With the guidelines above, 96% of the changes are either local (i) or otherwise harmless changes with no side effect.
стриш-ш-ш (ш-ш-ш!)lxe on February 26th, 2017 10:52 am (UTC)
Prototype/experimentation branches are just fine.
So are "TODO|WISDOM|MOREINFO" notes.

Edited at 2017-02-26 10:53 am (UTC)
Dennis Gorelikdennisgorelik on February 26th, 2017 10:56 am (UTC)
1) Why separate branches and not master branch (even for early prototypes)?

2) Even separate branches would mean "publishing thoughts". Is there any risks in premature thoughts solidification?
(no subject) - lxe on February 26th, 2017 11:41 pm (UTC) (Expand)
(no subject) - dennisgorelik on February 27th, 2017 06:05 am (UTC) (Expand)
(no subject) - lxe on February 27th, 2017 06:23 am (UTC) (Expand)
(no subject) - dennisgorelik on February 27th, 2017 07:06 am (UTC) (Expand)
(no subject) - lxe on February 27th, 2017 07:21 am (UTC) (Expand)
(no subject) - dennisgorelik on February 27th, 2017 07:49 am (UTC) (Expand)
(no subject) - lxe on February 27th, 2017 08:05 am (UTC) (Expand)
(no subject) - dennisgorelik on February 27th, 2017 08:13 am (UTC) (Expand)
(no subject) - lxe on February 27th, 2017 08:15 am (UTC) (Expand)
(no subject) - dennisgorelik on February 27th, 2017 08:20 am (UTC) (Expand)
(no subject) - lxe on February 27th, 2017 08:24 am (UTC) (Expand)
(no subject) - dennisgorelik on February 27th, 2017 08:41 am (UTC) (Expand)
(no subject) - lxe on February 27th, 2017 08:58 am (UTC) (Expand)
Critique-less programming - dennisgorelik on February 27th, 2017 10:08 am (UTC) (Expand)
Re: Critique-less programming - lxe on February 27th, 2017 10:19 am (UTC) (Expand)
Re: Critique-less programming - dennisgorelik on February 27th, 2017 10:26 am (UTC) (Expand)
Re: Critique-less programming - lxe on February 27th, 2017 10:34 am (UTC) (Expand)
The liberty of not proving the obvious - dennisgorelik on February 27th, 2017 11:30 am (UTC) (Expand)
Re: The liberty of not proving the obvious - lxe on February 27th, 2017 12:19 pm (UTC) (Expand)
Re: Critique-less programming - lxe on February 27th, 2017 10:37 am (UTC) (Expand)
Re: Critique-less programming - yatur on February 27th, 2017 06:05 pm (UTC) (Expand)
Re: Critique-less programming - lxe on February 27th, 2017 10:43 pm (UTC) (Expand)
Re: Critique-less programming - yatur on February 27th, 2017 10:48 pm (UTC) (Expand)
Re: Critique-less programming - dennisgorelik on February 27th, 2017 11:21 pm (UTC) (Expand)
mugunin: ninmugunin on February 26th, 2017 04:40 pm (UTC)
One should commit more often than once a day.
But committing is consequence of coding style, it is not an arbitrary requirement. To commit more often a developer should change his (her) coding to better coding style, like TDD, the result will be much more frequent committing.


Edited at 2017-02-26 04:41 pm (UTC)
Anatoli Dontsovlamantyn on February 26th, 2017 05:23 pm (UTC)
Business "commits" tax related forms every quarter.
What if we have business to file taxes every day?

You can pay salary every day, not two times per month.
Or pay bonus every day, not once a year.

Setting arbitrary goal is not better than setting a goal to cop - "issue X speeding tickets per day".

Commit implies something logical and working, not breaking build or product.
Developer must test it.
One can make two tasks in a day and make two commits.
Or make one task in a week.

Inspecting of code is time and money.
You can just put two developers for the same task - one is programming, narrating what he is doing and why; and second developer is controlling that in real time.

Code quality will be better. But not twice as the cost.

"personal secret" is incorrect term. The right term is "privacy".
It is not a secret what you are doing in toilet, but you would not agree to web-camera there, would you?
At the same time business would like to check whether the worker spends too much time, or use too much paper.
Dennis Gorelikdennisgorelik on February 27th, 2017 05:07 am (UTC)
Code privacy
> It is not a secret what you are doing in toilet

More detailed view of what happens in a toilet - IS a secret.

Can code have such private/secret details?

> business would like to check whether the worker spends too much time

Correct.
More frequent commits allow measuring time spent much better.
Anatoli Dontsovlamantyn on February 27th, 2017 05:32 am (UTC)
Re: Code privacy
Not a secret. And if you are immobilized on hospital bed - you would do it without privacy, with nurse help.


> More frequent commits allow measuring time spent much better.

Totally agree. As well as a keylogger - count number of clicks and mouse movement and periodic screenshots.
You could find developers willing to work under such control freak supervision.
Not the best ones, of course. People like privacy.
Re: Code privacy - dennisgorelik on February 27th, 2017 05:53 am (UTC) (Expand)
Dennis Gorelikdennisgorelik on February 27th, 2017 05:15 am (UTC)
> Commit implies something logical and working, not breaking build or product.

Yes: it should be at least buildable.
If it is committed in form of test or in form of class that is not called by actual production code - then it will not break anything.
Still, there is some overhead on "brushing up" code pre-commit.
But:
1) That "pre-commit brushing up" is required anyway, and probably would become too big in case of single big commit (meaning that single brush up could become much longer than sum of brushing up parts).
2) Once per day does not add much "pre-commit brushing up" overhead anyway.
Or does it?


> Setting arbitrary goal is not better than setting a goal to cop - "issue X speeding tickets per day"

It would be a correct comparison if I was asking to "commit X lines of code per day" or "fix Y bugs per day".

But I am asking to commit accomplishments for a day - whatever they are.
Anatoli Dontsovlamantyn on February 27th, 2017 06:03 am (UTC)
> called by actual production code

I wrote "product", not "production".
Other developers can get "nightly" build and issues may affect their work/testing.


"accomplishment" - something that has been achieved successfully.
"work in progress" at arbitrary time is not accomplishment.
why "per day"? Can we do it every 6 hours 42 minutes?

Auto-backup can run every 10 minutes.
Inspection, code review, judgement, etc - must be done when ready.

Again - put yourself in this shoes. Imagine IRS is inspecting you daily.

(no subject) - dennisgorelik on February 27th, 2017 07:18 am (UTC) (Expand)
(no subject) - yatur on February 28th, 2017 04:57 am (UTC) (Expand)
(no subject) - dennisgorelik on February 28th, 2017 02:58 pm (UTC) (Expand)
Dennis Gorelikdennisgorelik on February 27th, 2017 05:18 am (UTC)
Pair programming
> You can just put two developers for the same task - one is programming, narrating what he is doing and why; and second developer is controlling that in real time.
> Code quality will be better. But not twice as the cost.

The quality could easily be more than twice the cost.
Here are the reasons:
1) External code reviewer can catch errors that original developer simply would not notice.
2) Code reviewer and original developer teach each other (knowledge exchange).
3) Pair programming may allow to get much better focus on the task and, therefore, significantly improve both quality and speed of development.
mam6amam6a on February 26th, 2017 05:41 pm (UTC)
1. Если вы хотите обменяться информацией с человеком, то лучше личной встречи ничего не придумать. Он вам наглядно покажет, что и как у него написано за время с прошлой встречи, вы сразу сможете обменяться мнениями и убедиться, что каждый понимает друг друга правильно.
Кроме того, вы в таком случае для подчиненного будете означать личность. Плюс к словам, которые вы скажете, вы еще обменяетесь эмоциями, он посмотрит ваше состояние, вы - его. В чем то вы его похвалите, поощрите, где-то надавите. Когда руководитель олицетворяет собой морковку и палку, его подчиненные работают гораздо лучше.
2. Всё зависит от уровня руководителя. Я бы предложил вам мысленно построить отрезок, с одной стороны которого экстремально высокие навыки эксперта и профессионала, "ремесленника", а на другой - руководителя, именно как человека коммуникации и цикла Дёминга. Проблема в том, что экспертная власть именно как власть - плохая, негодная. У таких руководителей есть тенденция подминать под себя коллектив, не растить замену, не давать выдвинуться перспективным новичкам. С другой стороны, став именно руководителем, вам тяжело будет вернуться к работе руками.
3. Опять таки лучше это обсудить совместно.

Как мне представляется, требовать частых коммитов в общем случае не стоит. Главная причина в том, что программист - не мясорубка и не вязалка веников, из которой ровно идет. В какой-то момент на него надо надавить, что стимулирует мозговую деятельность, но в какой-то момент и дать расслабиться, чтобы он не потерял мотивацию и/или не заболел.
Кроме того, вы лишаете человека чего-то наподобие рабочего пространства. По идее, мы же всегда учимся и изучаем что-то новое. Пусть у него будет время и возможность поискать что-то новое, потыкаться в тупики и наделать ошибок, но только так, чтобы это было его приватное. Тем более, что установив доверительные отношения, вы от него всю информацию будете получать, не копаясь все время в коде.
Dennis Gorelikdennisgorelik on February 27th, 2017 05:25 am (UTC)
> лучше личной встречи ничего не придумать

Насколько часто следует проводить "личные встречи" с программистом?

> требовать частых коммитов в общем случае не стоит

"Часто" - это сколько? Раз в час? Раз в день? Раз в неделю?

> потыкаться в тупики и наделать ошибок, но только так, чтобы это было его приватное.

Зачем делать ошибки приватными?
Почему бы их не обсудить в команде?
Команда может подсказать неожиданное решение или, наоборот, научиться из уже сделанных ошибок.
mam6amam6a on February 27th, 2017 12:20 pm (UTC)
Частота встреч зависит от ситуации и от самого разработчика.
У меня были проекты, где надо было автоматизировать открывающийся бизнес с нуля. В день открытия выясняется, что бизнес-архитектура, на которой всё построено, не соответствует реальности и надо на 50-80 процентов всё переделать*. В этот момент я могу каждые полчаса доставать людей, которые отвечают за важные участки - и это работает, потому что люди понимают, что так надо.
Если ничего срочного нет, то можно ограничиться 2-3 встречами в неделю.
Сами люди тоже разные. Если к одним регулярно заходить, они будут думать "что он ко мне пристает, я же всё нормально делаю". А вы такие перестали заходить, и другие подумают "он у меня ничего не спрашивает и не интересуется моей работой, наверняка выгонит скоро".

Частый коммит - это не тот, который решает задачу, а который для коммита.

По поводу ошибок вы правы, надо разбирать их и извлекать пользу. Вопрос в том, какова культура процесса. Я видел множество безобразных сцен, когда руководитель группы высмеивал и стыдил сотрудника при коллективе "у тебя мозги где были?", "ты этого не знал?", стыдобище. Решение людей покидать таких руководителей для меня не было неожиданным.
Ок, человек ошибся или находится в затруднении. Прежде чем вынести их на обсуждение в команде, необходимо** решить, кому и какую пользу это принесет.

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

==================================
*Вы скажете, что это полное безобразие и разгильдяйство, но я соглашусь с вами только отчасти. По моему опыту, ИТ-проекты уровня бизнеса, где все заранее спланировано и реализовано, проваливаются. Успешно развивается та система, разработкой которой управляют как стартапом.
**Кому необходимо? Руководителю, который хочет создать и поддерживать команду, которая будет работать с высокой производительностью, устойчиво и комфортно для всех участников. Организационные системы, в которых руководитель реализует свои не лучшие комплексы и занимается плётка-менеджментом "в фейсбуке сидел?!", менее устойчивы и изнашивают человеческий капитал.
(no subject) - dennisgorelik on February 27th, 2017 01:46 pm (UTC) (Expand)
(no subject) - mam6a on February 27th, 2017 02:32 pm (UTC) (Expand)
(no subject) - dennisgorelik on February 27th, 2017 02:56 pm (UTC) (Expand)
(no subject) - mam6a on February 27th, 2017 03:12 pm (UTC) (Expand)
Yaturkenzhensirhiv - a handheld spyyatur on February 26th, 2017 06:45 pm (UTC)
> I asked a developer on my team to commit code frequently

What were the reasons behind your request?

Did you wish to facilitate incremental development, or did you want to have more opportunities to review the code and ask questions?

Incremental development is a good practice. When I actively code, I commit every 15 minutes to 2 hours, not because someone forces me, but because this allows me not to lose work in case my next step goes wrong.

However, if my bosses loved to micromanage, I would make sure they see as few commits as possible. If every commit becomes a fight, I naturally would want to minimize the amount of time spent fighting. With complete working code you can at least say "see, it works, I fulfilled the acceptance criteria". Incomplete code is much harder to defend against nosy bosses.
Dennis Gorelikdennisgorelik on February 27th, 2017 05:39 am (UTC)
For me, practice of incremental development is not the goal itself, but a tool to accomplish other things: easier code review, better tracking of progress and ability to revert changes.

> if my bosses loved to micromanage

What is your criteria of micromanaging?
Do you consider reviewing your individual commits - a micromanagement?

> If every commit becomes a fight,

Why would it be a fight, if you commit without code review?
The "fight" may happen later though.

> Incomplete code is much harder to defend against nosy bosses.

I'd say that incomplete code is much easier to defend, specifically because it is code in progress and is incomplete: "it was an early version that I already fixed (or plan to fix)" or "This code would probably be needed for X, but if not - I would delete it" etc.
Yaturkenzhensirhiv - a handheld spyyatur on February 27th, 2017 05:52 am (UTC)
> easier code review
Multiple commits make code review harder. There is more stuff to review.

> better tracking of progress
Well, the developers may not be interested :)

> and ability to revert changes
Bingo. That's why I use it.

> Do you consider reviewing your individual commits - a micromanagement?
Yes.

> Why would it be a fight, if you commit without code review?
If I commit without code review, there is no fight.

> I'd say that incomplete code is much easier to defend
It depends on the circumstances. Anyway, no commit means there is nothing to defend. So, there is less conflict and less overhead.



Dennis Gorelikdennisgorelik on February 27th, 2017 06:17 am (UTC)
> Multiple commits make code review harder. There is more stuff to review.

I do not agree.
Individual commits allow code reviewer to grasp individual concepts one by one with every commit.
And then review the final result together.

Or skip reviewing individual commits and review only final result.

In case if there is only one big commit - it could be very hard to tie individual line of changed code to a business or technical concept behind it.

> Well, the developers may not be interested :)

If developer does not track his own progress and tries to prevent others from tracking his progress - then he reduces his ability to improve his programming performance (both in terms of quality and speed).
Then there is nothing to show when negotiating salary raise.

>> reviewing your individual commits - a micromanagement?
> Yes.

Why?
Code review usually means mutual learning.
What is the good alternative to spreading knowledge across the team?

> no commit means there is nothing to defend

... and "nothing to defend" means "no opportunity train (yourself and others)".
(no subject) - yatur on February 27th, 2017 06:31 am (UTC) (Expand)
(no subject) - dennisgorelik on February 27th, 2017 06:42 am (UTC) (Expand)
Konstantin S. Uvarinlodin on February 26th, 2017 11:24 pm (UTC)
Speaking as a lazy and disorganized person myself, I'd say that frequent commits (~3 a day, maybe more) are a great idea. Commit - push - go for a smoke/coffee. This should be a reflex.

But. These commits should only go to a personal branch, and never ever should anyone be judged, scolded, or made fun of based on what they do until they create a pull request. So this is not "publishing", merely insurance against disaster.

As for the general direction, I tried to start out a "solution review" mailing list inside LiveNation as opposed to code review, so that a proposed solution can be discussed before the code is written. This never took off however.
Dennis Gorelikdennisgorelik on February 27th, 2017 06:03 am (UTC)
> never ever should anyone be judged, scolded, or made fun of

That is exactly what I struggle to understand.
Why not expose your raw code to everyone to criticize?

It is ok to make mistakes, especially in the first "rapid-fire" version of the code.
There is no shame in it.

Even more: if you are not making any mistakes while coding - that means you are way too careful and are working much slower than you can.
(That does not mean, of course, that you should intentionally do mistakes. Just take greater risks in order to improve speed of programming/coding until you start getting occasional mistakes).
Yaturkenzhensirhiv - a handheld spyyatur on February 27th, 2017 06:15 am (UTC)
> That is exactly what I struggle to understand.
> Why not expose your raw code to everyone to criticize?

There are two reasons for that.

Subjectively, dealing with critique is always unpleasant. People don't like to feel stupid (when critique is justified), and even less they like to defend their correct solution against someone who has no clue, but is always ready to offer an advice (when critique is not justified).

Objectively, dealing with critique takes time and mental effort. So, consider it an optimization strategy: if you want more intermediate check ins, you should promise developers that they will not be subject to scrutiny and critique, and you should keep your word. The proverb "дураку полработы не показывают" exists for a reason.

Edited at 2017-02-27 06:15 am (UTC)
(no subject) - dennisgorelik on February 27th, 2017 06:32 am (UTC) (Expand)
(no subject) - yatur on February 27th, 2017 06:39 am (UTC) (Expand)
"Abundant critique" environment - dennisgorelik on February 27th, 2017 06:50 am (UTC) (Expand)
(no subject) - lodin on February 27th, 2017 09:26 am (UTC) (Expand)
(no subject) - dennisgorelik on February 27th, 2017 10:16 am (UTC) (Expand)
(no subject) - yatur on February 27th, 2017 01:37 pm (UTC) (Expand)
(no subject) - dennisgorelik on February 27th, 2017 01:56 pm (UTC) (Expand)
Konstantin S. Uvarinlodin on February 27th, 2017 06:47 am (UTC)
In a perfect world (with unicorns and pegasi) I agree - it's ok to make mistakes. In the real world people tend to take them personally, though. This cannot be helped, apart from learning to separate one's own mistakes from oneself. But demanding that from others (who didn't ask to teach/enlighten them) is a bit too much.

I don't quite like the "even more" part, but this is probably true. Going to think more about it.
(no subject) - dennisgorelik on February 27th, 2017 07:01 am (UTC) (Expand)
(no subject) - lodin on February 27th, 2017 07:59 am (UTC) (Expand)
(no subject) - dennisgorelik on February 27th, 2017 08:10 am (UTC) (Expand)
Dade Murphysnsokolov on February 27th, 2017 03:56 am (UTC)
>The developer objected that:
Что-то мне кажется что девелопер явно булшитит вас. Аргументы из разряда сказать в ответ больше слов, чем сказали тебе. На мой взгляд в этом вопросе один единственный concern может быть - нельзя комитить нерабочий код. А все остальное, комить хоть по сто раз на дню, если все тесты проходят, один коммит в день это минимум, если человек вообще на работе делом занят.

Блин какое developer's privacy???, Мой совет, гоните этого девелопера ссаной метлой подальше от кода, кажется мне, что чувак worst team player ever, а за попытку отбулшитить, очень верное на самом деле предложение и из компании тоже.

> What do you think: is trying to commit code at least once per day - too frequent or a good goal?

Попробуйте ТДД или как минимум обязательный юнит тестинг своего нового кода и увидите, как вырастет количество коммитов.
Dennis Gorelikdennisgorelik on February 27th, 2017 08:03 am (UTC)
Можете вкратце описать, какого рода программы вы (и программисты в вашей команде) пишете?

Я спрашиваю, потому что сложность кода бывает разной.
Например, есть программисты, которые правят страницу на Фэйсбуке, а есть программисты, которые пишут framework для Facebook.
Кода первого типа (сами страницы) нужно писать гораздо больше, а кода второго типа (framework) нужно писать гораздо меньше, но он гораздо более ответственнен.
И, соответственно, подходы к написанию кода несколько отличаются:
В простом коде можно сразу писать код и покрывать его тестами.
В сложном - может быть нужно создать несколько прототипов и оставить только хорошо себя зарекомендовавшие.

Поэтому, увы, не всё так однозначно.
Хотя, конечно, больше дня вообще без коммитов - для меня несколько странно.
Dade Murphysnsokolov on February 27th, 2017 04:47 pm (UTC)
Нечто среднее. Новые проекты, инфраструктура, не продакшн.

Но в принципе какая разница? Инкрементальный девелопмент по идее можно делать в какой угодно код, в том же ТДД, там приблизительно каждые 20 минут ваш код commit-ready. Что мешает к концу дня выбрать рандомный passing state и отправить его на ревью и комит?
Dennis Gorelikdennisgorelik on February 27th, 2017 11:14 pm (UTC)
Когда код принципиально новый, а не пишется по отлаженному шаблону, то такой код пишется гораздо медленнее (требуется много новых исследований).
При этом, новый код связывает между собой большое количество новых компонентов.
В результате, первая версия кода пишется довольно сырой и кое-как связывает все эти компоненты в единое целое лишь для того, чтобы по-быстрому проверить, что прототип сконструирован приблизительно правильно.
Этот исследовательский этап может быть довольно долгим (несколько дней).
Разбить такое исследование на отдельные коммиты, конечно, можно. Но будет некоторый overhead (небольшой overhead, если коммиты только раз в день, и большой overhead, если коммиты пытаться делать каждые 20 минут).
Прикрутить тесты тоже можно, но польза от тестов на совершенно сыром прототипе - не очень большая. А время и внимание они отнимают.
Позже, на уже почти готовый код, добавить тесты, конечно нужно.

(no subject) - snsokolov on February 27th, 2017 11:58 pm (UTC) (Expand)