Is your code worthless?
Earlier in the week I was reading an old post by my new favourite blogger Dennis Forbes entitled Internal Code Reuse Considered Dangerous. It contained this gem:
The question every organization needs to ask itself, then, is what value they could sell their “reusable code” for - what, realistically, would competitors and new entrants in the field offer for it? The answer, in almost every case, is $0, and they wouldn’t want it even at that price. There is extraordinarily little code theft in this industry (even though we’re in the era of burnable DVDs and USB keys) because most code - above and beyond the industry-wide frameworks and libraries - has no value at all outside of a specific project with a specific group of developers. Trying to use it for other projects is often worse than starting with nothing at all.
This is something that I already sort of knew, but it’s the first time I’ve seen somebody express the idea so starkly. It seems very counterintuitive that something that is so difficult and expensive to create can have so little value. I guess that’s why so many organisations like to pretend that their code is much more valuable than it really is.
I first encountered this phenomenon a couple of years back when I was dispatched over 8,000 km from my beloved workstation to assist a customer with an integration project. They were attempting to integrate our product into their product and had run into a few difficulties. A manager at my company suggested that they send us the partially-completed integration, including their source code, so that our engineers could assist. The customer refused. They were jealously protective of their “intellectual property” and would not let any of it off-site.
Since this customer was a big fish, I was sent to complete the integration at the customer’s premises. I arrived on a Monday morning and was shown to my cube where the hardware I needed was already assembled. I sat down and fired up Vim to start looking at their code and was INSTANTANEOUSLY BLINDED by the reeking bile that was pouring across my monitor. Even if I or my company were interested in marketing a product that did the same thing as the customers product, the last thing we would ever do is steal this code. Incorporating their code into our product would have meant incorporting all their bugs into our product, and from the look of it there were probably a couple for every hundred lines.
Of course, the code was not worthless to the customer- it was in a successful product that was making them money. As Dennis says, it was just closely tied to “a specific project with a specific group of developers”.
(On Jun 8th, 2007 at 3:34 am)
The interesting trade-off, of course, is now the code is worthless but those programmers are valuable. They know the intricacies of the system, and they’ll yell up and down they can’t be taught to anyone else. There’s this uncanny valley where writing worthless code actually protects you from losing your job.
(On Jun 8th, 2007 at 3:57 am)
So then this begs the question, should developers of internal projects strive to make quality software so that it would be attractive to outsiders?
(On Jun 8th, 2007 at 11:02 am)
kind of curious to wonder whether this impacts an organization thinking about using modded open sourced code in a project rather than writing their own proprietary stuff… if the proprietary code is going to end up being worthless outside the project, maybe better to use the open code which, since it is written out in the open, perhaps suffers less from the above issues?
(On Jun 8th, 2007 at 12:20 am)
Hey, thanks for the comments. I don’t think that this has implications for what a developer should do- there’s no need to make software “attractive to outsiders”, and if modding open source gets you to your destination faster, that’s great, but kind of tangential to this issue I think.
If code is “worthless outside the company” that’s OK, since it’s the company that’s paying for it to be written. An employee really should be focused on creating value for their employer, not random third parties.
Where the “worthless code” idea does come into play is when management are deciding whether to make code available to outsiders. For example, I’ve been in the situation where our product (sold to developers) had to run on many different operating systems.
There were two solutions to this problem:
(1) Distribute binaries for all the different platforms
(2) Provide source code so that customers can build the software themselves.
Providing the source would have meant a lot less effort - we would avoid having to build, package and distribute so many versions of the software. But this was never done, presumably since management were worried that making the source available would lower the value of the company’s intellectual property.
My argument (and Dennis’, I think) is that, in many cases, the risk of this happening is much less than is generally thought.
(On Jun 8th, 2007 at 9:21 am)
It would seem to me that the value of a body of code is dependant on the ratio of how difficult it is to do the thing that the code does to how difficult it is to understand how to use the foreign code. Generalizability is of course a plus, but I think the top thing is the afforementioned ratio. Most corporate code is written by people who don’t like to code and don’t do it very well, and maybe can’t write explanations very well(http://en.wikipedia.org/wiki/Functional_illiteracy).
(On Jun 8th, 2007 at 1:54 pm)
I spent several years writing software that I knew at the time would be worthless to anyone other than the specific client who requested it. It wasn’t a matter of code quality as much a matter of extremely customized requirements. These customers are not willing to pay for anything more than their specific needs, making pushing a more general solution (which often requires more effort and time) an uphill battle. Even when general solutions were available, I often needed to apply further customization to fit the requirements, customization which would have little value to any other software user.
Consider customized work on a house or car, or consider efforts made to go into singular events, such as weddings. Sure there is work that can be reused, but much of the result is specific to a particular location, time and need.
(On Jun 8th, 2007 at 12:47 am)
Fred Brooks wrote that it takes 3 times longer to write a software product - something that works outside a carefully-controlled environment - than it is to simply crank out software. Reusable software doesn’t come free, you have to pay the price for it, and if you are just reusing it once, it doesn’t make any economic sense.
(On Jun 8th, 2007 at 8:29 am)
The interesting side effect is that open source software, which is supposed to worth nothing, is actually much more valuable than closed source. Simply because it’s tailored for re-usability (or tries to at least). Every time somebody uses that open source project, the project has created value out of nothing tangible.
(On Jun 8th, 2007 at 5:35 am)
Making extensible software is not everybody’s cup of tea…apart from that we all know that majority of developers are developers not by choice and passion but because they need a career to survive and therefore they care the least…
I have been in this situation before where the client is at the height of obduracy…
(On Jun 8th, 2007 at 8:59 am)
“Code reuse” and “reusable software” are not the same thing.
(On Jun 8th, 2007 at 7:07 pm)
George, nothing magical and wonderful happens just because code is open sourced. I’ve seen closed-source stuff that’s very well done indeed and I’ve seen open source nightmares.
A project is more likely to pick up “hairs” based on age, and the complexity of the code and the problem the code is trying to solve, and I don’t think that changes because of what licence document you refer people to in the headers.
(On Jun 8th, 2007 at 5:36 pm)
Huawei was able to steal Cisco’s code to build and sell a competing product a few years ago. So the main point of this article is to be taken with a pinch of salt. code is NOT worthless. in addition to helping competitors it could also help a lot of malicious folks discover bugs that could be exploited.
(On Jun 8th, 2007 at 9:36 pm)
anoncowherd:
Thanks for that counterexample, I wasn’t aware of it.
(On Jun 8th, 2007 at 12:59 pm)
We had a break in at a previous company, and a potential source-code theft. I told the VP of development that I would defy anyone who got our sourcecode to even set it up.
That did not go over so well.
(On Jun 8th, 2007 at 6:37 am)
@anoncowherd:
http://www.lightreading.com/document.asp?doc_id=56939
There was no theft. Cisco were idiots for allowing public access to there code. They were stupid to think Huawei wouldn’t clone it. I think managerial narrow mindedness more than theft was the issue.
If the code was “successful product that was making them money.”, you should qualify the context of the value you’re talking about since it obvious provides great value if it generates positive cash. Any internal app, by definition, should be worthless outside it’s scope. If it’s part of a proprietary process that gives the customer an edge, why make an argument that it’s worthless because it lacks reusability. And, again by definition, it is an internal app. Why worry about “competitors and new entrants”?
So what’s the point here. If software doesn’t have extrinsic value and reusability for everyone, it shouldn’t be developed?
There’s way too much socialism and architectural fluff in software nowadays. Corporate software is about exploitation, not poetry and “what we can share and reuse” garbage.
(On Jun 8th, 2007 at 1:58 am)
hi,
Not always correct that client code is not worth.Imagine why they are not open sourcing google search code any bank application code etc…
Regards
Prashant
(On Jun 8th, 2007 at 12:27 am)
This resonates with the distinction that Richard Gabriel made in his book “Patterns of Software”. He notes that reuse is an organizational process which incurs significant costs. Seems that his insights are aligned with the reasoning suggested here.
Also, reading your story I realized that “our code that should not be exposed” is sometimes a smell: it indicates that the company has invested too much time in a framework - which may be reused in different contexts - rather than in the specific logic of the application.