Value of Code

Introduction

Code is often valued at higher than it is worth. As software technology marches on, code is often a liability than an asset. Understanding this and how code ages, is critical to writing great software.

Creating an Internal Code Library

When I graduated with a Computer Science degree in 1992, I was very bullish on object oriented and component technology. In my first company, things were going haywire in the project. The code quality was bad, there was literally no architecture, multiple people were copying and pasting code around to create a spreadsheet or tree. End result was the product was scrapped.

I fought to establish a code library project that would build a C++ component library for spreadsheets, trees, custom window controls, dialogs, print preview, etc. It was very successful and was used in multiple products. But its value kept decreasing as MFC started including functionality like print preview, etc. The other issue with the library was that you had to convince developers to use it and get over the ‘Not Invented Here’ mentality.

Overall, the internal code library was a great success, and it did cut down significantly on product development time and led to more reliable products.

Third party Code Libraries

Other folks also saw the value in a code library and started creating component and code libraries for common tasks. When Visual Basic was released, the main value for the product was increased by the 100s of VBX controls that were available. You could buy a spreadsheet control for around $250 with the same functionality of our control that cost us around $15,000 to write.

Fast forward to today. Visiting componentsource.com or xtras.net, there are thousands of component libraries available for different development platforms. More importantly, the libraries have finally solved the code reliability and stability issues that their ancestors had. Another trend happening is that the environments like Visual Studio, Eclipse, Office, etc. are offering developers another platform to build on.

Another factor in play is code sites like CodeProject, etc., and open source software that give you a vast library of source code that you can use. All these factors change the equation of developing your own code.

Bottom line - the amount of code you write now compared to the amount of code you wrote in the 1990s should be minimal. Why? What sense does it make in writing code that some vendor sells for peanuts?

This is not to say Code has zero value, but Code is not like fine wine and does not age gracefully. Saying that my product has 2 million lines of code and took 3 years to develop is not a measure of value of the product. That Transaction monitor code (50K lines) you wrote is available as part of any J2EE server.

Focus Code to your Core competency

Companies need to make decisions, based on the core competency area, on what code is valuable, and what code can be junked or even better never written. Innovative code can give you a head start but can rarely give you sustainable advantage. You need to look for other methods like branding, partnerships, etc., to use the head start to become a market leader.

For example, if your company’s core competency is writing Printer drivers, then it makes sense to buy Visual components that help you build User Interfaces. This way, when there is a new toolbar for a new platform, you can take advantage of it. Developing and maintaining your own UI library in this case makes no sense. You should focus more on the printer driver code, which makes money for your company.

Unless you have a successful product like Windows with lots of legacy code, it is better to let code die and get resurrected in a different form via methodologies like refactoring.

Moving from ASP to ASP.NET

Let’s assume that you have developed some web applications using ASP. First, you need to find out if your customers need an ASP.NET version. If so, why and by when? What features do they expect to be in the ASP.NET version that isn’t there in the ASP one?

If there is a market need for an ASP.NET version, then you have three choices:

Port it line by line

Rewrite the whole thing

Refactor the domain specific code and write/buy the new ASP.NET code

The third option is normally the best because it makes best use of the new features of the new platform and reuses your domain specific code that you have years of knowledge. You could smoothen the transition to ASP.NET by buying server controls that implement the functionality you need. This method also lets you identify domain specific code that is valuable to you. When you need to port to another newer version of the platform (Avalon and WinFS?), this code will be ready.

It’s funny how software developers want to see the latest and greatest features in their platforms, and then cringe when they have to change or junk their old code to take advantage of it. It feels weird to see a Windows program now that does not support the latest toolbars, menus, or XP themes. To an end user, it looks like a 1990s piece of software.

Code Ages

If there is a lesson that developers can learn, it is this - All code ages and its value depreciates over time. Code goes from becoming an asset to a liability. What you can do is to write code that takes this into account.

In summary, some tips that can help you are:

Know what your company’s core competency is.

Write code that can be easily refactored.

Write classes that do only one thing.

Create and maintain UML diagrams, at least for classes.

Separate domain specific code that is valuable from platform specific code, which will change.

Try to buy platform specific code components that take advantage of the new platform features.

Try to bu components that will leverage your time to market.

Conclusion

As Software development platforms evolve, they will continue to provide more functionality either directly or via third party components. Planning how to evolve your product development strategy along with the platform’s evolution, will go a long way in easing some of the pain.

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

Share

About the Author

I am a software craftsman and have documented a small subset of my experiences that I hope that you will find it useful.

If you are starting a Software Development center, then you will find my presentation on Outsourcing Software Product Development very useful. This presentation is based on my experiences of co-founding and managing i3Connect.

Comments and Discussions

I'm always interested in the time and money that software decisions cost.

