Discussions

Java.net's editor blog pointed out Carl Lewis' "Is your code worthless" essay, which points out that many customer's intellectual property isn't worth much. It's an interesting point; code written internally usually is too focused on internal needs to be worth much to anyone else.
From the article that inspired Mr. Lewis' blog entry:

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.

The point brought up by the blog entry:

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”.

I feel the code that one writes is not all worthless. While it may not have a 'resale' value as such, it is quite invaluable to the person who writes.
There have been a number of occasions where I have seen programmers having their own set of common classes that they use across projects and across companies.
In my mind, reusability happens at the programmer-level rather than at the company-level.
A simple question to ask is this: Let's say you were working on a Java Chat Software in Company A. You quit the company at some point and move on to Company B. In this company, you are asked to work on a software, of which one of the components is a Chat Software.
At this juncture, would you or would you not use your experience and may be even snippets of code that you had written while you were at Company A?
If so, then that is reusability at the programmer level and that is valuable for the programmer in that it saves time.

At this juncture, would you or would you not use your experience and may be even snippets of code that you had written while you were at Company A?

Experience, that's what help you solve the problem faster the second time around and land the next job / project.
Reusing code - you better check the contract under which it was developed! I have not to date, worked (commercially) on a project where the code was not owned/copyrighted by the customer and/or my employer at the time. Of course this may just be my situation but I suspect that it is a common scenario.

My favorite poster from Dispair.com is hanging on my office wall and is labeled
"Mistakes"
It could be that the purpose of your life is only to serve as a warning to others.
I think of a great deal of code I deal with in that manner. That or an anti-pattern.

:-D
It's a very interesting point actually: the article define worthness as "what value they could sell their code for". Accordingly, all Open Source would be worthless.
How much did Red Hat pay for acquiring JBoss again? ;-)

Unless you are able to sell a solution that the software solves, the software is in deed useless. You really are never selling software, but a solution, because software alone is of no value.

I really don't like that attitude in software vendors. The more one wants to sell a "solution" instead of selling "software," the crappier the software tends to be.
The end result is a house of cards with custom-built strap-ons to fragile commercial products.

Unless you are able to sell a solution that the software solves, the software is in deed useless. You really are never selling software, but a solution, because software alone is of no value.

I really don't like that attitude in software vendors. The more one wants to sell a "solution" instead of selling "software," the crappier the software tends to be.

The end result is a house of cards with custom-built strap-ons to fragile commercial products.

Worse, it's usually an excuse to play down the role of the software and the people that create and maintain it.
Saw it firsthand in the previous company I worked in. One day management decided that we were no longer a software company but a "business integration service provider" or something of that ilk.
Suddenly software development was seen not as something providing the product they sold, but as a necessary evil to fix the problems with those products (many of which were related to poor installation and use).
Software development was banned to another part of the building where managers and salespeople rarely if ever ventured, everything that went wrong anywhere was suddenly blamed on software development (even when a customer site went down because of a powerfailure, the blame for the outage was laid on the software rather than their refusal to order a UPS for their server), every success (like the successful implementation of a custom solution by software development) was credited to sales and training departments.
That this wasn't doing the morale much good needn't be repeated I think.
The end of year letter by the CEO stating bluntly that the good financial results that year had been achieved DESPITE the software group only made things worse.
I didn't stick around for the next year.

I really don't like that attitude in software vendors. The more one wants to sell a "solution" instead of selling "software," the crappier the software tends to be.

The end result is a house of cards with custom-built strap-ons to fragile commercial products.

Isn't that what consultants do? They don't know enough or are able to be around long enough to provide anything but a solution.
That isn't a knock against consultants, just an observation. There job is to get software developed within a specified time period and at a certain cost. If they deliver a quote that is 2x higher than others, than they are not likely to be selected.

I really don't like that attitude in software vendors. The more one wants to sell a "solution" instead of selling "software," the crappier the software tends to be.

The end result is a house of cards with custom-built strap-ons to fragile commercial products.

Isn't that what consultants do? They don't know enough or are able to be around long enough to provide anything but a solution.

That isn't a knock against consultants, just an observation. There job is to get software developed within a specified time period and at a certain cost. If they deliver a quote that is 2x higher than others, than they are not likely to be selected.

I've seen a number of what some call "consulting products." Basically it's where a consulting organization tries to sell you something they've cobbled together over a series of contracts with several customers.
The problem is when they stop selling them as "consulting products" and start selling them as products. Margins are a lot higher in software than in consulting, and I think there's a lot of pressure to sell software even though it really hasn't been productized yet.

