?

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)
(no subject) - dennisgorelik on February 26th, 2017 10:56 am (UTC) (Expand)
(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.
Re: Code privacy - lamantyn on February 27th, 2017 05:32 am (UTC) (Expand)
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.
(no subject) - lamantyn on February 27th, 2017 06:03 am (UTC) (Expand)
(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)
> лучше личной встречи ничего не придумать

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

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

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

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

Зачем делать ошибки приватными?
Почему бы их не обсудить в команде?
Команда может подсказать неожиданное решение или, наоборот, научиться из уже сделанных ошибок.
(no subject) - mam6a on February 27th, 2017 12:20 pm (UTC) (Expand)
(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.
(no subject) - yatur on February 27th, 2017 05:52 am (UTC) (Expand)
(no subject) - dennisgorelik on February 27th, 2017 06:17 am (UTC) (Expand)
(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).
(no subject) - yatur on February 27th, 2017 06:15 am (UTC) (Expand)
(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)
(no subject) - lodin on February 27th, 2017 06:47 am (UTC) (Expand)
(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) нужно писать гораздо меньше, но он гораздо более ответственнен.
И, соответственно, подходы к написанию кода несколько отличаются:
В простом коде можно сразу писать код и покрывать его тестами.
В сложном - может быть нужно создать несколько прототипов и оставить только хорошо себя зарекомендовавшие.

Поэтому, увы, не всё так однозначно.
Хотя, конечно, больше дня вообще без коммитов - для меня несколько странно.
(no subject) - snsokolov on February 27th, 2017 04:47 pm (UTC) (Expand)
(no subject) - dennisgorelik on February 27th, 2017 11:14 pm (UTC) (Expand)
(no subject) - snsokolov on February 27th, 2017 11:58 pm (UTC) (Expand)