Albert Wenger posted "70% of the Software You Build is Wasted
" last month. His core position: "At least 70% of the software you build is wasted because you are constantly reinventing the wheel by building components that do not deliver any competitive differentiation to your offering. You have to build them for the offering to work, but they’re things that everyone in your space also provides. Often, they are things that everyone in every space provides." He follows up with some claims about frameworks and multicore performance.
Going further (with edits adding line breaks for ease of readability):
I was having lunch with a CTO friend recently and broached this subject to him in a deliberately provocative way. After he got past my delivery, he sighed and commented that he agreed. Every new job he takes requires reinventing the same wheels all over again.
Another friend who is a marketing guy had exactly the same reaction even though he isn’t a techie. He knew exactly how much was being invested in Engineering to build stuff that he couldn’t put in a press release or otherwise tout. He referred to this work as a tax on innovation.
The non-differentiated stuff would just barely be average if you did it extremely well. It would be average because it didn’t matter that it be any better than average: it wasn’t a competitive differentiator. Therefore you couldn’t afford to make it better than average if you were focusing your business properly.
I find it incredibly bleak to consider that 70% of the lines of code being written will be average at best and will likely make no difference to the business.
Addressing the reusability of code, he wrote:
Code reusability is hard, as anyone who has tried to herd the cats (developers) all together towards some form of reusability or core technology will tell you. Every developer will loudly proclaim that code must be reused. They will immediately follow this up by demanding to work in a core technology group that will produce the greatest code for sharing since sliced bread.
What they’re really saying is, "Everyone should reuse code, but it has to be my code they reuse." Take any software developer who is well regarded by his peers, collect some of his code, destroy all comments and other information that would connect the code to the star, and give the code to another engineer telling him he has to use it or maintain it. The recipient can be a star or just one of the troops in the trenches, it doesn’t matter. In 99 out of 100 cases, the recipient will loudly proclaim that the code is completely unusable and will have to be rewritten.
Another interesting claim is that he says that "Curly Brace Languages" (Java, C#, C++) are used because they can talk directly to the hardware, because they can do things other languages cannot, and:
Because I get better performance (yes, but not in a multicore world where massive scalability not tight loops will rule)
He also says that object-oriented programming doesn't do much for reuse:
OOP doesn’t really facilitate code reuse very well. It isn’t service oriented, it’s about controlling the fine grained behavior of objects in intricate ways.
In fact, one could argue that it makes a lot of code much harder for someone to read and understand because of all the things that happen implicitly and in many and varied locations. Certainly anyone who has ever walked through a complex inheritance scenario using all the OOP bells and whistles in a Curly Braced langauge on code someone else wrote will tell you it was a harrowing adventure at best.
The old computed GOTO in FORTRAN has nothing on OOP when it comes to the power to obscure meaning.
His summary is reproduced here in its entirety:
What’s the Answer?
If you want to quit wasting 70% of your efforts on software, you’re going to have to discover a way to reuse code- preferably reusing code that (Gasp!) other people wrote anyway. Getting back to the service oriented perspective, true code reuse benefits from the service oriented perspective. Forget the Curly Braced Power Tool perspective for a minute.
Use the power tools to create the proprietary advantage that you currently only get to spend 30% of your time and resources on. Look for a simpler, service-oriented approach to the 70% of functionality that is undifferentiated.
Favor simpler service-oriented approaches without making them too simple as to be unworkable. This will minimize the amount of learning your developers have to do to reuse the code components. This is why REST is rapidly becoming more popular than SOAP as a protocol for Service Oriented Architectures. It’s simpler.
A lot of things succeed because they are simpler. C, in its day, was far simpler than Algol or PL/I or even COBOL. C++ was simpler than the overblown Ada. And Java simplified a lot of the issues that were on the C++ programmer’s mind. Now lately we see that scripting languages like PHP, Python, and Ruby have succeeded well because they’re simpler than the Curly Braced Languages.
There is no one-size fits all, so why not choose a couple of sizes for different occasions? Martin Fowler (author of one of my favorite books on Enterprise Patterns) puts it well when he says, "we will see multiple languages used in projects with people choosing a language for what it can do in the same way that people choose frameworks now." Or, as the Meme Agora blog puts it, we are entering an era of Polyglot Programming.
PS: While you’re thinking about Polyglot Programming, consider that the Multicore Crisis is going to start kicking sand into a lot of the old machinery sometime soon anyway. The Curly Braced Languages will be the ones hardest hit by it because they’re closest to the cores.
The scary thing here is that virtual machines like the Java platform and the CLR are actually in a good position to take advantage of multicore.
Using multicore hardware doesn't automagically provide performance boosts (two 1.5GHz CPUs don't give the same performance for a single task as a 3.0 GHz CPU), of course, because a single thread can't execute on more than one CPU.
However, languages like Java have a lot of concurrency capabilities that do provide a lot of performance on multicore systems - provided that the tasks are broken down into pieces that can be run in individual threads.
See "Multicore processing for client-side Java applications
" for an example of multicore processing for a sort routine - this is a simple task, of course, but the author (Kirill Grouchnikov) says that he saw a 35% improvement over the normal single-tasked sort routine with a multicore CPU.
A number of Java architectures aren't even tied to simple request/response handling. Even Java EE, with its use of containers for services like EJBs, can leverage multiple cores with very little interference from the coder; even servlet engines can farm HTTP requests to different cores as they're available.
JINI is an architecture designed to leverage multiple CPUs - whether they're on the same physical motherboard isn't important.
All that takes attention away from his initial claim, however, which is "70% of the software you build is wasted." What percentage of the code you write is reusable? Why? Is his claim valid or even meaningful?
The fact of the matter is everybody's code sucks except your own. That why nothing is ever re-used. What's more important though is that this doesn't matter as long as the tests are re-used. That's the real value of old code...
JBoss, a division of Red Hat
Hi, my name is Rickard. My code sucks.
Hi, my name is Rickard. My code sucks.
My name is Raffaele and my code sucks, too.
Hi, my name is Steve. My Code Sucks
Hi, my name is Steve. My Code Sucks
Good for you Steve!
See, knowing that your code sucks is pretty good. Then you won't squirm too much when you find out that it, indeed, does suck (and all code sucks, it's just a matter of knowing it or not). And then you get to toss it out the window and replace it with better code. Which still sucks, since you will empirically speaking eventually realize that it does indeed suck, but the new code will (hopefully) be better for the moment.
And so it goes, iteratively, forever-and-ever. Towards less suckiness and prettier code.
See, this whole reuse thing is so last millennium. Recycling code, that's the new shit!
Hi, my name is Martijn. My code sucks. I'm in my 7th six monthly rewrite and things are looking good. The code still sucks but much less than 12 months ago.
Hi, my name is Rickard. My code sucks.
Hello all my name is nobody , I am still in denial.
My exprience is quite a different one: I am just pure and simply lazy. The first thing i do, when tackle a coding problem: I ask myself has somebody solved problem domain for me already - and not only a code level. More often then not the answer is yes. I see myself a coding assembler of well tested, high quality components .... ideally ;-) The "assembly" is still complicated enough. And that's were testing comes in. So the test codes expresses the uniqueness of the assembly and can from my experience not be reused.
With regard to "everbody's code sucks except your own". If i would tell that my boss, he would probably fire me. Apart from the economical irrationality, the comment highlights a social aspect of reuse: Respect for the others works, a capability to share and participate in evolving code to address evolving requirements.
Basically not just a goal for coders, but social behaviour, and certainly for non soft engineering deciplines. Maybe we have here a culture problem?
Simple sites don't need the full J2EE suite :)
Maybe GoF has an answer.
Is it the usage of java.io.*, java.lang.*, java.net.*
classified as code reuse ?
No ? Why ?
Yes ? Why ?
I think that is more a matter of model rather than plain code.
Java packages such as java.io or java.net fall in the reuse
category because of the general suitability and acceptance
(and effectiveness, of course) of the model: streams and sockets.
And their "technological" nature.
More business-oriented SW is difficult to reuse for
several reasons, but, mainly because of the model.
But, certainly, architecture plays an important role.
In fact, rarely business-oriented SW is designed with reuse in mind (i.e. extended use of interfaces, a good spi design etc).
Overall, this isn't the worst article I've ever read but there are a lot of really specious and even absurd statements and arguments.
What industry does do a great amount of work on things that do not differentiate them? Every car maker in the world designs their own engines. And every car has an engine. Every house has a foundation. It's a total non-differentiator. The idea that all work that is done by an organization must be a differentiator is corrosive and really pretty stupid. The question to be asked is whether it's more cost-effective and strategically correct to do something yourself or contract-out and/or buy it. None of this BS about differentiation is meaningful. It's a substitute for rational thought and discussion.
And the argument that Java is a systems language because there's a tool kit that allows you to work directly with the hardware? Give me a break. Jython can use this tool kit and that makes Jython is a systems language. It's not hard to see that we can turn any language into a systems programming language as long as it can have bindings to C. Total nonsense.
Do something that actually works. That is what differentiates you from other products, not some marketing giberish about new and unique features.
Google has an input field and when you press enter you get some search results. Great, everybody can do that. So nothing there that you could possibly but in a press release.
Why on earth did they implement it in the first place? Totally pointless exercise.
I found this article rather uninformed.
Also when deploying an enterprise application you deploy 90% framework libraries and 10% your own code. And the implemented code most of the times just wires together the different frameworks. So the reuse is quite high.
I found this article rather uninformed.
I agree with everything you said except this. He's very well informed (by the wrong people.) What is lacking here is logical reasoning.
What I find so irritating about this is that I hear this kind of crap all the time from people who are so removed from the work of getting systems running that they think it makes sense. It's generally the argument used to ensure that millions of dollars are thrown away on some overrated package or SaaS vendor that doesn't address the crucial needs of the company.
The point of a company is not to focus on differentiation. The point of a company is to make money.
This new "curly brace language" term is one of the silliest I've ever seen.
And I'm also getting tired of this garbage about how developers won't reuse other people's code purely because it's not their code. Sure, there are developers like this but it's definitely not the case in general. Every time we use a framework we are reusing someone else's code. Every time we use a class in the JDK we are reusing someone else's code.
The real problem is that reusable code doesn't just happen. It has to be written for reuse and generally it will need to be refactored over time to allow for continued reuse. I reuse a lot of code written by people I don't know. A lot of it is crap and I still reuse it. But more more of the code I see cannot be reused effectively and the hardest issues to deal with are not coding issues (such as comments) because those are usually easy to fix. It's the design of code that makes it impossible to reuse.
A really good example is a something written by a former coworker that we wish to reuse. He designed it to take a fixed length message of 500 bytes. Now we have a 1000 byte message. That might seem like a coding issue but we can change the length to 1000 bytes but tomorrow we might need a 2000 byte message. So the answer is to go to an extremely large message size that we would never exceed. But that means we need 200,000 bytes to send a 50 byte message. In the end, the decision to use that fixed length message makes the code useless to other processes. No amount of yammering about how developers won't use other developers' code is going to change that.
It's a demonstration of a lack of understanding to argue that there is no other factor besides developer attitudes that is limiting reuse. This kind of attitude usually comes with assumptions that all developers are basically the same and that development is basically a brainless assembly-line of widgets.
I found this article not only bad but insulting. The broad statements like the title, "70% of the Software You Build is Wasted", with no real foundation, just shows how poorly written this is.
Lets look at his examples:
Many Java developers use ACEGI and thus have the reuse he speeks of. We were able to implement ACEGI in our application through configuration and only 6 lines of code. And the code was business specific.
Forms and UI:
all major framewoarks have components for creating UI, most with AJAX and other options builtin. Further, frameworks like JSF and Struts 2/Webwork allow you to build libraries of UI components that can then be reused in other applications. We have mannly used the UI components from the frameworks, but have had to make some changes to support governmant Accessiblity rules (section 508).
Database Connections and Persistence:
JPA - need to say anything more?
Not going to go farther. The article is mostly trumed up. Just because the language allows low level access to the machine does not man that that kind of programming is being done.
By using the very frameworks he dismisses we have cut our non business related coding dramaticaly. In one of our systems I ran a report on the code and found:
364,784 lines of code (in business rules packages)
301,211 lines in UI layout/validation regex
9242 total lines of now business code (color themes, new UI components, etc)
Note this is an enterprise system with Multiterabyte data sources and over 20 million transactions a day. This is a chived by using over 100 different tools including Struts 2, JPA, Spring, Acegi, Axis2, etc.
Your point is good. I have to say, anyhow, that what you describe is good programming but, too bad, spring, acegi, struts and a lot of other things are just optional. I mean it's legal writing your own security, mvc, ioc framework and people, even people without good programming skills, do it. That should be considered criminal and I think that is the "70%" of this article.
I got two strong points _against_ code reuse
1. you'll mostly have to fork: and then keep patching to keep up with the head. Things tend to go like this:
- You see that great-mega-yeaha-framework (say DOJO) and decide to adopt it.
- Some bugs appear into your webapp because of interaction problems (or event maybe because of framework bugs): you make a patch but cannot afford to make a 'general' patch, nor you have the political power needed to submit those patches to the original project
- you're done :-(
2. My business experience also tells me that about 40% the money we wast goes into keeping up with evolving framework. Something like:
- You want to write app A and write module Z (say: metadata search) because existing modules are real overkill to your needs
- Find another project (say B) where you want to reuse Z (not to reinvent the weel!!!!), so you evolve the module Z in Z+1
- You spend time factoring the module
- [wasted time] You spend time to fix A so that it works with Z+1
[lots of waste!]- you add projects C, D, E etc... and each time you must evolve Z+1, +2 etc... and back-port so to ensure bugs are fixed in previous apps :-(
my point is: avoiding bogus reuse is key as much as reuse!!!
Wenger's blog is drivel. He admitted on another forum that he just made up the 70% figure, but that's not the real problem.
The undifferentiated code he complains about is necessary to make your differentiated code work. Your enterprise application wouldn't work without the code or xml to connect to your database so you and everyone else has to write the pesky stuff.
Your car is full of undifferentiated parts. Engines, transmissions, wheels, etc. are all undifferentiated to the point of being intgerchangeable. But that doesn't mean that they don't add value to your car.
He is long on sloppy thinking, but he doesn't offer any solutions. Phrases like "service oriented perspective" and "Polyglot Programming" are neologisms, not solutions.
The numbers are hard to verify but seem to be overly optimistic about the actual code reused. I would say it is much worse than 30% reuse. Basically forget about reusing unless you actually planned what to reuse ahead (and what not); invested the time and money to make it happen; and then actually managed get your money back through actual reuse. Most companies don't manage to do this.
Planned reuse actually works extremely well and is the reason we can develop huge software systems while only actually writing a relatively small amount of code: 99.99% of the software you deliver to your customer was not developed by you or your team (OS, libraries, tools, application servers, you name it). The problem is making this remaining 0.01% a bit more predictable, reusable and differentiating. An additional problem is that those 99.99% are not cost free. Just maintaining them costs money.
This is in a nutshell Microsofts' problem: they ship 100 MLOC+ software in Vista; a small portion of it is actually differentiating relative to XP but they have to employ 10000+ engineers to keep the shit in shape which ends up sucking billions of dollars annually. Most of these people don't actually work on differentiating software.
If you do software products instead of projects, basically you are doing planned reuse. You don't write your product from scratch for each release. Instead you incrementally improve the product each releases. Many products start out as projects where the engineers figured out that they should be reusing the results of their previous project. Essentially your competitiveness is constrained by the size of the delta's you release + the differentiating power of those deltas + the ability of your competitors to keep up with you.
If you find that you are doing the same thing over and over again that is A) an opportunity to reduce cost B) an opportunity for your competitor to outcompete you or C) an opportunity for a third party to provide you with a reusable solution. Option C is basically how most software reuse happens (e.g. open source or COTS components). Option A is possible if you know what you are doing and are in a position to plan reuse of your own code and spend extra money to make it happen (i.e. that's the hard part). Organizing for reuse basically transforms this into option C (e.g. core reuse team or something like that). Option B is what happens if A or C don't happen and the missed opportunity is large enough.
An illusion of reuse is that you will free up resources. The reality is that you will put those resources to use doing different stuff in the same project. Basically this means you get more for less. That is good. If you reuse successfully, you will have more work, not less.
Another illusion is that you can change productivity. Productivity measured in lines of code is more or less a constant. Most cost estimation models for software development assume this more or less (some don't). These models tend to be quite accurate. What that means is you will get X new/changed lines of code per time unit. X does not change substantially if you change the programming language; methodology; or any other factor. What you can change is how differentiating those lines are. 1 million lines of code of Java do a hell of a lot more than 1 million lines of code of C.
For example ruby on rails like approaches basically generate a lot of code for you that you don't have to bother with yourself. This means that for usecases covered by it you can develop much faster than people who have to hand craft their ruby code. Basically rails is the result of planned reuse. A bunch of smart people sat together and figured out how to do more with less lines of code.
"At least 70% of the software you build is wasted because you are constantly reinventing the wheel by building components that do not deliver any competitive differentiation to your offering.
87% of quoted statistics are made up on the spot.
I am not getting it??
Why should I have to re-use, if my ignorant CTO is ready to buy more which eventually help consulting firm to compare newly graduated Indian engineering student to Tiger Wood in every major airport in USA. Re-use mean today is cut and paste, Google search , copy, Eclipse code styling etc.
There is no resue or agile approach as long as IT implementation business runs through igonarant people.
1. Look into optimized cache technology from Cameron Purdy where is it now? With Oracle and everybody know Larry's business style right, make junk code make companies to pay for it buy making them to buy it through back door bully channel. Recently GM decided to use Oracle Fusion as their middleware platform. Great story right, GM plus Oracle fusion = more lost on car business. They don't get it
2. You guys have seen this in TV right "You can build it we can help you" The company which we all depend for anything for our home. This company running their 2000 more shops in America with 30 years old code, they haven't even compiled that in last 20 years. Any new store they start they go to another place and copy the machine completely. They have re-usage :). Average American hardworking people pay for it through the service. They use average American people money for their third class products made in CHINA with American label, processed through 30 years old system and accenture tiger woods monitor that for US through their tiger wood accuracy BUILD ON INDIAN FRESH GRADUATES :)
Finally I am confused,
WHAT IS THE HECK ANYWAY REUSE???
WHY SHOULD WE NEED TO HAVE REUSE??
REUSAGE, ACCURACY, AGILE ETC only make sense if those concepts can play big role in SUPPLY AND DEMAND. Supply and Demand phase of IT enablement of business is controlled by people who win lottery in professional job where they are at that place just for the sake they went to some known school using their own money. Consulting firms are there at these people's door step to use their ignorance in IT knowledge and keep his job SAFE.
Yesterday's wall street news also have research about what another firm in America is doing to make sure their woman counter part from client management side get more comfortable in meeting so that they can capture more IT business by making them happy.
Again I am confused what the heck is code reusage???
Re-use mean today is cut and paste, Google search , copy, Eclipse code styling etc.
Sadly, this is too true, and leads to situations where one of the other main benefits of code reuse is lost. In actually reusing (and, more importantly, modifying) someone else's code, you are required to think
the code, and not just blindly copy and paste.
Re-use mean today is cut and paste, Google search , copy, Eclipse code styling etc.
Sadly, this is too true, and leads to situations where one of the other main benefits of code reuse is lost. In actually reusing (and, more importantly, modifying) someone else's code, you are required to think and understand the code, and not just blindly copy and paste.
It is since a certain amount of time that I am convinced that
SW development and more in general Computer Science is not for anyone.
I don't exactly how many, but surely far less than anyone could think.
Unfortunately, those not made for this job generally migrate in the management position and are tipically fascinated by that (stupid) sirens like "zero code solutions", "code generators".
And tipically love buying developers by the pound.
That apply those wonderful reuse techniques.
Where i work, when we are in need of a specific feature we FIRST check to see if it isn't already provided by an existing framework and AFTER that, if we find no suitable solution, we go ahead and build something ourselves. Most of the times we found that the features we needed were at least in part offered by popular frameworks so i guess that there is a lot of Java code that is highly re-used. Also all the percentages in the article can't be correct, and "curly brace language" sounds really bad :).
One of the best things that happened to me was back in about 1995. I was reading a C++ newsgroup and someone was talking about using a 3rd party graphics library. He said "Using 3rd party libraries make me look much smarter than I actually am."
That single statement reached me. Why was I rewriting things like linked lists all the time(early on in the career)? Why not look for libraries to help with the heavy lifting? We use jacks to lift cars.
That post forever changed my feelings about using code not written by me.
I do agree, for the most part, with this blog. Very interesting actually.
But on the other hand, things have improved a lot mostly since the internet became widespread. I guess that before we didn't know that we were writing the same thing someone else has written thousands of times.
Let me give you an example. Our product, jbilling, is many 100K lines of code. Yet, this is just a puny fraction of the total code involved in the final product. There are literally hundreds of other open source components that jbilling uses (depends on). Hibernate for example. But hibernate uses dozens of other open source projects as dependencies itself, and so on.
I do see this as something that did not happened before and has increased a lot the amount of code reuse: the internet and open source have helped a lot.
The Enterprise Open Source Billing System
I am anticipating better OSGi tools, e.g. Spring OSGi, increasing code reuse, but will have to wait and see.
I'm also not sure that code reuse it that important in the scheme of things.
30% reuse is ok, so long as I can still build, say, another 40% fairly quickly, leaving, say, 30% specialised domain logic to write -- which must be written from scratch usually anyway.
Typically ever project differs wildly from the last, and so code generation tools to get the CRUD stuff out of the way, and the ability to copy/paste infrstructure definition into your project (e.g. copy/paste spring config files) deliver a lot of bang for your buck.
There are several problems with focusing too much on reuse:
1) The "you have a hammer" problem: You may end up trying to morph the solution to make it "look like a nail" to your existing code "hammer", even if that's not the best architecture to solve the problem.
2) The "whoops, side-effects" problem: The existing code you try and reuse was perhaps written for one specific purpose. Adding it to a different project will probably have side-effects you either have to code around, or end up copying the actual code (as others pointed out) and change it in-place.
3) The "snowflake" problem: Most projects have enough distinct requirements to make them so different that it often makes more sense to write something from scratch to cover a requirement than to spend time figuring out how a stack of libraries can be persuaded to work as a solution.
4) The "shelfware myth" problem: This is where some Oracle, IBM, etc. salesman convinces some director that the components in their "shelfware" app-server solution beats writing custom code. People, they do this because they know the "snowflake" problem! They want to sell consultancy when you inevitably need to try and morph the expensive and under-documented "shelfware" product into something that matches the customer's requirements and desired look.
5) The "who pays" problem: Writing the code in a way that makes it suitable for reuse (solving a range of potential problems) often requires more time than writing code that solves one particular problem. Who pays for extra time? It's not in the original customer's interest. Does the dev company take the expense and factor it into later projects that may reuse the code? And does the project actually have room for the extra time required?
What is really needed:
1) Well-documented libraries written from the ground up to be general and supportive
2) Effective use of best practices - like patterns.
Reusing library code makes sense in a lot of scenarios, but by not writing a solution to a problem yourself (just because someone else already did) you lose an opportunity to practice coding. Are you a programmer - or a plumber trying to fit pipes (existing code) together?
...between code reuse and code use. Using something like java.io.* or whatever is *not* code reuse... it is code use of an existing library. Code *re*use is where I have some code written for one task and find I can adjusted*(thru OO techniques or otherwise) for another task.
It's difficult to estimate how much of my code is reused because I don't know how old code of mine is being used - if it is. I can say that as my skill has grown my code has become increasingly more modular. Applications are built from small modules that perform preferably a single task: these modules are put into libraries.
This article covers a lot of ground. It makes statements that developers are averse to re-use. I disagree.
The notion that developers only re-use their own code is absurd. Novice developers write more than they should but experienced developers find it tedious re-inventing the wheel. Anybody still write linked lists for each application? How about Window classes?
This notion has a small kernel of truth. There are times when controlling the behaviour of a re-usable module is so deleterious that it's more cost effective to write your own module. Making this judgment call should help save time and effort (presumably saving money) for initial coding and overall maintenance.
Articles have been written - search ACM or IEEE Computer Society's digital libraries - about re-use in the small vs. re-use in the large. Overall re-use of small, well-defined modules has been successful. Re-use in the large has not been as successful although individual success stories exist. Hypotheses have been offered on why re-use doesn't seem to scale but I don't remember the authors having specific recommendations.
My experience says that frequent enough occurrence of corner cases as well as difficult to manage interactions between modules both cause problems: i.e. as smaller modules get combined into larger ones, the interactions expand the outcome range so that a lot of coding has to be done to prevent errors from unwanted outcomes.
The trend towards buying business applications instead of building them is an argument that re-use is occurring in the extreme large. Organizations are buying pre-fabbed systems and extending them to customize for their own practices.
Re-use has different meanings and, to me, all are valid depending on the context. From posts I've read so far, re-use means:
1. class extendability
a. taking the source from a working program,
carving out unnecessary code, and adding
application specific code
b. copy/paste code from one program to another
3. use of libraries.
While 2. is my least favorite it can work in the right work environment.
To me 3. is absolutely a re-use of code. Just because it's a linker adding compiled code to an application (or adding a call to a dynamic library), code you didn't write is still being used.
To me, this post is controversial because re-use is occurring and developers are not averse to re-use.
As other have stated, you really don't have a clue what you are talking about, nothing stays static certainly not in OSS libraries e.g. Log4J mutated into Logback (with some critical incompatible features). My single developer common code has to be refactored and replaced because new demands are placed on it. I even have to replace classes, in external OSS code libraries, because they are not flexible enough for a config-based swap-out, luckily Java and the JBuilder merging jar builder make this dead easy.
After reading your article, i am a little confused whether you are talking about code reuse or system/sub system resue? I disagree with you that developers are bad at resuing other people's code, on the contrary, i believe developers are pretty good at using other people's code. However, where i believe the problem arises is that the business analysts and system architects might not be doing a proper analysis and system design job. If the business requirements are properly documented and sub systems well identified, sub systems can (and i have first hand experience of that) be built to be reused in future projects. All you need is to properly identify your subsystems and have proper interfaces to talk to the subsystems, and only then will u achieve a much greater reuse of code.