Lance's Whiteboard

Random scribbling about C#, ASP.NET, Sql Reporting, etc.

News

BlogMailr Enabled




Sponsored Ad
Sponsored Ad

Blogs I Read

Developer Sites

Googling, etc...

MSDN Resources

Tutorials & Reference

Code as an Asset...

I am not as well-read of a developer as I would like, but I consider myself to be very intuitive at discovering and defining best practices in programming. I don't mean this as a boast, there is just a part of my personality that drives me to constantly seek-out and create templates and patterns to simplify and standardize any code I write. I am constantly trying to identify and improve my development philosophy and methodology to create applications better, quicker, and more innovatively every day.

Therefore, it was a bit of a shock, when I discovered a viewpoint of software development that had escaped me:

Code is an Asset!

I'm not referring to the software produced via code, instead I'm suggesting that each piece of code itself is an asset. More specifically, any encapsulated piece of UI or functionality should be treated as an asset to an organization, not just as a piece of the greater asset of the Application that uses the code.

Each unit of encapsulated code has a cost to create, and therefore has value. But, how often is this cost and value tracked and monitored? Who makes sure that code-assets do not get misplaced, thrown away, or lay unused? Undoubtedly the programmer's supervisor or organization sees the expense of the payroll associated with each developer, but have you ever seen a company try to assign that cost to individual pieces of code in order to establish its value? Have you seen a manager ask why we arent getting more reuse of a component in which they invested? With the exception of companies whose main function is software-development, I suggest that the majority of companies only consider the products and services rendered by a developer as an asset, and ignore the value of the underlying code.

On the other hand, for many years developers have instinctively labored to achieve encapsulation and code reuse. However, the value of this has mostly been lost on management, unless it added benefit to the project or to the productivity of the developer. In fact, I suggest that most IT management would overwhelmingly favor an application quickly delivered, yet poorly encapsulated, over one well-encapsulated at the expense of a small delay in the project. Obviously we always must try to balance the cost of time vs. reuseability in every project, but in many organizations management has been excessively focussed on delivery-date, while developers tried to squeeze every bit of time in to enhance reuseability and encapsulation within their codebase. It is this constant struggle between developers and management to achieve their opposing goals that undermines achievements of most IT organizations. In the end, both are usually left with ill feelings and an adversarial attitude due to the compromizes they each had to make.

If IT organizations restructured their methodology to recognize cost and value (or valuelessness) of every ounce of code produced, it would go a long way towards remedying many of these conflicts and promote a proactive approach to optimizing the ROI of every project. Indeed, by tracking code as an asset, it could streamline the development process and reduce overall IT costs for the organization. Together, management and IT staff would focus their attention on identifying the best use of existing code assets and time, and how best to invest towards in-house, contract, and even open-source development to enable the company to gain even greater productivity while delivering more timely, robust, and well-balanced products and services.

Developers could be involved in decisions of how to reduce development costs by outsourcing, or buying prebuilt libraries for the homogenous code, and spending more time on the proprietary or company-specific implementations that take advantage of your company's expertise. Also, management would start seeing the payroll expenses translated into assets they can promote as capital investments for the organization. This will lead inevitably to an incentive to invest in improving methodology for identifying and designing reuseable components, promoting sharing of intellectual property within the organization, and a focus on rewarding developers who excel at delivering innovative reuseable components that provide the organization with more assets with which to speed delivery of increased profits to the bottom line.

This is such a simple and obvious idea, yet as an industry we are stuck in our traditional and out-moded approaches to IT management that it could actually be considered revolutionary if not rebellious in many organizations.

What do you think? Is this much ado about nothing, or am I on to something? Does anyone out there know of books on the topic that exist? Tell me if I'm just a silly newbie developer who has too tight a hold on the elephant's leg to see it standing right in the middle of the living room....

Comments

Stephane Rodriguez said:


