Measuring the Time Saved When Reusing a Well Architected Component

A well architected component is easy to develop given the right technical knowledge, practice, skill, and motivation to do the right thing.  I’m taking a practical example of a component I developed recently, described in the blog post titled Getting to the Monetary Value of Software Architecture.  Relatively speaking this component wasn’t complex to develop, but it did require some trial and error and some clever thinking to perfect it.  Development of this component took just over 4 hours to complete – and contains 80+ lines of code (that’s code, not including comments or blank lines), and once it was complete we could apply and reuse this functionality in various places with extreme simplicity.  Actually, with only one line of code!!  That’s the power of simplicity and reusability.  See the actual code for the component here: Class to Add Instant ‘As You Type’ Filter Functionality to Infragistics UltraCombo Control

In a recent blog post, I talked about the monetization of well architected solutions.  Here I am going to put some hard values against it.  I used the following variables to come up with the data to put into the chart.

Initial development time required: 240 mins

Time required to duplicate this functionality once (non architected solution): 15 mins (assuming the user is somewhat familiar with the code and is copying and pasting) – I would comfortably say it could take 30 mins for someone who isn’t quite sure how the code worked to begin with and therefore not knowing exactly which code is required to be copied – this would double the blue time line as shown on the char below.

Time required to duplicate this functionality once (well architected solution): 1 min  (it’s literally one line of code!)

These numbers were taken from the time it took to actually do the implementation several time.  The 15 mins value required to duplicate the functionality for the non architected solution was derived from practicing a copy and paste scenario to integrate code to add the functionality required. 

image

This does not account for the extra effort required in the future to maintain the code or make updates and enhancements.  With the well architected component you have to make an update somewhere in 80 lines of code to fix a bug or add an enhancement.  In the non architected version, you would be making a change within (80 x N) lines of code where N is the number of implementations.  Let’s say 10 – so we’ve got 800 lines of this code that essentially do the same thing over again that need to be looked at to make a code change!  Plus all of the other application code intertwined within it that you have to ignore.

This is just one example!  There are great architectures all over the place and we all (mostly) know how valuable they are.  Other than just saying “Yeah, they save tons of time..”, I’m here putting some hard values against it. 

This is one scenario, but there are many more scenarios that save even more time – I’d even say, exponentially save more time!

About dandouglas
Dan Douglas is based in Toronto, Ontario, Canada and is a professional independent Software Consultant and an experienced and proven subject matter expert, decision maker, and leader in the area of Software Development and Architecture. His professional experience represents over 15 years of architecting and developing highly successful large scale solutions. Dan also believes that properly empowering teams with trust and responsibility yields the greatest results. | For inquiries about Dan's software consulting practice, please see the contact page.  Dan has also built up a network of highly successful and professional Software Developers and Architects who are highly respected and can be called upon and used in conjunction with his own consulting practice to handle the largest of consulting projects.

One Response to Measuring the Time Saved When Reusing a Well Architected Component

  1. Steve says:

    This is great. Nice to see a value put to it like you said. Not just yeah, it saves time. If you look at the example you are saving 2.5 hours on the project simply by reusing something that is well architectured. Goes way beyond that, like you mentioned with upgrades or maintenance, but even debugging, and troubleshooting times will be way cut down. If you ask me, it is invaluable, and something that I tried to teach many developpers that I have worked with, would have saved them alot of time and trouble, and me plenty of time supporting it. One particular example comes to mind where it was such a horrible mess, in the solution I implemented such an idea, but it cost the company 40 hours of support, pushed back other things I would be supporting and not to mention all the problems that plagued the software that prompted me to look at it in the first place.

    Good post Dan, hope many add it to their development standards.

Leave a comment