Comments on: Maybe Software Development IS Like Building a House http://ntschutta.com/jat/2008/02/05/maybe-software-development-is-like-building-a-house/ Just A Thought...on Ajax, usability, software development and anything else that catches my fancy. Mon, 06 Oct 2008 19:36:21 +0000 http://wordpress.org/?v=2.3.1 By: ntschutta.com » Blog Archive » Dateility http://ntschutta.com/jat/2008/02/05/maybe-software-development-is-like-building-a-house/#comment-64415 ntschutta.com » Blog Archive » Dateility Thu, 03 Jul 2008 01:51:37 +0000 http://ntschutta.com/jat/2008/02/05/maybe-software-development-is-like-building-a-house/#comment-64415 [...] a little time, but odds are we’ve cost ourselves significantly more in the long run. When building a house or a bridge, the consequences of shortened schedules are easy to see; with software, it’s [...] […] a little time, but odds are we’ve cost ourselves significantly more in the long run. When building a house or a bridge, the consequences of shortened schedules are easy to see; with software, it’s […]

]]> By: ntschutta.com » Blog Archive » Silver Bullets http://ntschutta.com/jat/2008/02/05/maybe-software-development-is-like-building-a-house/#comment-57291 ntschutta.com » Blog Archive » Silver Bullets Sun, 10 Feb 2008 20:28:03 +0000 http://ntschutta.com/jat/2008/02/05/maybe-software-development-is-like-building-a-house/#comment-57291 [...] ntschutta.com Just A Thought…on Ajax, usability, software development and anything else that catches my fancy. « Maybe Software Development IS Like Building a House [...] […] ntschutta.com Just A Thought…on Ajax, usability, software development and anything else that catches my fancy. « Maybe Software Development IS Like Building a House […]

]]> By: Nate http://ntschutta.com/jat/2008/02/05/maybe-software-development-is-like-building-a-house/#comment-57289 Nate Sun, 10 Feb 2008 20:21:02 +0000 http://ntschutta.com/jat/2008/02/05/maybe-software-development-is-like-building-a-house/#comment-57289 Dave, Sorry I stole your topic ;) it wasn't deliberate! I sure hope you jump into the fray - the blogosphere can sure use more reasoned voices. I think those that abuse the construction analogy underestimate just how much "guess work" there really is in building a house (or any custom structure.) As you state, there's the overall architecture but when push comes to shove, the craftsmen have to make a lot of decisions...just like those of us building software. Gee, there's more to this than I thought! Boston was great - a short trip with a VERY early wakeup call but I had a blast. Thanks for your comments! Dave,

Sorry I stole your topic ;) it wasn’t deliberate! I sure hope you jump into the fray - the blogosphere can sure use more reasoned voices. I think those that abuse the construction analogy underestimate just how much “guess work” there really is in building a house (or any custom structure.) As you state, there’s the overall architecture but when push comes to shove, the craftsmen have to make a lot of decisions…just like those of us building software. Gee, there’s more to this than I thought!

Boston was great - a short trip with a VERY early wakeup call but I had a blast. Thanks for your comments!

]]> By: Nate http://ntschutta.com/jat/2008/02/05/maybe-software-development-is-like-building-a-house/#comment-57288 Nate Sun, 10 Feb 2008 20:00:45 +0000 http://ntschutta.com/jat/2008/02/05/maybe-software-development-is-like-building-a-house/#comment-57288 Pete, Thanks for the insightful comment - you've hit on some key issues there. I've seen so many projects fail because they didn't deliver that business value early...they just spun on and on. Your point about risks resonates as well - it amazes me that customers and managers continue to cling to what is arguably a much riskier approach to developing software (and one that has a very poor track record of success I might add.) BTW, are you, by chance, the Pete named in <a href="http://media.pragprog.com/articles/sep_04_imaginate.pdf" rel="nofollow">Imaginate</a>? Pete,