I don't think today's new challenge for software developers is to make a tradeoff between the beauty of clean interfaces, and the ability to come up with a code that works right on the deadline. It's more about how code can adapt the changes in requirements during the lifetime of the project.

We already know that the lack of requirements, the fuzziness, the fact there are too many constraints, on top of short deadlines is an issue, has always been, and will continue to be.
But, when you deal with short or semi-long term projects, you'll probably have to change your code to meet requirements that change 3, 4 or even more times. At this point, that's not beauty or uncoupling of interfaces that matter, it's the ability to quickly change to meet the new requirements regardless the existing plumbing you have capitalized on so far. This indeed greatly open doors to visual modelers, visual editors, and code generators based on modelling.


# December 17, 2003 1:00 PM

Lance said:

I agree 100% with your comments. Development challenges today are more complex and go much further than this one issue.

However, the conflicting and often adversarial approaches taken in IT today between management and developers are a major current within that struggle with requirements, constraints, and deadlines.

I do not think your statement is contrary at all to what I was saying. In fact, it strengthens my view on the importance of tracking code as an asset instead of just as an expense. It totally changes the dynamics that lead to the problems you stated.

Thank you for your comments!
# December 17, 2003 1:09 PM

Udi Dahan - The Software Simplist said:

Put yourself in the shoes of the IT manager. His boss is non-technical. He is responsible for delivering services to the business. The building blocks of the value he delivers are projects/applications. Now, what you're saying rings true, and maybe - just maybe, the IT manager can come to understand and appreciate the new point of view. However, what you're suggesting here has long-term organizational impacts.

The IT manager in many cases doesn't have the political organizational power to make the changes required. If you're very VERY lucky, you may have such a boss, with the political power and the guts to improve things long-term while sacrificing short-term business-valuable collateral.

All this, of course, pertains to organizations where developing software isn't the main line of business. In these places, IT is viewed as a cost center, and not as a profit center, in most cases. The IT manager has a lot on his plate, but changing the perception of IT as a value-producing entity should definitely be at the top of the list.

As a person who has done both development and IT management, I find that developers are somewhat ignorant about the surrounding organizational issues. Yes, code is an asset, SO WHAT ! Prove it. Show the business value. Translate it into ROI - that's return on investment - meaning how much is this gonna cost the business ( remember, cost center ) ? Can you cite studies that have done similar things in organizations like ours ? What were the results ?

Furthermore, developers have to be brought down to earth sometimes. I had a developer under me some years ago that was just aching to do some .Net work when it was still in beta. Now, I needed the system up and running in a month - and an Access solution would have been just fine. "But .Net is the wave of the future" he said. "We'll be so much more productive long-term." Do you think that the HR manager to whom I committed to developing a solution for a time-critical problem cared ? Do you think that, as a result of that, I cared ?

In IT, business rules. If you've got a case, make it in business terms. Yes, code is an asset - I agree, now prove it.
# December 18, 2003 3:53 AM

Mike Shraga said:

Hi
Excellent article - I am in the process of looking at a 30% buy in and need to calculate after 3 years of development and over 100 installations the NAV of my software.

Any idea how I do this beside the cash and goodwill , banks etc do not see software as a asset.

Look forward to your reply

Mike Shraga
MD Kuepper International (Pty) Ltd.
# March 7, 2004 7:00 AM

Mike Shraga said:

any replys for me on the above ??
# April 29, 2004 2:01 PM

Lance said:

Sorry for not getting back to you, but I havent had much time to devote to this topic lately.

I did some research in the area of quantifying the value of software, but havent found a good resource on the topic yet. Most of the pre-existing Case Studies revolve around mergers and acquisitions within the commercial or consumer software industry... (E.g. IBM acquiring Lotus, Microsoft acquiring Connectix, etc.)

I think we need to find a good bean-counter who has been through this process and had to assess value of a code-base.

I wish you good luck in your search, and will try to contribute to this topic whenever I am able to devote more time.

Thank you....

LH
# April 29, 2004 8:21 PM