<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
	<id>https://www.thinkulum.net/w/index.php?action=history&amp;feed=atom&amp;title=Software_Development%2FIterative_and_Incremental_Development</id>
	<title>Software Development/Iterative and Incremental Development - Revision history</title>
	<link rel="self" type="application/atom+xml" href="https://www.thinkulum.net/w/index.php?action=history&amp;feed=atom&amp;title=Software_Development%2FIterative_and_Incremental_Development"/>
	<link rel="alternate" type="text/html" href="https://www.thinkulum.net/w/index.php?title=Software_Development/Iterative_and_Incremental_Development&amp;action=history"/>
	<updated>2026-04-09T12:47:17Z</updated>
	<subtitle>Revision history for this page on the wiki</subtitle>
	<generator>MediaWiki 1.37.1</generator>
	<entry>
		<id>https://www.thinkulum.net/w/index.php?title=Software_Development/Iterative_and_Incremental_Development&amp;diff=374&amp;oldid=prev</id>
		<title>Andy Culbertson: Added the article.</title>
		<link rel="alternate" type="text/html" href="https://www.thinkulum.net/w/index.php?title=Software_Development/Iterative_and_Incremental_Development&amp;diff=374&amp;oldid=prev"/>
		<updated>2019-02-22T04:58:50Z</updated>

		<summary type="html">&lt;p&gt;Added the article.&lt;/p&gt;
&lt;p&gt;&lt;b&gt;New page&lt;/b&gt;&lt;/p&gt;&lt;div&gt;[https://en.wikipedia.org/wiki/Iterative_and_incremental_development Incremental development] is the approach of adding a few features per release rather than developing the whole program at once. It lets users begin using the software earlier, and it lets the feature roadmap change without wasting much development effort on the original design. It's different from iterative development, but they normally go together, so I'm using incremental as shorthand for both.&lt;br /&gt;
&lt;br /&gt;
If you're a developer working on your own, the habit of small, frequent releases also can add accountability to the development process. It'll at least hold you accountable to work on the project, since other people will notice when the releases stop coming. It might even encourage you to code each feature well. A short release cycle does mean there's less time to get the code right, but there's also less time to procrastinate on getting it to work, and if you implement good programming practices, you'll waste less of that time debugging.&lt;br /&gt;
&lt;br /&gt;
Small, frequent releases can also help the developer avoid procrastination, since the tasks for a small release feel more achievable, similar to writing a [http://volokh.com/posts/1182282037.shtml zeroth draft] of a manuscript. There's little concern for polish, so a zeroth draft has fewer requirements to worry about, and therefore it's more likely to get written.&lt;br /&gt;
&lt;br /&gt;
A related practice is to deliberately trim your feature list for each release, captured in the [http://wiki.c2.com/?ExtremeProgramming Extreme Programming] practice [http://wiki.c2.com/?YouArentGonnaNeedIt You Aren't Gonna Need It].&lt;br /&gt;
&lt;br /&gt;
One practice that's helping me think in terms of incremental development is using [http://scottchacon.com/2011/08/31/github-flow.html GitHub flow] as my version control workflow. In GitHub flow the master branch is reserved for deployable code, so anything I'm actively developing goes into a topically named branch off of master. Once the code related to that branch is ready for deployment, I merge that branch back into master. This procedure gets me to plan in terms of small clusters of features. I'll talk more about version control in the next main section.&lt;br /&gt;
&lt;br /&gt;
[[Category:Programming]]&lt;br /&gt;
[[Category:Essays]]&lt;br /&gt;
[[Category:Developing]]&lt;/div&gt;</summary>
		<author><name>Andy Culbertson</name></author>
	</entry>
</feed>