This article is important. It highlights the fact that in the extreme programmers need no longer be programmers. By that I mean that there are edge cases where a "programmer" goes to codeproject, sourceforge and component vendors does a little refactoring, builds some simple wrappers AND outperforms his hard core peers. Scary but realistic. (Maybe it's actually a great thing. Hmmm.)

My big problem with finding components is that my needs are often poorly served by what exists. That means time evaluating a variety of solutions. There is a skill in knowing when the evaluation effort exceeds the cost of writing your own. (I'm unhappy with my skill level in that area.) Then there are the horrors of fixing bugs in the third party code. I'm talking bugs that are only revealed over time. You need to set a cut point, in your mind, at which you "change horses".

There's also the "cross cutting" or orthogonal issues like exception handling, transactions, logging that may require a substantial refactoring (and forking of the project).

An area which I see emerging is translation. Somebody, who knows an area much better than I do, suggested the best solution for a problem was to take some open source Java code and translate it to C#.

I hope to see articles, in part inspired by this one, that give valuable insights of ways to tackle these things better.

Using Third Party libraries does reduce your development time, however the tradeoff here is the time spent in evaluating and searching for the right component to pick up. Also, you end up dealing with bugs which come with these third party components.

However, Over time, you do build relationships and trust the quality of components from certain vendors and at that time, using third party components is the way to go.

The best way is to find out which libraries are good is to have conversations with other developers who used them. This will save some time spent in evaluation.

With regards to the quality issue, I think component vendors have made big strides there, especially in .NET components. Since I am not a component vendor, it would help, if they would speak up on this issue

Another useful thing to do is to abstract you code from the component, so if you have to change the component, you need to change the abstraction layer only.

i strongly like to have the source also, todo the bugfixing or change the behaviour which our customers like to see,
but my boss don't like that he thinks i should not spend time on issues like bugfixing another one code...

another is thing that if you decide to use some components,
support and future new release should be granted..
our company bought a set of libraries in VC6.0++ (no source),
but after 1 year, the supplier was stopped development for C++ and go on
Java Only..... Now a few men years programming should be invested to get rid of those elements..

One of the things that I think was lacking from your otherwise very good article is the importance of writing an abstraction layer around third party libraries, whether Microsoft's or some other vendor. All too often important code blocks are entangled with the current implementation of MFC, .NET, or whatever. When the vendor changes the code, everything breaks. By using an abstraction layer, the code that I write is independent of the framework that it interfaces with. I've gone through several MFC and one .NET update without much hassle because of this.

I even write an abstraction layer around the internal guts of my own application, so I can swap out modules for improved ones, incrementally. An incremental approach maintains the value of the code base, rather than causing a code-value crash when new features are added or an OS changes.

Hmmm, do I hear "application automation layer" somewhere in the background?

Most of the examples involve GUI code. GUI code has a very short half-life: you should expect to abandon it in a few years. Non-gui code lasts much longer. (I frequently use some of the UNIX command line tools that were written in the late 70's.)

I think Microsoft's recent strategy with .NET is going to make things worse. They're making a big deal about how components will automatically recompile themselves on new computers. Yet .NET is best at GUI stuff which isn't going to last. I fear that many programmers are being conned into thinking .NET will give their code a longer lifespan.

I'm coming to view GUI code as a poisonous disease that you need to isolate from your valuable code.

I wanted to write coding practices that would be helpful but decided to do that in part 2 (version 2?) of the article, incase anyone was interested. Judging by the interest, I will write and post it next week.

I agree 100% with the abstraction layer concept that lets you swap out different modules. Close coupling with frameworks always get you into trouble when things change.

Maybe the author could suggest some tools for managing a shared library of core, reusable code? Or, were you looking for suggestions yourself?

Many things reduce the value of code -- but by how much? Consider buying some source code where the price was a function of the number of bugs, what would that function be? Now consider that instead of buying source code, you're buying the entire company. How much does the value of the company depend on the value of the source code it procuces?

It's an acedemic, rhetorical comment of course. But interesting to think about when reading about the latest insane price for a software firm aquisition.

I wanted to write coding practices that would be helpful but decided to do that in part 2 (version 2?) of the article, incase anyone was interested. Judging by the interest, I will write and post it next week.

With regards to your question - How valuable is source code when you buy a company. Unless it is patented and has been years in a development, the answer is not much.

For example, EBay recently brought Baazee.com, the largest auction site in India, the source code for baazee would be worthless in the deal, as EBay wanted to expand to a new market.

Keep it modular. If you ensure that everything is properly layered it should be relatively easy to swap components in and out as time progresses, technologies improve and the business rules change at ever increasing pace.

It remindes me of a line from the British TV comedy Only Fools and Horses where there is particularly slow thinking character called Trigger who said that he's had the same broom for 20 years and during that time the handle has been replaced 11 times and the head has been replaced 6 times. At which point the audience burst out laughing as they realise it contains none of the parts of the original broom.

"You can have everything in life you want if you will just help enough other people get what they want." --Zig Ziglar

It feels weird to see a Windows program now that does not support the latest toolbars, menus or XP themes. To an end user, it looks like a 1990s piece of software.

My personal experience is that users don't care what the app looks like, as long as it does the job. Non of my recent work uses any of the "cool" UI features and my customers don't miss it. Of course I'm building custom solutions and not selling 'shrink wrap' software, so that may be a factor.

> My personal experience is that users don't care what the app looks like, as long as it does the job...

My personal experience has been if you ask any Enterprise user, should I implement one of your features or support Office 2003 toolbars, the answer will always be - my features come first and this nice UI can come later.

But if you are selling an Enterprise Application Product, all things being equal the one with the Office 2003 Toolbars looks more professional.