tag:blogger.com,1999:blog-7533727264507128560.post1953682981750235039..comments2024-03-12T23:38:00.147-07:00Comments on Lessons Learned: Work in small batchesErichttp://www.blogger.com/profile/12249063135381216090noreply@blogger.comBlogger11125tag:blogger.com,1999:blog-7533727264507128560.post-82532258423287174672009-06-15T18:06:18.945-07:002009-06-15T18:06:18.945-07:00This comment has been removed by the author.Damon Edwardshttps://www.blogger.com/profile/08075446611632722802noreply@blogger.comtag:blogger.com,1999:blog-7533727264507128560.post-85405889766629427912009-03-06T07:28:00.000-08:002009-03-06T07:28:00.000-08:00However, a technological solution can't necessaril...However, a technological solution can't necessarily resolve all human root causes. <BR/><BR/>So, we have a system that disallows commits to broken branches. That doesn't prevent an engineer from breaking a branch, going home and leaving the mess for someone else to fix.<BR/><BR/>If peer pressure doesn't work then it looks like a management problem. And I'm afraid those can only be solved by managers who are willing to solve them.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7533727264507128560.post-1804002329234345982009-03-05T22:05:00.000-08:002009-03-05T22:05:00.000-08:00@Anonymous - appreciate the thoughtful comment. I ...@Anonymous - appreciate the thoughtful comment. I think what you've described is a common approach to getting quality (or other) problems under control: increase batch size, increase audits and other controls.<BR/><BR/>But I think this is the wrong approach. The key to maintaining small batches is to ensure that the team works only as fast as it can reliably produce quality work, and no faster. <BR/><BR/>So, for example, I would not allow anyone to commit to a broken trunk (or any other branch). Take a look at:<BR/><BR/>http://startuplessonslearned.blogspot.com/2008/12/continuous-integration-step-by-step.html<BR/><BR/>for a suggestion for how to implement this. Even if you have untrained, undisciplined engineers, you can create a system that incrementally, over time, addresses those root causes.Erichttps://www.blogger.com/profile/12249063135381216090noreply@blogger.comtag:blogger.com,1999:blog-7533727264507128560.post-25021974116964134742009-03-05T21:39:00.000-08:002009-03-05T21:39:00.000-08:00Small is beautiful. However, consider a situation ...Small is beautiful. <BR/><BR/>However, consider a situation where a team has many inexperienced/careless engineers who commit modifications in small batches...but unfortunately a very large percentage of those batches keep breaking the continuous build. <BR/><BR/>So now trunk branch is broken almost all the time and progress is difficult because either you have to commit to an already broken tree (so you don't what else you might break) or you have to wait for it to get fixed...which might take a while because naturally the fixes tend to break something else.<BR/><BR/>So now the organization decides that small batches are bad and two things happen:<BR/><BR/>1. Modifications are gathered into large infrequent batches. Weeks/months of boredom are broken by blood-curling terror when the Big Batch lands.<BR/><BR/>2. Everybody stops using trunk and squirrels their work away in private branches. Trunk is desiccated and all the cool action is somewhere else...if you only knew where. <BR/><BR/>So what's a small batch advocate to do? <BR/><BR/>I think small batch advocacy contains implicit assumptions (reasonable level of skill/discipline, desire to avoid breaking the build, desire to fix the build when it's broken) that may not be widely shared in an organization. And then it can get ugly.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7533727264507128560.post-16400453495110577672009-02-25T20:12:00.000-08:002009-02-25T20:12:00.000-08:00Small batches also help deliver value earlier in t...Small batches also help deliver value earlier in the project. If you can start getting ROI on a feature in month one of a twelve month project versus waiting until the end, you've comparatively reduced the cost of development by the revenue generated by that feature over 11 months.Matt McKnighthttps://www.blogger.com/profile/16098483018096096360noreply@blogger.comtag:blogger.com,1999:blog-7533727264507128560.post-15853480988146988432009-02-23T10:19:00.000-08:002009-02-23T10:19:00.000-08:00So how many releases per year would you recommend?...So how many releases per year would you recommend?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7533727264507128560.post-61552069623853466462009-02-21T16:10:00.000-08:002009-02-21T16:10:00.000-08:00Good analysis. Game development in general has wo...Good analysis. Game development in general has worked this way for at least a decade, if not two. Junior developers tend to take a more traditional approach and have to be coached into following this line of thinking. The only disadvantage that comes to mind is the potential bottleneck of submission reviews, when that is deemed necessary.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7533727264507128560.post-76704677330249794802009-02-21T15:08:00.000-08:002009-02-21T15:08:00.000-08:00Sounds very similar to agile development which is ...Sounds very similar to agile development which is the way. Short iterations, quick commits (some harmful) but at least it's alive, moving, and nobody's losing interest.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7533727264507128560.post-73558838140207778412009-02-21T12:26:00.000-08:002009-02-21T12:26:00.000-08:00I'm a huge fan of small batches as well. This is a...I'm a huge fan of small batches as well. This is a fantastic article.John Rockefellerhttps://www.blogger.com/profile/15521060955974077373noreply@blogger.comtag:blogger.com,1999:blog-7533727264507128560.post-79122842122766274832009-02-21T07:39:00.000-08:002009-02-21T07:39:00.000-08:00No doubt about it, small batches are the way to go...No doubt about it, small batches are the way to go<BR/><BR/>RT<BR/>www.anonymity.eu.tcHarold Fowlerhttps://www.blogger.com/profile/08018983019271676117noreply@blogger.comtag:blogger.com,1999:blog-7533727264507128560.post-48247880972310455832009-02-21T00:10:00.000-08:002009-02-21T00:10:00.000-08:00Interesting post. As a developer I find that forci...Interesting post. As a developer I find that forcing myself to work in small batches allows me to solve the problem quicker by avoiding the analysis paralysis. Each time I encounter a complex task I immediately force myself to think what are the independent small steps I can take to finish it. I try to keep each step solvable under 1-2 hours.Peter Severinhttps://www.blogger.com/profile/17671104297412097653noreply@blogger.com