Who do you sell to?
Is selling the act to receive money by giving away an executable?
For the particular in-house solutions, I've seen a tool made for internal use saving thousands of dollars to the company in person-hours of manual work. That tool is never going to be sold, but it is of great value.
Was is worthless to construct it?
William Martinez.

The observations are absolutely correct.
But they leave us two choices:
1) Do not try to reuse code
2) Learn from the issues experienced and get it right
Code reuse and frameworks for the sake of it will not help. We need to look at the failures as well as at the success stories and learn from them. We need also to accept where it can work and where not.
Done correctly it can save a lot of time and produce consistent and strong applications.

Writing clean and good documented code, designed with loose coupling in mind to promote reusability is much more (2-3 or more times) expensive that just churning out something that just runs, delivers required functionality and passes all tests.
So it is not surprising that the customers, wanting "just" a working system, are not ready to pay for future reusability that will most probably never come.
And it is also quite obvious, that the value of the code itself, being taken separately from complete system, designed to run in specific environment, is nihil.
After all, the code is only as good as the developers make it to be. If you've won a fixed bid contact, you'd better make sure that you'll rip them off with maintenance contract later, won't you? :)

Writing clean and good documented code, designed with loose coupling in mind to promote reusability is much more (2-3 or more times) expensive that just churning out something that just runs, delivers required functionality and passes all tests.

Not to mention, in my experience, most developers when given the chance, will take 2-3 times longer and there stuff still isn't all that reusable. So even if a company wants reuse they still often find themselves on a legacy system that the developers want to rewrite after a few years.
Successful Open source projects have far and away the best reuse in our industry. I'm 10x more impressed with guys who have successful open source than people who work on in house frameworks that are designed for reuse. Most in house frameworks are only liked by those who wrote them.

Successful Open source projects have far and away the best reuse in our industry. I'm 10x more impressed with guys who have successful open source than people who work on in house frameworks that are designed for reuse. Most in house frameworks are only liked by those who wrote them.

You know, if you need something in house and you can't find an existing solution. You could create an open source project (on your own time, of course) and then say 'hey I found this great package' and use it.
This is all hypothetical, though, I've never ever done this myself ;-)

Successful Open source projects have far and away the best reuse in our industry. I'm 10x more impressed with guys who have successful open source than people who work on in house frameworks that are designed for reuse. Most in house frameworks are only liked by those who wrote them.

You know, if you need something in house and you can't find an existing solution. You could create an open source project (on your own time, of course) and then say 'hey I found this great package' and use it.

This is all hypothetical, though, I've never ever done this myself ;-)

Well, if you know a guy doing it, have him let me know how it works out. The idea has crossed my mind on more than one occasion.

Successful Open source projects have far and away the best reuse in our industry. I'm 10x more impressed with guys who have successful open source than people who work on in house frameworks that are designed for reuse. Most in house frameworks are only liked by those who wrote them.

You know, if you need something in house and you can't find an existing solution. You could create an open source project (on your own time, of course) and then say 'hey I found this great package' and use it.

This is all hypothetical, though, I've never ever done this myself ;-)

Well, if you know a guy doing it, have him let me know how it works out. The idea has crossed my mind on more than one occasion.

The hard part is getting people involved, at least for the project I started. Not really a glamor project. Hell, I don't even want to work on it all that much.

Successful Open source projects have far and away the best reuse in our industry. I'm 10x more impressed with guys who have successful open source than people who work on in house frameworks that are designed for reuse. Most in house frameworks are only liked by those who wrote them.

I don't care much about open source or not, code quality and cost. I care about functionality. In fact a lot of open source projects have such a bad codebase that no one who would care to look at it would consider reuse. Much as in the closed source example. A particular bad mess of code was Tomcat 3, yet it was a huge success. Because of it's functionality (and cost and branding of course).
The problem with a lot of In House frameworks is that a lot of them tend to replicate something that already exists in open or closed source, but worse. Generally there is far too less looking at existing frameworks.
For example I am sure there are zillions of "Web Flow" frameworks out there that have been written without taking a serious look at Struts, let alone Web Methods. There are probably even more "rich client frameworks" for Java without anyone bothering to look at how Microsoft or NextStep have tackled the problem.
Also, there is to some extent an issue of the quality of programmers and designers. Most excellent designers will not work at an airline or an insurance and if they do, most of them will be contractors.

