Fog Creek Software
Discussion Board




Re-using code

For some reason I'm not good at finding and using code written by others. I'm good at re-using my own, because I understand it and I like it and I know where to find it. I don't like searching and deciphering documentation and trying to figure out how to use something. My manager keeps telling me not to re-invent the wheel (even if I already invented it years ago). Even if it's something simple, he thinks I should first find out if it already exists.
I know he's probably right. But exactly how important is it to use other people's code, and how much time and effort does it save, in general? Should you ALWAYS look for existing stuff first, or only if it would be time-consuming to write it yourself?

PC
Thursday, June 13, 2002

aye, there's the rub . . .

Shakespeare
Thursday, June 13, 2002

Despite popular folk wisdom, the wheel has been re-invented many times over the ages. 

Imagine using an ox-cart wheel on your car.

Reuse has benefits, as well as disadvantages... as you point out, search time for something suitable is one of the disadvantages.

On one of my projects, I counted no less than 25 different unique functions for triming unused blank padding from a character string. 

Apparently our search patience is pretty thin.

Joe AA.
Thursday, June 13, 2002

That why component based software binary specification,
was invented. e.g. COM etc....

One need only understand the exposed interface ;-).

If the component doesn't serve your purpose, you either
buy another or create your own.

Simply concept actually

Looking Over Your Shoulder
Thursday, June 13, 2002

I agree looking... hope you don't mind me using your first name.

If we could all just understand everything that is (painly obviously of course) "exposed", then there would be no search time... we would just automagically "understand".

Kewl!!!... now why did I think there was a problem?  Uh oh, might just be that less than perfect world I seem to run into.

Joe AA.
Thursday, June 13, 2002

Hello there, just joining this neat place. Thanks Joel for fine articles.
Back to reuse... What size of projects are you talking about? IMHO things are all different in those fields. 5 places of trimming spaces in large software may result in megs compiled code, dozens of bug and tonns of maintainability issues... Well, good-big-company-with-Booch (Rational) creating RDA ( www.rational.com/rda ), MS does other things, but all this tends to be efforts to formalize and structure Knowledge Management (KM). [btw] Joel, do you have an article on KM? [/btw]
Reinventing the wheel is dangerous thing in my opinion. You can easily miss something. And you code will work, but slower, not in all cases or whatever...
The real thing is to think of HOW to lower search cost. And HOW to make knowledge creators put information into system.
I see Joel giggling on my post :-) Saying, "Hey, man, try using your personal news server for KM, full search is good".
Not really so. Many buzzwords are heard about it, like that the major parts of KM are cross-references, automated keywords assignments and other cool feature you can imaging. In my opinion REALLY good KM software will give you information you NEVER placed into it :-)

Have a nice KM!

Orangy
Thursday, June 13, 2002

Software is fragile.  It's doesn't take much of a shift in context (os, compiler version, 3rd party lib versions) to break it.

A statistic I've seen quoted is "if you have to change more than 20% of a piece of software in order to use it, it's faster to rewrite it".

IanRae
Thursday, June 13, 2002

