Building software vs building bridges and going forward …

https://commons.wikimedia.org/wiki/File:%22S._P._Graves,_instrument_man,_working_on_new_construction_bridge_at_Norris_Dam.%22_-_NARA_-_532685.jpg#filelinks

I was in NDC 2013 (thanks to Johannes B) and went to a session from “Jez Humble” titled “(Re-)architecting for Continuous Delivery“. There he opened up the old comparison of “building bridges vs building software”.

With that Jez tried to explain there are significant differences in architecting a bridge vs architecting a software. One of his points was that you get an expensive architect to design and cheap construction worker to build a bridge whereas you get both design and building being expensive in software. Of course this point was fun intended.

One thing came to my mind out of this was that the bridge construction is tangible but software is not. (Of course this is obvious :D) And we are at a significant disadvantage as software builders due to this. (This is not news to anybody either :D) What intangibility does is it restricts the all important direct feedback to the builders (of software) at the building phase. What I mean as direct feedback is to get the feedback from war end or from where it is being used.

Compare with bridge building:

When you start constructing a bridge, once the two end points are identified, the builder can measure whether the each brick (or bar of steel) is in alignment throughout.  After every single brick put on, the builders can get the direct feedback since the output is tangible. (Nowadays you don’t do this as there are much better ways of getting feedback but still this is a possibility)

When it comes to building software, the builder cannot obtain such accurate feedback, since the output is not tangible at the source. Of course there are feedback mechanisms available for software builders such as compiler errors, test failures, build breaks, code analysis tools, etc. But these are not effective as bridge building feedback due to feedback being not direct. (meaning you get the feedback from builders computer and not from where is going to be used and those are not accurate either) One reason for this is that nobody knows where the software is going to be used. (If you consider bridge building, it is like bridge is build on a lab and copied all over the world:))

Good news is that we are improving over this:

Consider old days where we did software building in waterfall way. The builder has to wait many months if not years to get the first direct feedback. By the time this arrived, the builder may be working in another project.

Through subsequent iterative development and Agile movement, the software industry focused on making this feedback loop much shorter. Typically within two weeks time, the builder get some level of indirect feedback and within less than 2 months you would get direct feedback (from production). Good improvement but with added complexity in current business environments, this two months waiting period seems too-long now.

Continuous delivery:

http://tribune.com.pk/story/333790/long-term-deferred-payments-iran-offers-pakistan-oil-supply-on-soft-terms/

This is where Continuous Delivery (CD) would come in to rescue. So what the software world has done is not only to reduce to feedback cycle time but also to get the feedback from to the battle field itself (direct feedback). This would significantly counter the disadvantage of intangibility.

By maintaining a CD pipeline, you can get the feedback very quickly (after some minutes from code check-in) and from where the software is used. To do this, we have made the software delivery (incremental change) ever so lighter, even up to a level where there can be a release to production for adding a shade to “order” button. Isn’t this similar to construction worker getting feedback after every brick he laid on?

In conclusion, the software will never be tangible, but CD has done a significant work of cutting some corners of intangibility.

PS: It seems like bridge as also not safe and reliable as we think.

http://cliffordlaw.com/shocking-statistics-u-s-bridge-collapses/ http://www.bridgeforum.org/dir/collapse/year/2000-2009.html

References 

http://blogs.msdn.com/b/steverowe/archive/2005/02/28/why-building-software-isn-t-like-building-bridges.aspx

http://www.codinghorror.com/blog/2005/05/bridges-software-engineering-and-god.html

Photo

http://tribune.com.pk/story/333790/long-term-deferred-payments-iran-offers-pakistan-oil-supply-on-soft-terms/

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s