Technology investment: Intangible Assets Part IV

Technology Investment

The actual investment in technology is both over- and under-valued by many non-IT practioners; either folks seem to believe that once you invest in one platform type you can then never change again, OR they believe that switching platforms is a trivial decision.

They also tend to forget about the costs of maintaining and upgrading your platform over time -- the biggest cost is often not the initial build.

I divide technology investment into two categories:

1. Code Base
2. Experience

Code Base
This asset relates to the investments an organization made in technology platforms, both those created/maintained by the organization as well as those that are not necessarily owned by the organization (due to copyright, open source, or public domain reasons). Unless the platform used is very simple, even when using a common platform like Drupal or Fakoli, it is highly likely that there will be custom or configured code base that is unique to the website.

For example, a Drupal site may have custom modules that are unique to this instance, that do specific things. A Wordpress site may have a custom designed template and graphical materials that is only used by one site. A Fakoli site will have a custom data model and components that pull and manage the data in ways specific to that site.

All of this custom code started with requirements gathering, included software design and development time, and testing for integration, cross-browser compliance, and usability, representing many hundreds (if not thousands) of hours of labor.

Secondly, the code base also probably represents a few iterations of development, meaning there are also processes and scripts created to move code from development to production. The more often these sites are updated at a code level, the more likely the site management process will be streamlined and perfected.

Experience

The second part of the asset is the experience of the team that built the site. Every instance of Drupal has unique configurations; every Fakoli site has specific elements created just for that site. For a good developer, the learning curve for learning a well-designed site should be short, but it does exist (for junior developers, the learning curve is often much steeper). It is at least 10x faster for the developer who created the code base to fix a bug than it is for an outside developer to find it. The last thing you want your developers to do is "code archaeology."

Secondly, the experience of the team working together on the same project makes requirements management a lot easier; they can plan out future changes and edits in multiple stages, and highlight areas of testing and concern. They often can tell you quickly whether a requested change is trivial or non-trivial - something that can be hard to determine wtihout knowing the code base intimately. 

Finally, the team learns from real world experience with users about what works and doesn't work. The current model of development uses "agile" methods to get just enough software up in front of users as quickly as possible, because it has been found that even the best designed systems fail to capture all requirements of the real world. However, a team that has worked together in a production environment for a few years has a good sense of the user base, what has failed in the past, and what may work in the future.

Valuation/Loss
The valuations of these assets are mainly measured in time vs. quality. The more time you give something to mature, the higher in quality it will generally be. But if you start from scratch with a new platform and a new team, you are not gaining from the previous investments in the code base or the team experience.

An example to bring the value of experience home:

Andy (our CTO and co-owner), in an exit interview with a former employer, was asked how long it would take to rebuild a piece of software from scratch (as they were prohibited from using any of the previous code base due to legal issues).

Andy replied "Well, it took two senior developers full-time 18 months. So, with two senior developers full-time... around 18 months." 

The boss replied, "But what about all the institutional knowledge? Surely it must take less time because of that?!?!"

Andy replied, "Your institutional knowledge just walked out the door."