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.
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.
10
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
4