Small Code Commits
Small Code Commits
Join the DZone community and get the full member experience.Join For Free
[Latest Guide] Ship faster because you know more, not because you are rushing. Get actionable insights from 7 million commits and 85,000+ software engineers, to increase your team's velocity. Brought to you in partnership with GitPrime.
If you've got features lasting weeks or months, then adding a single feature is a huge amount of code. When you want a team to add one feature or fix one bug, you use tools like continuous integration to train yourself (and your team) to check in a single feature. But how big are those features?
Recently, I spoke at the Great Lakes Software Symposium in Chicago and an audience member verbalized a great tip about driving the team towards small code commits.
The key to small code commits is small estimates.
My definition of small is between half a day and a week's worth of work. Anything longer than a week probably has a surprise or two hiding in it. You haven't decomposed that feature down far enough and when you encounter this hidden surprise it might blow up in your face. Anything shorter than half a day is too small. And you can't do anything in half a day anyway... try it sometime and see the interruptions appear from out of thin air.
It's simply easier to estimate smaller chunks of work. It also minimizes the code collisions between you and other developers. It makes your integration tests more effective as well. If your integration test covers 150 classes, you need to use small code commits and continuous integration to isolate what code was broken.
So where are you? Still working on figuring out how to estimate? Start with small units of work and be sure to look back and see how you're performing over time. Fast feedback leads to fast fixes. Be sure to work in smaller amounts of work, commit often, and look back over what you've done as often as possible, whether it's your continuous integration system providing the feedback or the estimate errors.
Smaller estimates lead to smaller code changes.
Jared Richardson is a programmer, speaker, author, and trainer. He helps teams build better software through his company Agile Artisans. As a recognized expert in the software industry, he has worked with both startups and software giants. He's a co-author of the best selling book Ship it! A Practical Guide to Successful Software Projects and contributor to the No Fluff Just Stuff Anthology 2006 and 2007 editions. Jared speaks frequently at the No Fluff Just Stuff travelling software symposiums all over the United States and at other software conferences and users groups. Agile Artisans also matches great speakers with companies and conferences.
Published at DZone with permission of Jared Richardson , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.