Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
    
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 Nov 23 '12 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 Nov 23 '12 at 21:03
add comment

2 Answers

up vote 1 down vote accepted

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.

share|improve this answer
    
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 Nov 23 '12 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 Nov 23 '12 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 Nov 23 '12 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 Nov 23 '12 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 Nov 23 '12 at 22:33
show 5 more comments

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
share|improve this answer
    
@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 Nov 23 '12 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 Nov 24 '12 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 Nov 24 '12 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 Nov 24 '12 at 9:42
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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