Writing clean and good documented code, designed with loose coupling in mind to promote reusability is much more (2-3 or more times) expensive that just churning out something that just runs, delivers required functionality and passes all tests.

Depends if the project is active or destined to be zombied after the initial release. After watching a gang of developers from a team essentially rewrite the same project from scratch every 12 months as the business grows and requests enhancements, I can't say that is 2-3 cheaper than investing in writing well designed, extensible code.

Writing clean and good documented code, designed with loose coupling in mind to promote reusability is much more (2-3 or more times) expensive that just churning out something that just runs, delivers required functionality and passes all tests.

Depends if the project is active or destined to be zombied after the initial release. After watching a gang of developers from a team essentially rewrite the same project from scratch every 12 months as the business grows and requests enhancements, I can't say that is 2-3 cheaper than investing in writing well designed, extensible code.

By the third time they should have decent, extensible code. The first time they don't know any better. The second they over-engineer (aka the second-system effect). But the third time they should get it right.

I always thought that the real concern with IP and software was not that the code could be reused as is but that there were business processes and other proprietary knowledge built into the code.
If I go look at a tutorial on using a library, I don't expect that I'll be able to take that code and reuse without writing anything. But the code in the tutorial is still valuable to me. I can learn from it.

I always thought that the real concern with IP and software was not that the code could be reused as is but that there were business processes and other proprietary knowledge built into the code.

Bingo. Although someone could write the same blog about how your "business processes" are worthless, and it would be equally applicable.
Have you ever been to a conference that has domain experts, IT people, and software developers in fairly equal measure?
What I've learned at these is that everyone has pretty much the same problems as is solving them in pretty similar ways. Much of this is because they all buy the same crappy commercial packages, and hire the same consultants for "ideas" (e.g. what the competition is doing...which happens to be asking what you are doing...so the consultants make something up).
Yes, every once-in-a-while someone has a true gem of an idea, and either has or finds someone with the organizational influence to make it real.

What I've learned at these is that everyone has pretty much the same problems as is solving them in pretty similar ways. Much of this is because they all buy the same crappy commercial packages, and hire the same consultants for "ideas" (e.g. what the competition is doing...which happens to be asking what you are doing...so the consultants make something up).

This is one of my arguments against the 'we must buy everything' philosophy. At my current employer, we have issues because the software that was purchased something like a decade ago never met the needs of the users. More specifically, the package did not support a lot of the functionality of the custom written app they used before that. From my perspective, this is a problem that we (the tech people) need to solve. But instead we just tell the users that they are using the software incorrectly or that their processes are overly complex or that they should change their processes to fit the software.
To me this is completely ass-backwards. It seems to me that we should be trying to solve problems, not telling people who know a lot more about our business than we, how to do their job. Basically we've handed over how we run our business to some nerds that are completely isolated from us. The best we can hope for is to be as good as our competitors because we've decided that all innovation in our business must derive from software that our competitors also use. The idiots that make the software aren't even good at that and we expect them to show us how to run our business? This is insanity. We are constantly paying the vendor huge sums to implement things (above what we already pay for the software) which I'm sure they turn around and sell to our competitors for less.
I'm not saying that we must all write everything from scratch but I think businesses need to be more critical of software vendors and require that these tools are highly customizable. By 'highly customizable' I mean we can extend the product and hook into it with real programming tools and not some BS DSL or XML format they pooped out.

What I've learned at these is that everyone has pretty much the same problems as is solving them in pretty similar ways. Much of this is because they all buy the same crappy commercial packages, and hire the same consultants for "ideas" (e.g. what the competition is doing...which happens to be asking what you are doing...so the consultants make something up).

This is one of my arguments against the 'we must buy everything' philosophy. At my current employer, we have issues because the software that was purchased something like a decade ago never met the needs of the users. More specifically, the package did not support a lot of the functionality of the custom written app they used before that. From my perspective, this is a problem that we (the tech people) need to solve. But instead we just tell the users that they are using the software incorrectly or that their processes are overly complex or that they should change their processes to fit the software.

Personally, I believe that unless the particular process belongs to the core business of the company (or otherwise can give the company a competetive advantage against competitors), the software should be bought, and if necessary the internal processes should be aligned to whats supported by the package.
A company building cars could build systems for building cars if it believes that it can gain a competetive advantage by doing so. It should not buy a tax reporting package, and if the internal processes for reporting tax isnt aligned to the major commercial packages, then change them.
It gets more complicated when you deal with international enterprises, because there are fewer customers, and hence fewer comercial packages which really fits the profile.

