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.
