4

During work, i only make commit and push my work to our shared repository at Github, when i consider that I have done my task up to necessary changes which I may realize later. So that means that I don't commit and push my work on a daily basis, but often once in several days.

Generally, is daily commit and push necessary for managers and supervisors to check my progress and productivity? Is it especially true in Agile?

If i commit and push at the end of each day, chances are my work is paused at the middle of something. What shall I write in the comment of the commit? I feel that I can write something in the comment only when I have completed some task up to some future changes realized later.

Thanks.

Update

I am working on my own feature branch, so i only push to my feature branch at Github. When my work is ready on my feature branch to be merged into the master branch, i will create a pull request to the person who has the ability to merge.

Tim
  • 5,405
  • 7
  • 48
  • 84
  • 9
    So what happens if you spend a week on a particularly difficult bit of code and your hard drive crashes right before you commit? – Dan Pichelman Apr 06 '17 at 16:26
  • 2
    Possible duplicate of [When to commit code?](http://softwareengineering.stackexchange.com/questions/83837/when-to-commit-code) – gnat Apr 06 '17 at 16:26
  • 2
    @gnat: This is not a duplicate, due to the "management" factor. It does change things. – Greg Burghardt Apr 06 '17 at 16:41
  • Is this an actually problem, or a hypothetical one? You don't say if management is already complaining about your sparse commits. – FrustratedWithFormsDesigner Apr 06 '17 at 16:54
  • 1
    @DanPichelman: I think I'd open my backup app, pull the most recent stuff from my provider and lose maybe the last 20 minutes' worth of work. 'Cause we all back our stuff up, right? ;-) – Blrfl Apr 06 '17 at 18:12
  • @Blrfl: You would, I would, but I'm sure we've both seen companies that do not back up desktops :-) – Dan Pichelman Apr 06 '17 at 18:17
  • 2
    @GregBurghardt when it comes to code version control any "management" factor becomes totally negligible compared to convenience of developers. Using VCS for anything other than making developers most productive (as discussed in duplicate question) is a serious abuse. If management finds that natural flow of commits doesn't suffice to make them feel good they need to find _other_ ways to communicate progress (as one of most popular examples I've seen daily updates to issue tracker do the job, and I've seen other ways that don't misuse development tool for managerial communication) – gnat Apr 06 '17 at 20:09
  • @gnat: Yup. I completely agree, but that doesn't make it a duplicate question. The other question did not have the management factor in it. – Greg Burghardt Apr 06 '17 at 20:29
  • 1
    Because you used the word "necessary", the answer is clearly an unqualified "no". There are good reasons to check in your code early and often, but as a necessary step for management? Nope. – Bryan Oakley Apr 07 '17 at 03:29

6 Answers6

15

It should not be necessary for you to commit daily just to assure your managers that you are working. If management can't tell how you're doing without looking at your commit history, then I would argue they are not very good at management. Maybe one step above counting LOC to see how good a worker you are. If management engages in closely monitoring your commit history, that feels like a really annoying (and time-wasting) form of micromanagement.

Management should be more concerned with whether or not your features are completed on time, and if they work as per the specs.

What you didn't actually state in your question: Does your manager(s) actually complain that you are not making enough commits?

All that aside, I commit several times per day. When my code is in a good state that I want to preserve, I commit and push, and on a good day, this happens several times per day. But the details of this are a completely different discussion than the one you asked about.

FrustratedWithFormsDesigner
  • 46,105
  • 7
  • 126
  • 176
  • I also like this answer "Perception is reality" http://softwareengineering.stackexchange.com/a/138407/91219 – Karan Apr 07 '17 at 10:24
5

Generally, is daily commit and push necessary for managers and supervisors to check my progress and productivity? Is it especially true in Agile?

Well, it's good practice to commit code at least once a day, to ensure you're not keeping hours of valuable work hostage on your workstation!

But, for "true agile?" No.

For managers to "check your progress?" Not really. A better check of progress and work ethic is velocity over time and 1-to-1 dialogues.

That said, we don't know your team dynamic. And, one of the most basic principles of "Agile" development is, "do what works for you." Your team needs to discuss these policies internally (with your manager) to determine why or if this procedure is helpful.

And from my own experience as both a developer and a manager, regular checkins aren't necessarily a product of an overbearing manager. They can also be a sign of a manager (or team) who's actually interested in your work or wellbeing. Or a manager who's interested in not losing days of your work if you get his by a bus ...

I should also note, from my experience on both ends, that when someone — myself included — isn't making regular pushes, they've usually "checked out." That is, they're not actually working. And more importantly, they've stopped caring.