Personally, I believe that unless the particular process belongs to the core business of the company (or otherwise can give the company a competetive advantage against competitors), the software should be bought, and if necessary the internal processes should be aligned to whats supported by the package.

Has anyone actually seen a project where this actually worked? I don't mean one were it was deployed and some executive declared the project a success. I mean actually worked.
In my experience this is the mantra of projects about to blow past their budget and schedule, as they realize the futility of adapting a large company to a piece of half-baked software.
The only thing harder to change than large codebases is large companies.

What I've learned at these is that everyone has pretty much the same problems as is solving them in pretty similar ways. Much of this is because they all buy the same crappy commercial packages, and hire the same consultants for "ideas" (e.g. what the competition is doing...which happens to be asking what you are doing...so the consultants make something up).

This is one of my arguments against the 'we must buy everything' philosophy. At my current employer, we have issues because the software that was purchased something like a decade ago never met the needs of the users. More specifically, the package did not support a lot of the functionality of the custom written app they used before that. From my perspective, this is a problem that we (the tech people) need to solve. But instead we just tell the users that they are using the software incorrectly or that their processes are overly complex or that they should change their processes to fit the software.

Personally, I believe that unless the particular process belongs to the core business of the company (or otherwise can give the company a competetive advantage against competitors), the software should be bought, and if necessary the internal processes should be aligned to whats supported by the package.

A company building cars could build systems for building cars if it believes that it can gain a competetive advantage by doing so. It should not buy a tax reporting package, and if the internal processes for reporting tax isnt aligned to the major commercial packages, then change them.

It gets more complicated when you deal with international enterprises, because there are fewer customers, and hence fewer comercial packages which really fits the profile.

The situation that I am describing and the one I am dealing with is with respect to the core business. The core of the core. And the problems are not minor. I had a huge issue recently on a project because there is verifiable way to track certain core entities through time. That is, there is nothing that links record A with record B even though they represent the same customer entity at different points in time. The only reason that is the case is because the software that was bought does not support the way that the company does business. Actually in this case, if technical people had been involved, it might have been avoidable.
I agree with you that software packages (if they exist at the desired quality) should be purchased or acquired for non-core functions. The biggest problem I see is that things that are core are categorized as being non-core.
And even for core functions, IT should not be writing applications from scratch in most cases. They should be gluing fairly small general pieces together. But software is rarely sold in nice modular pieces.

I had a huge issue recently on a project because there is verifiable way to track certain core entities through time. That is, there is nothing that links record A with record B even though they represent the same customer entity at different points in time. The only reason that is the case is because the software that was bought does not support the way that the company does business. Actually in this case, if technical people had been involved, it might have been avoidable.

Well, thats another (and soften more serious) problem, i.e. that architecture and operations often fall short to business when decisions in procuring new packages is made. I have often seen software that is marginally better in business functionality win over packages that are much more suited to the enterprise architecture or operational environment.

I had a huge issue recently on a project because there is verifiable way to track certain core entities through time. That is, there is nothing that links record A with record B even though they represent the same customer entity at different points in time. The only reason that is the case is because the software that was bought does not support the way that the company does business. Actually in this case, if technical people had been involved, it might have been avoidable.

Well, thats another (and soften more serious) problem, i.e. that architecture and operations often fall short to business when decisions in procuring new packages is made. I have often seen software that is marginally better in business functionality win over packages that are much more suited to the enterprise architecture or operational environment.

I guess the point I am trying to make is that there is a dogma in IT these days that says you must buy all of your software if possible. The result is that 'off-the-shelf' packages are bought even if they are not appropriate in order to attempt to implement this theoretical ideal. I see no evidence that this approach is always better. There are certain packages that we have bought that have cost us almost as much as our staff of full time developers (each year) on top of the purchase price.
My biggest pet-peeve is making decisions based on theoretical models of how things 'should' be and not on how they are. In fact, most of these big packages are walled-gardens with their own programming language. I think IT needs to grow up and realize that this is a failed idea. SOA is actually a step in the right direction but it's meaning is so diluted with BS that the term is becoming worthless.

