An interesting read
 

...discuss :) (Especially those out there using other people's code!)

-Kitriel

Re: An interesting read
 

A good read indeed.

The last little paragraph, about 'your own people being more incompetent' applies to MUDs, though in a less harsh way. As a hobby primarily filled with non-professionals, you are often going to run into situations where you want to run a MUD even though you lack the competencies to secure competitive advantage in any area. That's because unlike a business which is run 'for-profit,' many MUDs are made because making and running a MUD is fun. It's like teaching your child to ride a bike. Sure, a professional instructor might do it 'better' but the experience itself is worth far more to you.

Re: An interesting read
 

It is just some blowhard rambling. Code reuse may be worthwhile, but it depends on the context. Now tell a few interesting stories about Microsoft development, add a few disclaimers to avoid the negative nancies from imagining meanings that weren't there, then ramble confusingly.. ta da.

Re: An interesting read
 

It is a good thing we don't have any of that here :D

Re: An interesting read
 

I'm glad that you know, the first step is admitting it, after all ;)

Re: An interesting read
 

The last few paragraphs do seem appropriate for any type of software development company - but not for other companies. And not for hobbies like Elvarlyn said. Unless you are a full blown company doing MUDs 24/7 for profit, then we need to see this as the hobby that it is. And code reuse is a good thing. (As a side note, I've often thought that's what really happened to MUDs in general - back when they started, there were few fantasy commercial games out there and kids loved playing ANY type of game they could. They didn't care if it was done by a hobbist or a commercial venture. Heck - back then you couldn't TELL if it was a hobbist or commercial venture. But 20+ years later, our there are tens-of-thousands of commercial games of all types out there, all of which have some sort of flashy eye candy. And you can completely tell what is done by a hobbist and what is a commercial venture. And a hobbist game no longer cuts it, so our genre has just withered by the way side. :()

But back to the article - It's also ironic that this was written 9 years ago. Flash forward those 9 years and everwhere you look we have exactly what he talks about in that big paragraph near the end: "trend virtual" companies. Even software companies - I would bet that there are less (percentage wise) companies out there writting their own software.

Re: An interesting read
 

Yeah. You have seen a few things in the last 9 years:

1. Libraries that solve "most" problems, even the flashy, "ooh, lets make pretty graphics no one has seen before", stuff.
2. Better development systems, so you can reuse code easier, and understand how it connects to other things.
3. The realization that just because you remove dependencies doesn't mean your product won't have as many, or more, crash prone bugs as the next guy, and its actually *easier* to fix those, if you have a clear concept of what goes in, and comes out, of the module, as apposed to rolling you own, where you may miss something "hugely" critical.

And that is just in the software end of things. To some extent, this can work with business models too, though, the point of the article is still, somewhat, true there. Just not for the reason imagined. You tend to get one of three sorts of companies - 1. Those that see support as an expense to be minimized, run scripted support, and try to get you to give up, before solving the problem, since solving it costs time, which costs them money, 2. Those that are just not competent at fixing your problem at all (AOL for the Apple II, back when you had to use dialup clients is a good example. You sent an email, and a) the reply email auto-deleted, so you had no way to talk to the original responder, and b) every question they asked you ignored what you where talking about, and/or assumed you where connecting from a PC, so could give them bloody direct information about what the address and folder was the file you where trying to download was in, something the Apple version didn't let you see. Its was simply not possible to *get* support, unless you where on a PC from them.), 3. Those willing to spend the time to fix an issue, even though fixing it costs them money (More common from, say.. a smaller ISP, than from the guy selling you a $300 piece of software).

Luckily, unless the problem is something that keeps you from getting online at all, you *may* be able to find a forum some place where people talked about the problem and how to fix it now. lol

But, yeah. The article was a bit over the top, and I couldn't help note it using an MS product as an example... Today I doubt Excel is any less intergrated with external junk than anything else they make, and nothing they ever made was ever what I would call.. stable, even when they tried to avoid those dependencies, and recode stuff every time for each application. ;)

Re: An interesting read
 

An interesting *topic* but not that great an article. The author goes from one simplistic view (code reuse is always good) to another (code reuse is always bad unless you're surrounded by monkeys).

Color me complicated, but I think it all depends.

I happily put low-level (network & other hardware-talking) libraries to use -- those are generally written by accomplished coders and the fact that they work is enough to give them a passing grade.

On the other hand, I've often had to make a judgment call not to use a free plugin/snippet for my project when I saw it would take me less time to write my own than to decipher what the plugin coder tried to do and the various ways in which it has to be mended or adapted to suit my needs. On several occasions, I've regretted using free code as the process of integration seemed to take longer than doing it afresh.

In time, I suspect that anyone develops a sense of what they should and should not try to reuse depending on the nature of the project, the nature of the code component, and their own level of comfort with this kind of code. It's a bit odd that someone with a long track record as the author of that blog post seems to have not developed any such sense.

Or maybe he reached the conclusion he did because he's so good at coding that everyone else (including us) looks like a monkey. If he's that good, I'll gladly reuse his assembler instructions in my next iPhone app!