So, as long as you're actually doing work, and as long as writing code is a daily responsibility of yours, you shouldn't be afraid to push code every day. If you find that difficult, you might be in the wrong job! And, that's something both your manager and you should want to see the early signs of!

And I mean that seriously. When I'm in development mode on a project, if I get to the end of the day and can't push my code, it's never because my code doesn't compile or I'm embarrassed. It's because I didn't work. ... So, I either walk up to someone at the office and make a commitment to them1, which a great motivator, or I start looking for another job. (Or both.)

1. That is, I walk up to a stakeholder or my manager and say, "Hey, I'd like you to review my work at the end of the day tomorrow." And to be perfectly honest, after a few days of this routine, I usually stop looking for another job, because I'm engaged again. I care again, because I'm no longer working for a vague corporate entity. I'm serving my coworkers.

svidgen
  • 13,414
  • 2
  • 34
  • 60
  • 1
    "But, for "true agile?" No." How do you do "true agile" if you're not doing continuous integration? – Rob Crawford Apr 07 '17 at 14:58
  • "Well, it's good practice to commit code at least once a day, to ensure you're not keeping hours of valuable work hostage on your workstation!": The git (or mercurial or whatever) repository is not a backup facility! To make backups you can use an external disk or a network drive. But please, do not fill the change history with microcommits that in six months from now you won't be able to understand. The change history in the repository should only contain meaningful changes that introduce new features of fix bugs. They are not the daily log of each programmer's activities. – Giorgio Apr 07 '17 at 15:13
  • @Giorgio If you wrote code *today*, putting it someplace your team can see it *today* isn't "backup" ... And, if you're branching and merging properly, your "micro-commits" really won't bother anyone. – svidgen Apr 07 '17 at 15:41
  • 1
    @RobCrawford I sincerely hope you're joking. ... While I'd advocate very strongly for CI, it is by no means *necessary* in Agile development. – svidgen Apr 07 '17 at 15:42
  • @svidgen - that's a matter of opinion. I'll point out that a lot of us who've been doing Agile since before the current Scrum craze consider XP the best process, and CI is a core practice in XP. – Jules Apr 08 '17 at 06:56
  • @jules if it's a matter of opinion, it is necessarily not a necessary element. – svidgen Apr 08 '17 at 13:42
  • Unmerged code is risk, and risk reduces your agility. You want to be agile, you commit early and commit often. – Rob Crawford Apr 14 '17 at 13:17
  • 1
    @RobCrawford Unmerged code is risk regardless of whether you're "agile." – svidgen Apr 14 '17 at 13:37
2

Generally, is daily commit and push necessary for managers and supervisors to check my progress and productivity? Is it especially true in Agile?

No. Absolutely not (see When to commit code? and Is committing/checking in code everyday a good practice?). This is what your daily Scrum/stand up is for. They should also be looking at daily burndown charts. Look at past sprints to gauge the velocity of the team. If management needs more proof that you are working, then they need to either:

  1. Come to or dial in to your daily Scrum or stand up

  2. Actually come down to where the developers are and walk around

  3. Ban telecommuting (as unpopular as that would be)

  4. All of the above

I think the real question is: why do managers need a constant stream of code changes in order to believe developers are doing something?

But that's a separate question: How can I demonstrate my productivity to management?

Community
  • 1
