A Position Statement:
Other people's code is better than my code. Even if it costs less initially, it's cheaper to maintain and a much cheaper way to add functionality. -- RogerHayes
A contrasting view:
Other people's code is worse than my code. I will spend more time doing costly experiments to understand how it works than I will just writing my own. However, if those other people are my teammates, and through constant communication and PairProgramming
, their code is as well known to me as my own code. Then other people's code is as good as my own code.
(Related to LegacyCode)
In favor of reuse:
If you can buy it instead of building it, do so. You can't buy back lost time.
The third party tools and libraries you buy will have bugs in them. In most cases, you can work around the bugs. But if you have the source code, you can track down and fix the problem yourself, and congratulate yourself for the excellent one-on-one customer service you provide yourself.
A contrasting view:
Even in the absence of bugs, third party software used in a manner different from the author's intent can be an ongoing source of maintenance problems. It can also be very difficult to reverse engineer and replace should the third party go out of business, not provide needed upgrades or enhancements, or change licensing policies. When looking at third party software, you need to look heavily at the long term and not just settle for short term convenience. If the shoe does not fit don't wear it.
is only any use if it comes with source, that way it enters your codebase and becomes just another piece of code that you didn't have to write from scratch.
In favor of closed source modules:
If you can put it where it's needed, now and in the future, and if it's reliable, then you can just treat it as if it were a piece of hardware...
A cynical view:
Hands up those who've rewritten MFC classes? Did you buy DundasToolkit?
because they did it for you? Whoops, they never tested their code once. Now you're screwed... What do you do? Roll your own because you don't have to be all things to all people; your code will work. And if it doesn't, at least you can fix it. -- SunirShah
I bought Dundas <sigh>. That's why I ended up spending time to learn sockets programming using the API directly. A week or two I really didn't have right then... Hey wait, that's why I bought Dundas in the first place...
An it-depends-on-the-code view:
This all depends on whether or not the code is good. If it works, you like it, and you can easily understand it, make modifications to it, and get help with it, then it's probably good to use it. Points are lost if it's buggy, it's complex, you can't change it, etc. Some times it's hard to tell if it's good, and you have to use your instincts. Other times it's obvious.
''But surely one of the points of XP that ItsYourCode?
. If you bring in a third-party component, then either you have the source (in which case now ItsYourCode?
) or you don't, and you end up either throwing it away or working around its defects. Maybe one of the advantages of OpenSource
is that you make the code your own and then (if you have the OpenSource
ethos) contribute the improved version back. Whereas if you bought compiled code (as in the Dundas horror story above) it remains somebody else's code, and if you
can't work around its bugs you just wasted your money. -- SteveHolden
An is-the-domain-a-moving-target view:
I work in valuing financial products. The underlying target of the code is moving all the time. By using OtherPeoplesCode
, I save (1) the initial cost of duplicating the package and (2) the cost of keeping up with changes in areas that aren't my speciality. (2) outstrips (1) in the longer term. I put more effort into making sure everyone can use each other's stuff as easily as possible.
On the other hand, I'm very happy to roll my own where I know things won't be changing all that much (e.g. a published API) and where there's not already a perfect fit to my particular needs out there.
What i see is that people don't like other code because it's not their code. Code is always written from a mental model and every programmer's model an implementation of that model are different. How often do people talk about good code? Hardly ever. It always has some flaw or over-sight.
Take a look at JavaUnit (I recommend JunitCooksTour) for an example of other peoples' good code.
Although I usually use it, due only to its widespread familiarity among other programmers, I don't consider JavaUnit
an example of good code. To my mind, JavaUnit
exhibits flexibility in certain ways that are frivolous, yet complicate the framework. But in other ways, I find JavaUnit
too inflexible to support the way I want to write tests. I also take strong issue with some of the class names. I see far worse code every day, but I would not hold up JavaUnit
as an example of good code.
Ah, but comparing it to code that doesn't exist isn't really fair now, is it? That's like saying, "Other people's code always sucks because I could always write it better." Instead, why don't you write a TestingFramework that you would consider good (or possibly refactor JUnit until it is up to your standards), and then show it to us as an example of good code (or maybe just 'better than JUnit')? In other words, show me.
So he shows you his ideal code. What are the chances other people will think the same? Thus this page.
Well I suppose it
is a view. But not a very useful view in my opinion. Kind of like solipsism or nihilism. So nothing exists, so what? Myself, I'm a pragmatist. If I can make use of it, it's good. The more useful the better. Other people's code isn't bad because it's not mine, it's bad because/if I can't use it.
It's not nihilistic at all. Something is being created. It helps to realize that try as you might you will not be adored for your efforts. You should need to have your own standards and don't look to others for validation. As for useful, ShowMe?
strikes me as less than useful because it just spirals the same conversation.
I was just using nihilism as an example of another view that is not useful. In any case, ShowMe? is an instance of OccamsRazor, which is the tool of a pragmatist.
Need More Than Just Source Code:
In order for source code to be usable it needs to include a build script and unit tests. If you can't quickly determine how complete and correct the source code is, it's pretty much useless.
A change log and list of known bugs is nice too.
An overview document, or even a whole website. (Imagine a well done wiki!)
Other People's Thoughts are Less Important than Mine:
Therefore my code is better than theirs.... QED.
The title is meant to be a joke. I don't think it is possible to talk about code as if it is a piece of gum. In the gum case if one doesn't like the flavor, one calls it bad and spits it out, no harm done. Code, however, is intrusive: it formats one's brain. As one reads and writes more and more code, the brain gets formatted in a way that recognizes very easily the patterns one uses most, and the brain develops a resistance to understanding code that does not follow these patterns. If one's brain hurts while reading a piece of code, one calls it bad code. It may not be the case; it could just be that the process of understanding of this code requires other nerve connections in your brain, and your familiarity with your own patterns makes the understanding more difficult. As with music, it is easy to say what you don't like about a piece of code and it can be hard to appreciate a symphony.
Besides, nobody has to use other people's gum, but pretty much all of us have to listen to other people's symphonies.
See also: SomebodyElsesFramework