Changes Are Expensive

10 Dec 2007

Saw another interesting post over on DZone aptly titled Changes Are Expensive, Damn Expensive.

Now I agree more or less with the premise of the argument.  There will always be a cost associated with writing or releasing code, invariably this cost will rise as the product matures in the market and develops a sizable customer base.  Not only do market demands or shifts dictate the cost of a change (or conversely it’s earning potential) but the organization itself plays a significant role in determining the true cost of a change.

The developer in me doesn’t necessary agree with the notion that code re-use should significant increase the cost of a change.  We’ve all been beat over the head with the low coupling – high cohesion hammer enough to hopefully understand when and how code should be re-used. 

In my mind, it’s all about timing and more importantly becoming pro-active individuals.  The later ties into the act of balancing both the strategic and tactical objectives of an organization.  Having been through the high growth periods of a startup, I’ve come to realize the importance of establishing strategic goals (we didn’t exactly have them and played catch-up long after the fact).  In times of pressure it’s very easy to forget the future and plan only for the present. 

A lot of software companies have realized this, and they provide a test suite along with the code that they handover to their customers.

I’m not quite sure what kind of software the author writes (I realize he’s in India so perhaps it’s outsourced work) but short of open-source projects I’ve rarely ever seen code let alone a test suite delivered to an end-user.  An interesting idea but difficult I imagine to do in practice with a diverse set of customers and demands.  As a user of software, it’s been long evident that writing test cases doesn’t guarantee quality software nor ease of maintenance.  It shows a bit of added diligence and with the right team could take you a significant ways towards building maintainable software but *unfortunately *it’s not a guarantee of anything.

The act of making a change impacts far more organizational groups then development, certainly if it’s any way shape or form user-facing.  Not to be left out would be the customer support, quality assurance and end-user documentation costs associated with any significant change in functionality.

Changes are inevitable and when adequately balanced an important aspect of growth.  Probably the worst thing a developing (or already established) organization can do is attempt to ignore them. Fortunately for us we’ve be witness to an emergence of organizational processes (some development-focused, some not) that should allow us to more easily embrace the notion of change.