1

I believe that agile works if everything is agile.

In software development area, in my opinion, if team members' code is integrated early, code will be more in sync and this has a lot of pros:

  • Early integration helps team members to avoid painful merges.
  • Encourages better coding habits, because everyone makes sure that they don't break co-workers' code everyday.
  • Both developers and architects (code reviewers) may detect bad design decisions or just wrong development directions in real-time, preventing useless work.

Actually I'm talking about getting the latest version of code base and checking-in your own code to the source control in a daily basis.

When you start your coding day (i.e. you arrive to your work), your first action is updating your code base with the latest version from the source control. In the other hand, when you're about an hour to leave from your work and go home, your last action is checking-in your code to the source control and be sure that your day work doesn't break the project's build process.

Rather than updating and checking-in your code once you finished an entire task, I believe the best approach is fixing small and flexible personal milestones and checking-in the code once you finish one of these.

I really believe that this coding approach fits better in the agile project management concept.

Do you know some document, blog post, wiki, article or whatever that you can suggest me that could be in sync with my opinion?. And, do you find any problem working with this approach?.

Thank you in advance.

Improve this question
2
  • What problem are you trying to solve? Are you currently using the first method you described? If you are, are you running into problems with it? What kinds of problems? If you aren't experiencing problems with your current workflow, why are you trying to change it? It doesn't make sense to introduce a change in a working process unless you want to improve some aspect of it - what aspect are you trying to ultimately improve?
    – Thomas Owens ♦
    Commented Nov 23, 2012 at 20:36
  • @ThomasOwens I'm asking this because I have a different point of view compared to my team colleagues. They prefer "task finished, update, solve problems, finally check-in". I don't like this approach because I prefer early integration as I said my question.
    – Matías Fidemraizer
    Commented Nov 23, 2012 at 21:03

2 Answers 2

Reset to default
2

And, do you find any problem working with this approach?

I'm going to focus on this particular point.

I do have problems with this approach, largely because it is kinda orthogonal to what people should be doing. Sure, we should promote more frequent 'get latest's and commits but aligning those with the workday is in poor alignment with what we're actually looking to solve and how development will usually work.

Programmers should get latest before they start a task, and before they commit code for a task. These are the two natural points to do merges for developers. If developers aren't doing this, then it's pretty straight-forward to correct that. "Hey, you should get latest to prevent breaking the build and merge pain." Developers like reducing development pain.

If that somehow leads to integration less frequently than daily, then you've worse problems than infrequent integration. You have very large tasks. These will inherently be more error prone, and lead to more merge issues overall; regardless of your integration frequency. You should be looking to cut down on the common task size into more manageable chunks. This will cut down far more on your integration pain (and other development issues like estimation error, coordination problems, time/issue tracking accuracy, etc) than dictating that people merge even if they're not in a good spot for it.

Improve this answer
10
  • I like your opinion (+1). I'm agree about you need to be flexible in terms of check-in daily if it's possible. But when I say "daily" I'm trying to say "this is the rule" but "use it with common sense". You know.
    – Matías Fidemraizer
    Commented Nov 23, 2012 at 21:07
  • @MatíasFidemraizer - I do, but if it's enough of a problem to require the rule, there's probably some root cause that would be better to fix.
    – Telastyn
    Commented Nov 23, 2012 at 21:08
  • In the other hand, when you say that less frequency than daily is worse than infrequent integration, you're right. But anyway, again, we need to do things with common sense. I prefer to get latest version during the same day as times as some colleague says "I checked-in an interesting/requires/important feature/fix/whatever", instead of use the fixed rule of "I'll get the latest version after each milestone". At the end of the day, what kind of milestone is a one that works in your computer but it can't be integrated with others' code?
    – Matías Fidemraizer
    Commented Nov 23, 2012 at 21:09
  • "Programmers should get latest before they start a task, and before they commit code for a task" - WHY ??? I wrote code, based on old codebase, I have functioning code, I save it and only after it I'll merge it with latest changes - not the easiest way, but it have rights to live
    – Lazy Badger
    Commented Nov 23, 2012 at 22:22
  • @LazyBadger When I did my first reading of your comment I thought "poor code......" ;) Well, why? Because team doesn't care about you having a working code in an obsolete code base. This isn't a finished task. Finishing the task is having your code well integrated with others' tasks. Do you have any guarantee so your code will compile in the most up-to-date code base? And what's most important: if compiles, what about tests? Your code compiles but you broke a lot of tests. A task will be done when it compiles and passes all tests.
    – Matías Fidemraizer
    Commented Nov 23, 2012 at 22:33
0

Well, I see your Pro-list as rather weak list of "advantages"

Early integration helps team members to avoid painful merges

Painful merges are both types: or they do not exist yet or have been here already. Conflict (fact of this action) produces disorder, not the amount of actions before it

Encourages better coding habits, because everyone makes sure that they don't break co-workers' code everyday

If merging of coworker's code into my working codebase destroy build, it's not my fault, sorry! This is also true in the opposite direction of merging

Both developers and architects (code reviewers) may detect bad design decisions or just wrong development directions in real-time, preventing useless work.

If I saw this style of work in my team (control only merged code), PM and TL will be immediately dismissed with the black mark

I'm talking about getting the latest version of code base and checking-in your own code to the source control in a daily basis

"It depends" (c):

  • If nobody touches "my" files, I (can) don't worry about unrelated code-changes
  • If I close a lot of small related with other tasks, I'll prefer merge changes as fast as possible
Improve this answer
4
  • @LazyBadget About the "it's not my fault, sorry": you're right. When one breaks the build, what about buying some cookies for the rest of the team? It's other's fault, not yours. And if your build is broken because you got the latest code and produces problems in your local code, I don't find the problem. What's the advantage of having a "future broken code" not broken for now?
    – Matías Fidemraizer
    Commented Nov 23, 2012 at 22:36
  • @MatíasFidemraizer - "When one breaks the build, what about buying some cookies for the rest of the team?" - I hate this yankee-games: Errare humanum est! "What's the advantage of having a "future broken code" not broken for now?" - Let's solve problems as they arise, Merge conflicts are problems of merge time, code disfunction are problems of integration time. Agile is just method and toolset, not god
    – Lazy Badger
    Commented Nov 24, 2012 at 0:05
  • @LazyBadget hahaha, well it's a valid opinion, but your hate doesn't convert an opinion into the truth. In second place, for me, the fact that I'm building code on top of a non-existent, refactored, different code is the same as doing nothing. Imagine that you're building your solution based on an approach that has been deprecated during last 3 days, or you had to workaround something because some approach didn't work in your situation. Because getting the latest version breaks your build, you stay with your useless solution?
    – Matías Fidemraizer
    Commented Nov 24, 2012 at 8:10
  • @MatíasFidemraizer - 3 days of pure development + 1 day of integration < 3 + 3 (at least) of parallel work (50% of speed degradation in task-switching is good result). But "non-fundamental changes" have to be integrated ASAP
    – Lazy Badger
    Commented Nov 24, 2012 at 9:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.