I guess the point I am trying to make is that there is a dogma in IT these days that says you must buy all of your software if possible. The result is that 'off-the-shelf' packages are bought even if they are not appropriate in order to attempt to implement this theoretical ideal. I see no evidence that this approach is always better. There are certain packages that we have bought that have cost us almost as much as our staff of full time developers (each year) on top of the purchase price.

My biggest pet-peeve is making decisions based on theoretical models of how things 'should' be and not on how they are. In fact, most of these big packages are walled-gardens with their own programming language.

Well, in my experience most of the problems comes from the desire of the business side to make every customization possible to the bought package. The vendor darent say no in fear of losing credit early in the contract. This of course causes all kinds of nasty problems, like virtually killing the upgrade path.
When you buy a package you somehow also buy ideas and processes. If you cant imagine adapting your self to the package, then you must either be lucky enough to find a perfect match or build it yourself.
And then there is SAP, but that is closer to build it yourself than buying a ready software...

Well, in my experience most of the problems comes from the desire of the business side to make every customization possible to the bought package. The vendor darent say no in fear of losing credit early in the contract.

Exactly. People want software that helps them do business. They don't want software that tells them how to do business. I'm pretty convinced that they are absolutely correct.

This of course causes all kinds of nasty problems, like virtually killing the upgrade path.

Of course. But it seems pretty odd to me to tell people that they should use software in a way that doesn't fit their needs so they can avoid issues with using it in the future.

When you buy a package you somehow also buy ideas and processes. If you cant imagine adapting your self to the package, then you must either be lucky enough to find a perfect match or build it yourself.

But I kind of think this is a cop-out. It's basically saying that vendors can't actually meet your needs so you should change your needs to match what the vendor supplies.
I'm also convinced that the problem is a result of trying to sell software in monolithic pieces. Any vendor with a few skilled designers could provide their functionality as a set of modular pieces. We don't buy something that processes transactions, we buy something that does that, and manages accounts receivable and billing and reporting, etc. We chose it because of the transactions (which it does a reasonable job at) but all the rest is a nightmare.
Think about it. If everyone adjusts their business processes to fit the software tools that everyone buys, how would any company have competitive advantage over another?
It seems so ridiculous to me that something that increases productivity (when done right) by such large amounts can be considered a cost that needs to be eliminated. Kill that goose that's laying the golden eggs. It's eating way too much food.

And then there is SAP, but that is closer to build it yourself than buying a ready software...

Exactly. What advantage is there to having to learn SAP or Siebel when they are just as complicated a custom program, if not more? Somehow, it makes sense to spend twice as much to get a worse result.

Think about it. If everyone adjusts their business processes to fit the software tools that everyone buys, how would any company have competitive advantage over another?

Sure, which is why I advocate buying software for non-core processes, and build yourself for the core - where you want your competitive advantages.
It doesnt make sense for a car manufacturer to try to have a cutting edge in tax reporting - but it makes a lot of sense to invent new and improved processes for assembly, and build software to support them.

I completely agree: invest money where you can achieve a genuine competitive business advantage. For other areas you may as well use an off-the-shelf solution (or as near to it as you can do). Its about striking a balance and getting a good return on investment where it counts.

When you develop an enterprise application for a company your main goal is to solve the business functionality. If you are an architect or designer or developer you will not think of building something so generic that it can be sold as that is not into your intrinsic or extrinsic requirement.
So in short enterprise application codes are worthless outside your company and many times outside the project.

When you develop an enterprise application for a company your main goal is to solve the business functionality. If you are an architect or designer or developer you will not think of building something so generic that it can be sold as that is not into your intrinsic or extrinsic requirement.

True and absolutely correct that they should not. It is not cost-effective to build a highly-generic solution. This is the mistake a lot of well-intentioned designers make, especially early on in their career.

Weather the code can be reused or not depends on what tht code is doing, if it has been written for a perticular business than one might have hardcoded business rules of the organization. business rules differs from organization to organization, so the code written for a perticular business might not be used out side of that organization, but still its
valuable for that organization
sudhir
jYog.com

Weather the code can be reused or not depends on what tht code is doing, if it has been written for a perticular business than one might have hardcoded business rules of the organization. business rules differs from organization to organization, so the code written for a perticular business might not be used out side of that organization, but still its valuable for that organization

Sure, business rules vary between organisations, but the overwhelming majority of variation is actually in parameters, not in rules.
Parameters (as well as rules) tens to vary with time within the same organisation as well, which means that it makes perfect sense to externalize them from code.

TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations technology projects - with its network of technology-specific websites, events and online magazines.