Thanks for the insightful comment - you’ve hit on some key issues there. I’ve seen so many projects fail because they didn’t deliver that business value early…they just spun on and on. Your point about risks resonates as well - it amazes me that customers and managers continue to cling to what is arguably a much riskier approach to developing software (and one that has a very poor track record of success I might add.) BTW, are you, by chance, the Pete named in Imaginate?

]]> By: Here’s how you find something interesting « Dryland’s Note http://ntschutta.com/jat/2008/02/05/maybe-software-development-is-like-building-a-house/#comment-57215 Here’s how you find something interesting « Dryland’s Note Fri, 08 Feb 2008 19:04:56 +0000 http://ntschutta.com/jat/2008/02/05/maybe-software-development-is-like-building-a-house/#comment-57215 [...] Raganwald links for 02-05 —-> Maybe Software Development IS Like Building a House [...] […] Raganwald links for 02-05 —-> Maybe Software Development IS Like Building a House […]

]]> By: Dave Klein http://ntschutta.com/jat/2008/02/05/maybe-software-development-is-like-building-a-house/#comment-57153 Dave Klein Wed, 06 Feb 2008 22:18:40 +0000 http://ntschutta.com/jat/2008/02/05/maybe-software-development-is-like-building-a-house/#comment-57153 Don’t doubt yourself. I think the construction analogy is still appropriate and sometimes even helpful. It’s the engineering analogy that has always been misplaced and troublesome, in my opinion. The example you give is, I believe, the best one for most software development projects. The building of a custom house (or other building) is an excellent analogy to a custom software project. There are engineering principles involved, but you wouldn’t refer to your average home builder as an “engineer”. There are pre-built components that can be used. There is an overall architecture. There is a more detailed design. The construction process uses engineering principles and standardized tools to implement that detailed design while staying within the boundaries set out by the architecture. Most of the work that is done while building a home is the same as the work that was done for the last one, but the outcome is unique and the problems that arise are also. Then there is your point. Home construction, just like software, can be done following an agile or waterfall methodology. Obviously, home construction can’t be quite as agile as software. As Neal points out the manufacturing costs of software are much lower which means the cost of change is lower. But the principles are still the same. The cost of change increases the later the change is made. How much more would it have cost if you didn’t catch that plumber in time? Rapid feedback and flexibility are just as valuable in home construction as they are in software development. So, I agree with you 100% but I am miffed at you for posting this. Just yesterday I was thinking of finally getting into this blogging thing (realizing that in our industry if you don’t blog you don’t exist) and I was going to write about this in my very first post. Now I’m going to have to wait until I get another interesting thought. Who knows how long that will be? Anyhow, great post. Have a good time in Boston. Dave Don’t doubt yourself. I think the construction analogy is still appropriate and sometimes even helpful. It’s the engineering analogy that has always been misplaced and troublesome, in my opinion. The example you give is, I believe, the best one for most software development projects. The building of a custom house (or other building) is an excellent analogy to a custom software project. There are engineering principles involved, but you wouldn’t refer to your average home builder as an “engineer”. There are pre-built components that can be used. There is an overall architecture. There is a more detailed design. The construction process uses engineering principles and standardized tools to implement that detailed design while staying within the boundaries set out by the architecture. Most of the work that is done while building a home is the same as the work that was done for the last one, but the outcome is unique and the problems that arise are also.

Then there is your point. Home construction, just like software, can be done following an agile or waterfall methodology. Obviously, home construction can’t be quite as agile as software. As Neal points out the manufacturing costs of software are much lower which means the cost of change is lower. But the principles are still the same. The cost of change increases the later the change is made. How much more would it have cost if you didn’t catch that plumber in time? Rapid feedback and flexibility are just as valuable in home construction as they are in software development.

So, I agree with you 100% but I am miffed at you for posting this. Just yesterday I was thinking of finally getting into this blogging thing (realizing that in our industry if you don’t blog you don’t exist) and I was going to write about this in my very first post. Now I’m going to have to wait until I get another interesting thought. Who knows how long that will be?