Greg Burghardt
  • 34,276
  • 8
  • 63
  • 114
  • 2
    Uhh ... wait. What? ... Why is this getting upvoted like crazy!? Progress checks are *not* what stand-up is for. Stand-up is a catalyst for communication and identifying and removing blockers! ... Secondly, how can you pretend to know this guy's team dynamic? ... Maybe, on his team, it *is* necessary to perform daily pushes, because the team is struggling to stay focused! – svidgen Apr 06 '17 at 16:59
  • @svidgen: Developers use Scrum as a means for communication. Take a wild guess what managers like to use Scrum for? Progress checks. Theory meets reality here. Scrum *is* a form of progress check, even if you don't here scrum updates like "I am 53% done with Story X". You hear things like "Working on Story X. Blocked by Y". That's some form of a progress update -- someone is blocked. Management should step in. As for the current team dynamic? It sounds like it needs to change. And daily pushes don't necessarily keep people focused at all. – Greg Burghardt Apr 06 '17 at 17:02
  • Or, maybe it's just a really boring project, and the manager understands, from personal experience being a work-horse, that it's easier to stay focused when someone is actually interested in your work ... There's a personal investment involved, which, some projects don't *inherently* offer... – svidgen Apr 06 '17 at 17:06
  • 1
    @svidgen: I had a coworker tell me once to "love the code, not the application." The subject matter of the application might not be the most exciting thing in the world, but that doesn't mean engineers shouldn't find joy in writing the code. It's all in what you find enjoyable. Now let's just hope the problems brought up by the litany of expense reports and basic CRUD applications we must deal with are interesting problems... – Greg Burghardt Apr 06 '17 at 17:09
  • I'm not sure what your point is! But, all I'm saying is, I've been on both ends of the motivation problem. And, I know from experience motivating folks and trying to stay motivated myself, that the *biggest* motivator is knowing that you're doing your work *for another person.* ... This guy's manager is *probably* not offering that motivational service. But, asking for daily pushes could, *on some teams*, be part of that strategy. – svidgen Apr 06 '17 at 17:11
  • 3
    I up-voted this not because I think the daily stand-up's purpose is to provide a progress update to the manager, but because the conversations in the stand-up should be enough to satisfy the manager's needs. If meaningful daily conversations are taking place, then there should be no need for a daily "commit and push". If there are other reasons for requiring daily commits, then so be it. But not for progress checks. – Eric King Apr 06 '17 at 17:42
  • 1
    @EricKing I dunno. I don't know that I agree. Having been on both sides, it can easy to deceive oneself into thinking a task is way more complicated than it really is ... and to say, day after day, "Oh, I'm still working on X. It's a real thinker." ... Well, OK. If it's *really* a thinker, you should either be committing experimental code or producing diagrams or having conversations with people, any of which a manager can use as a sign of life that a standup can't really provide. I've seen way too many folks overstate complexity for a week ... and then commit a few simple lines on Friday. – svidgen Apr 06 '17 at 17:50
  • 2
    This is an incorrect statement: _"This is what your daily Scrum/stand up is for"_. The daily scrum is for team members to sync up. It is not in the slightest to be a tool to keep management in the loop. Management can look at burndown charts and the story board and speak with the scrum master and team members, but the daily scrum should be for developers only. – Bryan Oakley Apr 07 '17 at 03:30
  • Downvoted for the suggestion that telecommuting has any effect whatsoever on a manger's ability to judge whether programmers are working. – Kevin Krumwiede Apr 07 '17 at 04:44
1

One thing I would note is that if your manager is telling you that daily commits are necessary, then they are necessary regardless of how you personally feel about it.

Another circumstance not noted in the other answers, which is particularly relevant these days, is when you are working remotely. If you are working remotely, your manager can't swing by your desk to check on your status and make sure you are actually working. They might be able to ping you on Slack and you might still have weekly meetings on Skype/Zoom/whatever, but that doesn't give the full picture. Are you actually at your desk for all of the hours you say you're working? Are you actually writing code, or are you browsing the internet or playing video games?

Unfinished work can always be committed to topic branches which are understood to be a WIP. You can always squash commits later.

Kevin
  • 111
  • 2
0

You could ask the same question of any process. Is it Necessary to:

  • use jira tickets to track features
  • attend the daily standup
  • estimate tasks in terms of story points

No! not if you are doing it some other way.

Not checking in code at least once a day is unusual.

Doing so will give your managers lots of nice graphs and show that you have at least done some typing that day.

Git doesn't punish you for checking in non functional code. You can use local branches, tags, rebases (urg) etc to manage your personal preference, but theres no reason not to check code in if it makes your boss happy

Ewan
  • 70,664
  • 5
  • 76
  • 161
0

If it's not clear for you yet you should be asking your manager/mentor or other team members what is your team's mode of operation (in the commit rate sense) and you should align with it.

Advice from other answers may be good if the team works like that or bad if the team doesn't.

For example:

  • if the team is working on a branch shared with many/all other teams working on the same product (true CI) it may be more important to integrate smaller pieces faster to minimize the chances of merge conflicts which would force you to re-evaluate and re-verify your changes, maybe repeatedly. Committing a function skeleton first and following up with one of more meat-adding commits would be preferred, as long as you don't break other stuff, even if your stuff isn't yet functioning. Of course, if such partial functionality commits are accepted (and they probably would be in such dynamic environment).

  • if the team works in an environment where each commit is expected to be fully reviewed, verified and functional then obviously you'll have to follow that trend, partial commits would not be an answer. Not very agile IMHO, but still quite common in many organisations.

And you should ask your manager what is the method for checking and reporting progress for your organisation. That might actually be unrelated to the number/rate of commits (IMHO that'd be a mistake). For example tons of trivial cosmetic commits aren't necessarily "more progress" than a single infrastructure performance-enhancing commit (which might even be a lot smaller, too).

Dan Cornilescu
  • 869
  • 7
  • 14