I think the decision to reuse (other people's) code has to be asked on an individual basis for each case, because there are a lot of issues involved.  A few of them include:

Pricing.  Is the functionality of someone else's code worth what they charge for licensing fees (if they do, in fact, charge?)

Time saved.  Will you really save time?  There are many different skill levels of programmers/designers out there.  You might find some reusable code that is well implemented, but is poorly designed, or code that is well designed but poorly implemented (inefficient, etc), or some that is both.  It’s fairly rare to find code that you can reuse that is both really well designed and implemented well.

License issues.  The Open Source Software model has created tons of reusable source code available for use by virtually anyone.  Some of it total garbage, some of it quite good.  Of course a primary issue here is license concerns.  Many businesses are reluctant to use GPL or even LGPL code, and IMO for good reason (at least if they are your standard shrink-wrapped software company).

I think there really is something to the "not invented here" attitude programmers are often accused of having, but on the other hand I think that in practice, most source code isn't as reusable as people think.  For all the hoopla about architecting completely flexible, reusable software, this is rarely done in the real world because of very real business constraints (time to market, cost involved, cost of hiring great designer/programmers vs good-enough ones, etc). 

My only advice is to look at it on a case-by-case basis.  If you're building a network aware Operating System, you'd be a fool not to at least consider using the BSD TCP/IP stack, but on the other hand in a lot of situations you'll spend more time trying to understand someone else's half-assed kludges than it would take for you to create your own half-assed kludges to accomplish the same thing.  As with most things, experience is the primary teacher as to which situation you're in for any given piece of software.

gmcbay
Thursday, June 13, 2002

Also, you could try the search on this forum (see that small box to the left with a ">" button near it?)

Check this old discussion thread:
http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixPost=112

Orangy
Thursday, June 13, 2002

I was having the same opinion as you in my early days. From My experience I've found out that reusing code is one of the best things because that code is tested and verified. So the amount of bugs will reduce.
Some body up here are talking of "ox-cart wheel for car", which I think is not the problem with most of the cases. Unless you want something tailored specifically in terms of performance point of view. I don't see any reasons otherwise why reuse is bad.
Looking at other people's code will definitely increase your ability in terms of understanding. It can also be that the code must have been better implemented than what you are about to do.

RK
Friday, June 14, 2002

Well, nothing is black or white, everything is grey.  And nothing comes for free.

Reusing another one's component is a good idea, but you may be firing your own feet.  That component may be unadecuatelly documented, may be doing its own assumptions of your environment and may introduce some nasty dependencies you will be unaware of...

So take anything with a pinch of salt.

Juan Lupion.
Friday, June 14, 2002

cum grano salas

One of the few things I remember from latin.

I think also that the size of what to reuse has an impact also.  I would probably reuse in the case of the TCP example above... but probably not for the remove blanks from string example unless I knew exactly where it was and that it worked.

Joe AA.
Friday, June 14, 2002

It's not a cut and dried issue. It depends on many things including politics and legal issues.

For example:

I have my own linked list library. "You must be crazy" you might say "There are thousands of good list implementations out there".

Well, linked lists are used in a lot of my other code libraries. And my linked list is very robust, very well tested, and in plain vanilla ANSI C that compiles on everything. Sure, I know there are other linked lists out there but I own mine 100% and it works for everything. Call me crazy, but it works for me.

A lot of the time I will write something that I know for a fact is already out there.

Another example, I have my own malloc. I have a theory that the best programmers all have their own malloc.

BUT I do this only when I am to be the owner of the code. If I am working for the occasional client who insists on 100% sole ownership of all code, I do not use my own code libraries. I start with whatever I can find in the public domain, or that the client is willing to pay to license, and I modify it. I have no problem doing this as long as I am paid by the hour.

I think it is a smart idea to, whenever not under contract that eats your IP alive, to build up a portfolio of your own IP, even when it means reimplementing things. I have my reasons for this.

One of them is that it makes me a better designer and the benefits outweigh the costs.

This approach is not for everyone. For one thing, you should be able to write better code than the free code libraries that is out there.

X. J. Scott
Friday, June 14, 2002

I often use existing code, when I think it will save time, or when it's something I don't know how to write. But I don't necessarily see the point when it's something simple, or when you already wrote it and have been using it for years.
I started web programming in 1995 when not much was available, so I wrote things for my own use that are available now. The result, I think, is that I learned some of the basic concepts of web programming that I might not have learned if I had started more recently. I'm not sure if this is true or not, but I think you learn a lot by inventing, or re-inventing. You can also learn by using someone else's code, I guess, but in general you don't learn anything if it's really easy to use. The result is you don't understand the underlying concepts and in the long run you won't be as good. This is just a theory, subject to change.
Of course there isn't time to understand and learn everything and I have no desire to write everything myself, and of course you have to make a decision for each particular case. I guess my question is about the attitude, which is so prevailent, that you should always use what has been contributed to the open source arhive.

PC
Friday, June 14, 2002

I think code reuse only works for very small or very large modules. The STL is a great example of small-time reuse. Microsoft's MFC is an unpopular example of large library reuse.

Any medium sized modules either have too much hardcoded knowledge (too big) or are an incomplete solution (too small). I think design patterns are a good answer to medium-sized reuse. As "mini-architectures", design patterns do not have the hard-to-rip-out hardcoded knowledge from their previous application use.

Banana Fred
Friday, June 14, 2002

Design Patterns aren't (strictly) code; they are designs.  I find that they are rarely useful or reusable in client/supplier relationships when implemented as code.  Instead, they seem much more useful in an inheritance regime, especially when multiple inheritance is supported.

PatternPunk
Friday, June 14, 2002

I'm a software engineering student at Milwaukee School of Engineering, and several of our classes (educational not code) stress code reuse.  In a classroom setting this makes sense, but even one of our intructors has told us that in the real world, code reuse just doesn't happen.

Hohle Cow
Monday, June 17, 2002

One of the problems that I find when I'm trying to reuse some code is that even if the code is documented well, or written in a style where little documentation is needed, it can rarely be used as a black box. The dependencies, assumptions and 'soft' requirements are rarely documented and often at odds with those of the project into which the code is being inserted.

The code might be in C and my C++ sensibilities might be offended by how it operates. It may use exceptions and I might not wish to. It may use the C++ standard library, MFC, ATL, etc and that may not fit with the project that I wish to use it on. The error handling may be inadequate, there may be bugs, the code structure may be offensive. It may be optimised for speed and I need it optimised for space, etc...

The good thing is that by the time you've worked out all of this you've reviewed the code to the point where you can usually rework it into a style that fits with your project's requirements. If you can't then that adds more weight to the 'reuse as is and live with the consequences' side of the argument.

The bad thing is that it's not always easy to explain why you needed to do that to management who feel you could have just used the code as is.

Sometimes it's a close call. I've just been using some of Jeffrey Richter's code for windows performance counters from his Programming Server Side Applications book. His requirements and mine were a long way apart, but the code was complex to rewrite and relatively easy to wrap in a more acceptable interface. I wrapped it and used it as is. Now I find that I have a problem and his 'assert in debug builds' and don't check all errors "style" is causing me problems. I know that if I'd rewritten it in my 'throw exceptions on all errors and never assert' "style" that I'd now instantly know what the problem was rather than having mysterious crashes on one installation. So I'm in the process of reworking the code into my house style to help me locate the problem.

COM goes some way to help by restricting what you can do at interface boundaries and .Net goes further by assimilating the world. ;) But you still end up with the possibilities of the code you want to reuse having a poorly designed interface or inappropriate performance characteristics.

Add to all these "legitimate" reasons the fact that when we're at school and college we're always expected to create new and unique works rather than build on the work of others it's not too surprising that most programmers prefer to write new code rather than understand and use other people's code. I'm surprised any code gets reused at all...

That said, there's no excuse for having mutliple versions of the same code within a project (unless one area requires radically different performance characteristics than another) and code duplication should be agressively refactored away.

Len Holgate
Wednesday, June 19, 2002

Reuse is a means, not an end. If it saves you something like time or money (preferably taking into account the complete lifecycle of the code if you have the luxury to consider that), then by al means go for it.
As for the " ... our intructors has told us that in the real world, code reuse just doesn't happen", I am afraid that is a typical academic position focussing on very narrow definitions of "reuse". Everything that get's build into a foundation (OS, standard libraries etc.) gets reused a gazillion times. Many people have pointed out COM as a good example of a reuse vehicle that is very succesfull in the "real world". I believe .NET components and webservices will become even more successful as a reuse platform.

Just me (Sir to you)
Wednesday, June 19, 2002

*  Recent Topics

*  Fog Creek Home