Anyhow, great post. Have a good time in Boston.

Dave

]]> By: Pages tagged "acceptance" http://ntschutta.com/jat/2008/02/05/maybe-software-development-is-like-building-a-house/#comment-57114 Pages tagged "acceptance" Wed, 06 Feb 2008 06:22:38 +0000 http://ntschutta.com/jat/2008/02/05/maybe-software-development-is-like-building-a-house/#comment-57114 [...] bookmarks tagged acceptance Maybe Software Development IS Like Building a Hous... saved by 5 others     ZombiesAteMyParents bookmarked on 02/06/08 | [...] […] bookmarks tagged acceptance Maybe Software Development IS Like Building a Hous… saved by 5 others     ZombiesAteMyParents bookmarked on 02/06/08 | […]

]]> By: Pete Ruth http://ntschutta.com/jat/2008/02/05/maybe-software-development-is-like-building-a-house/#comment-57111 Pete Ruth Wed, 06 Feb 2008 05:22:16 +0000 http://ntschutta.com/jat/2008/02/05/maybe-software-development-is-like-building-a-house/#comment-57111 Great post. I started building software like contractors build homes in 1972, using a general-purpose system framework and customizable reusable components and a collaborative process very similar to today's agile methods and incremental/iterational processes. That approach evolved into a generative component-based development process in about 1978, and I've been using it ever since. This combination of approaches affords a great deal of flexibility in terms the development process, and estimating the associated project cost and schedule. This enables working software to be built and reviewed in near real-time. The basic premise is to do the most challenging or important stuff first, transfer the most business value to the users as quickly as possible and identify problems as early as possible to mimimize costs. The generative part produces 75-90% of the total system code automatically; the rest is related to the code that differentiates one application from another, or modifications to the existing components to satisfy unique module requirements. The key to this approach is the degree of "granularity" of the component templates: too fine, and keeping track of everything becomes increasingly difficult as the application grows, too coarse and the number of modifications to generated components increases. Another benefit of the generative process is that multiple approaches to building the application may be explored in parallel with little risk. Modularization at this level enables specific functionality to be "localized", yielding substantial post-deployment benefits, like improved sustainabilily and extendability. (Some of the systems built this way have outlasted the platforms on which they were implemented several times over). These factors may provide extremely good TCO figures. The bottom line is this: being able to create bullet-proof custom applications in a fraction of the time and cost of other methods means that that risks typically associated with software development are substantially reduced, and payback comes much earlier. Thanks again for an interesting post. Great post. I started building software like contractors build homes in 1972, using a general-purpose system framework and customizable reusable components and a collaborative process very similar to today’s agile methods and incremental/iterational processes. That approach evolved into a generative component-based development process in about 1978, and I’ve been using it ever since. This combination of approaches affords a great deal of flexibility in terms the development process, and estimating the associated project cost and schedule. This enables working software to be built and reviewed in near real-time. The basic premise is to do the most challenging or important stuff first, transfer the most business value to the users as quickly as possible and identify problems as early as possible to mimimize costs. The generative part produces 75-90% of the total system code automatically; the rest is related to the code that differentiates one application from another, or modifications to the existing components to satisfy unique module requirements. The key to this approach is the degree of “granularity” of the component templates: too fine, and keeping track of everything becomes increasingly difficult as the application grows, too coarse and the number of modifications to generated components increases. Another benefit of the generative process is that multiple approaches to building the application may be explored in parallel with little risk. Modularization at this level enables specific functionality to be “localized”, yielding substantial post-deployment benefits, like improved sustainabilily and extendability. (Some of the systems built this way have outlasted the platforms on which they were implemented several times over). These factors may provide extremely good TCO figures. The bottom line is this: being able to create bullet-proof custom applications in a fraction of the time and cost of other methods means that that risks typically associated with software development are substantially reduced, and payback comes much earlier.

Thanks again for an interesting post.

]]>