- Buy an off the shelf program and take 3 hours to read their proprietary API for extra functionality. Then learn that you cannot integrate it into the current system (because of licensing, data format, missing features). Since you cannot make changes to the off the shelf program, you have to rewrite most of the existing code, just to satisfy the programs expectation. Or spend a month writing software that does a two-way sync between the proprietary API and the current data. Then learn that the API documentation is not complete/correct, then that new versions come out once a year - whether you need a bugfix or not.

I agree with the rest though... if there is a library, use it. Pay for it if you really need it. Just make sure you can modify it when needed and that you can do what the api/docs says you can - otherwise the software you bought is worth nothing as soon as you hit a problem, or you spend more money working around the problems than rewriting the software from scratch would cost.

I think there is still a valid trade-off in purchasing - it just has to make sense, is all. If the problem is big enough that it's unwieldy enough (ie. take too long to develop and TEST internally), then it definitely makes sense to investigate 3rd party options.

That said, developing internally is sometimes the only answer: when you don't get a good feeling from the 3rd party options (based on research), when the 3rd party cost is too high, etc.

Of course... it's usually more fun to develop internally. :)

From my experience most programmers I've worked with don't understand the underlying mechanism that make their tools work. And when they hit a bug or a problem their tools weren't designed for, the shit hits the fan.

And I've seen the reverse of what you're talking about quite a lot ... developers or managers choosing off-the-shelf software with no clue of what they are choosing, just to spend countless resources and important amounts of money ... later to realize that it doesn't fix their problem. But they use it anyway, adapting the problem to the software, just to get a return of investment ... which is the most idiotic thing one can do. But it happens quite often, especially in big companies that get lured by salesmen with promises of greatness.

Another thing that happens is that quite often I've seen situations where inventing the wheel is faster than using something prebuilt. That's because software development is not like lego-building. Many times you'll find a module that's close to what you want, but it's not good enough. So you start fixing that, and then you realize that the mismatch is greater than what you thought, and you lost more time than doing it from scratch and keeping it simple.

And more to the topic ... the first rule of programming is there are no rules. What works for one project, doesn't necessarily work for another.

Also, developers that consciously and constantly try to "keep it simple" and "not to repeat themselves" are doing a pretty good job at not reinventing the wheel anyway.

I've almost always written something that has less features/worse code/more bugs than a library that would have been a perfect fit. And I did it intentionally.

Why?

Because I learned something new. I've written my own C++ DirectX game library... then went out and used HGE/Goblin 2D. It made me a better programmer because I understood why the design decisions were made because I had similar problems when doing it myself.

I've written my own PHP framework. Why? Same freaking reason. I can look at similar frameworks, CakePHP/Django and quite literally see what it was they were doing under the covers without looking at the source because I've solved the same problem myself.

In the event that there isn't a third party library out there that does what you want, the programmer who is accustomed to look for those first will be screwed. They've never had to make a large system by themselves and they don't understand ahead of time what types of problems they'll run into because they've used other frameworks that have prevented them from making those mistakes.

tl;dr; Using a framework just because its there is similar to a parent coddling a child. When its time to enter the real world they simply won't be ready.

The anecdote here, I believe, is knowing when doing it yourself is a great learning experience, vs a COMPLETE waste of time. Always doing it yourself is stupid, but never doing it yourself is the easy way out.

Merely my $0.02.

I don't think anyone would write a web server unless they were in that business. But if they were, they wouldn't simply pick up Apache just because they can.

There are always at least two correct sides to every argument.

THINK before you SOLVE.

A natural tendency for programmers/developers is to move towards a knee-jerk reaction of "I'll just start coding this". It's not that good solutions don't come up from that line of thinking; it's more that - as cyman states - there are faster ways to accomplish results if you simply think about how you're going to solve the real problem(s).

Once a problem is analysed and broken down into it's appropriate tasks/needs/requirements, sometimes a credit card solves the problem faster (and better).

Oh, and when you purchase solutions, you typically can investigate APIs and system requirements beforehand. Even after purchase, most reliable solution vendors offer support/money back guarantees.

There is the other knee jerk (and a dangerous one) to do the reverse and just use off the shelf kit for large swathes of functionality.

We have one contractor who did just this and it currently the project is 3 months overdue as he is reworking large portions and sections so that it can do the things we originally asked of the program ;)

Formulate your approach then decide what can use pre-built packages and what needs to be hand coded.

"Dont program" can be as dangerous as "knee jerk" programming.

There're costs and benefits both to implementing something yourself and to using an off-the-shelf solution. It's a given that if you do something yourself, it will take 3 times as long as you expect, and you will be finding, tracking down, and fixing bugs long after you thought you'd be "done". And then if you bring in other people to help you, they'll all have to go through the same process.

But using off-the-shelf solutions has hidden costs too. Abstractions leak; that 3rd-party library never completely shields you from the complexity it purportedly solves. There may not be docs, or they may be incompletely specified. You'll probably have to spend some time customizing it, and your customization code may often end up more convoluted than just reimplementing from scratch. You'll probably run into incompatibilities between different libraries. The libraries may themselves have bugs that you have to dig in and fix.

Worse, reliance on off-the-shelf solutions often warps your product so that it fits the solutions you have available. ("When all you have is a hammer, everything looks like a nail.") As much as people say that they'll figure out the problem first and then pick solutions to solve it, the choice of solution then feeds back into the types of additional features you can add. If you decided to use an RDBMS early in development and then find you want to add, say, clustering of related items where "related" is defined by a fuzzy matching function, you'll likely say "This is too hard" and fall back using an exact match, one that can easily be stored in a relational table. Users suffer.

Obviously, a blanket rule of DON'T PROGRAM is wrong, because many successful websites throw away all the off-the-shelf solutions and write their own. Google's probably the most obvious one. I'd amend it to "Carefully consider the infrastructure you'll be using, and only reach for the third-party solutions when they save you significant time and complexity over doing it yourself."

Consider keeping such a chunk of code around only long enough to get the product shipped and paying for itself. At that point, make an attempt to justify keeping it around, especially after seeing how it fits into the big picture of your product.

I will say this -- the first step to not writing too much code is to reuse your own "internal" code. It's simple; instead of cut-n-paste-n-modify, make it a library, and make the per-app "modification" some different parameters you pass to the library. Now a bug that affects all the possibilities can be fixed everywhere at once. And, if someone understands one app's usage of this library, they will understand the other app's usage, as well. Less to think about, less code to maintain, and nothing to buy.

The next step is letting other people fix your bugs for you. My last job was for a company that routinely factored out part of their apps into community libraries. If you use Perl, you probably use Moose -- that was a piece of an internal app at one point. Releasing that bit of code changed the entire Perl community, and it made maintaining our software even easier. There are plenty of times I've hit a Moose bug only to have it fixed in 30 minutes by Someone Else. (To be fair, I've fixed other people's Moose bugs too.)

So anyway, the word "reuse" is thrown around a lot, but it is really an important concept. I have reused every piece of code I've written in the last few years -- once in my application, and once in the test suite.

If you're not reusing your code at least once, you're doing it totally wrong. If you're not reusing your code more than once, you're missing out on a lot of good things.

I may use several libraries, but I lean heavily on platforms; for instance, I have no problem using what's in /usr/lib from a typical Linux distribution, or the Python standard library. This keeps deployment pretty simple, and I can rely on well-tested components that are widely used and unlikely to go away. The platform libraries are also usually free. And I can ask or hire anyone who knows something about them.

While I don't rule out incorporating another library, this is definitely not a rule of programming. A 3rd party library has to do a lot to justify its added deployment complexity. After all, maintainers will have to read through API documentation just to figure out what something does, and this shouldn't take more time than it would take to read through my own implementation of the functions.

Top Three Rules:

1. Before you start writing something, make sure it'll actually reduce workload in the future. (laziness)

2. Borrow liberally from others -- especially open source code -- because that's the quickest way to success. Why waste time rewriting stuff that others have written, when that'll take three times as long and require lots of testing? (impatience)

3. Eventually write your own version anyway, because you can do better than the other guy. (hubris)

The first is what ensures you're writing software that should be written.

The second is what ensures that you write robust software with reasonable efficiency, and what protects you from getting a reputation as someone who badly implements a lot of cruft that someone else has already done better.

The third is what ensures that you improve as a programmer, rather than just getting into the tired rut of playing Legos with other people's libraries and never learning anything new.

It's all good, if it wasn't for one little problem. Unwritten-code is non-functional. Until we sit down and spend weeks --yes, weeks-- working on it, it's absolutely useless. What is worse, once we start getting better clarity on the domain, we start to understand what those architectural bumps were on the original codebase. At best, our new architecture will be better than what existed before, but our codebase is yet to be tested on the wild.

Oh, the wild, the proverbial real world where code is tortured in ways that we failed to imagine. If your code runs on a server, you may be lucky. Given the continuous feedback, you can patch it and evolve it, effectively reacting to the environment where your program runs. But if you pack it in a released form and part with it, then you're in for a ride.

There's a few rules to heed when rewriting something that's readily available, they are:

1- You are an expert in the domain of what you're rewriting. You're only an expert iff you've written the previous codebase and maintained it for years or you're an user of the codebase and worked with it for years. Yes, years.

2- You have the time and disposition to claim ownership (design, implementation, unit testing, functional testing, maintenance) of this code. It's like having a baby, you have to see it through College.

So, what to do? Write new functionality using existing parts. The value is on the new parts, and since they're new, there are few or no experts, and anyone can go ahead and explore that vast unknown.

Eventually, something will happen to render that line of code incorrect; either another line of code, changes to other code, changes in the tech stack or 3rd party libraries, and even the domain may change out from under your code.

Here's a typical example, one I just ran into today. For a course, I need to enter some data into some system that stores grades. It doesn't just store grades, though, it tries to calculate grades--by various rules and heuristics, which you are likely to misunderstand. They have written a lot of code for the import process, to, you know, take the burden off the poor teacher, by calculating the grades.

Of course, it's such a pain, and so error-prone, the much easier solution would be to just make a spreadsheet containing the grades and upload it, and have the program do nothing but display the results or whatever actually needs to be done. That would remove 95% of the code written for this thing. And make it work better.

Another one, which I ran into a few weeks ago. I needed to add a class. The professor needed to approve it. The software was so confusing, the prof couldn't figure it out (he is a world-renowned professor of computer science, BTW). After a couple weeks of this, I finally got a sheet of paper and had him sign it. I brought that sheet to the expert in operating the mysterious System, and that finally got the job done.

Some software does obviously help the university run better. Every line of code after that makes it run worse.

Write code to solve the core problem. Don't write code for the rest unless it's really needed.

What I have experienced in commercial environments:

- Software make/buy decisions are rarely made by programmers, but are made strategically with programmer input.

- "Everything else (95%)" can be many things. Sometimes you can plug in standard stuff (utilities, human resources, accounting), often you must write original code to handle your company's proprietary processes.

- In theory, existing libraries and frameworks are great. In practice, sometimes they make sense, but just as often they force you into a dead end. It may be tough to code at a low level, but the advantage is that you can almost always do what's needed.

- Having source code and being able to do something with it if often a huge competitive advantage. I forget how many times I've witnessed M & A scenarios where the acquirer bought the acquired because the former was able to change their business software on the fly and the latter had an unchangeable package.

If someone else has solved the same problem, use their code. If your problem is different enough, solve it yourself.

Knowing the difference is the hard part.

Also, sometimes the problem actually is "Purchasing a complementary solution will take 6 months of managerial approvals". The solution is to build it yourself.

If everybody would reason the way you did then we'd be stuck at version 1.0 of just about everything because nobody would get off their asses to do something new every now and then.

So it's a treshold problem. At some point the tension between that which is available and that which has to be done becomes so large that someone will stand up and says 'let's fix that, once and for all'. This person will then put in an enormous amount of time on top of what it would probably have taken to fix just the original problem.

And that's exactly how progress is made in the software world.

So, the premise you make is an idealistic one, in an ideal world, such libraries and bits and pieces should be available, for sale, well documented and 100% applicable.

In reality that is definitely not the case.

You are right that many people will fall for the 'let me do that' temptation when in fact they would be better served by using something off the shelf.

To keep your engineering analogy alive: If an engineer working on a car even could go and make his own bolts then that would be the road to total madness. There is lots of standardization and materials knowledge available to 'hard' engineers that is simply not there for 'soft' engineers, and because the price of the tooling is essentially zero the threshold for re-implementation (hopefully in a novel and better way) is very low.

Maybe it's too low, but that's a policy decision, not a technical one.

And if you are not under a deadline and simple trying to get the hang of stuff nothing will teach you better than to re-implement some of the better understood algorithms, especially queues, lists stacks and so on.

These are the staple of many larger structures and to understand them well (and how tricky they are to get right) is essential knowledge.

So, I'm not sure people are doing what you are saying.

SOLVE PROBLEMS.

Sometimes you do this by programming it yourself, sometimes by doing it off-the-shelf, but if at the end of the day you've solved someone else's problem, they will give you money.

By the way, the nr 1 rule is: context is everything. The nr 2 rule is: keep it simple.

But when integrating, I do prefer to wrap the integrated thing within a simple layer or wrapper, if feasible, that only exposes what I need. That buys me several things: it makes the interface very simple; I can create tests that verify my expectations; I can replace it later without having to clone someone else's API; and the API of the wrapper is almost a bullet-point list for what I'm expecting the third-party code to provide, and as I dispatch from the wrapper to the third-party code, I can verify that it's going to meet my requirements, before having to readjust architecture etc. if I find out it doesn't fit further down the road.

With open source or free software libraries I can quickly get some idea of how well-written the library is, and how well it can be extended in the directions I need it it to.

In rare cases I might pick a propietary library for a project at work, but even then I only pick those for which I get the source code. When a client calls with some issue which needs an immediate fix, I can actually dive in and fix things.

#2 Rule of programming ist. Don't talk about programming.

Was intendet to be funny, but I just realised it makes a lot of sense.

    "Talk is cheap. Show me the code."
    - Linus Torvalds

In reality, this clever quip is just Linus' way of telling people to go away. He certainly talks a lot about code he has no intention of writing. (He does write a lot of code, too.)

It's easy for me to outline how a great piece of software X is supposed to function, but I'm still surprised every time how much more work ends up going into the actual implementation compared to the conceptual simplicity of the design. So, similar to "writing is thinking" I believe that "coding is thinking" as well.

You need freedoms within apps that are going to be around for the long haul.

Example... Do I build an app in MOSS 2007 or simply use asp.net. Ya, then comes MOSS 2010 and you need to do a rewrite, if you used asp.net then there is no rewrite needed.

But there are many cases when the best solution is to program. For example: Hi performance software development, sequrity issues and etc.

In the programmer-performance sense, just snagging an off-the-shelf component and shoehorning it into your product will let you ship something far sooner than otherwise. Who cares if the code looks nice right now? Just ship the damn thing!

In the runtime-performance sense, the whole mess becomes a case of "someone else's problem." If you purchase a component, I'd say you have a lot of leverage to complain that a particular piece of software isn't performant or secure. If it's open source, write patches and, if politics becomes a problem, step on someone's toes.

Off-the-shelf components will make you to code fatster and prolly much more flexible. Don't programm is really greate rule.

Don't programm and keep your code as simple as possible

In reality, while you'd like to keep your code as simple as possible, it's often impossible even to keep the simplest things simple because you have numerous bad designs from the past to use as a foundation for whatever it is you're building.

UNIX? Sucks. X11? Sucks. Windows NT? Sucks. Win32? Sucks. .NET? Sucks. PHP? Sucks. Perl? Sucks. Ruby? Sucks. Everything? Sucks.

Any one of these will pose a decent enough challenge somewhere down the line. What really becomes a problem, though, is gluing a good chunk of that mess together somehow.

Get your product out now and then worry about runtime performance.

If that ends up being a big concern early on anyway, I suppose you could pull a Google and just hype the hell out of your product while letting in a small amount of early adopters. ;)

Prototype a cog in an afternoon; you'll have a much deeper understanding of how that cog should work, and you'll be a better judge of the available cogs.

FrankenCode is a perfectly viable strategy, but it's gross and boring.

So what if it is faster to do X? I program because I like to. I find it much better than trawling through the net, evaluating a half-dozen alternatives and then cursing as I try to force fit their API into my requirements.

however i'm in Academia and need to program a lot of by myself, cause i should use some non free library ( cause other people wil lnotbe able to modefy this code and etc.

Some businesses may requires "fast" solutions, but I would argue that most businesses would be better off with "the best" solutions. And, in any case, requirements of a certain segment of businesses shouldn't really qualify as "The No #1 Rule Of Programming".

I'd factor it at anything from 8-24 hours at least.

Why is this site called 'Hacker News' anyway?

Or, you could use something that's cross platform like Python.

As in the most succesful?

But IKEA succeeds because they meet a very broad set of needs very shallowly. The IKEA book shelf will not necessarily be one you can hand down to your children, but it's pretty guaranteed to go well with your Target couch and Walmart dresser.

I'm not interested in competing with the mass producers on their terms.

I have lived in places with old mahogany furniture(from Congo), strong, beautiful, heavy wood, I prefer IKEA furniture for living, I don't need to care if I broke it, is lightweight, and I don't feel bad about the environment.

Having someone do something using his own hands doesn't mean is better, in fact, it uses to be worse, compare a Toyota manufactured with robots to a handmade car and tell me.

  [1] http://en.wikipedia.org/wiki/Ingvar_Kamprad#Net_worth

Or: Programming takes eons.

[2]They don't have the experience points (Money) to buy the material needed to build those parts. And that's not just limited to material, sometimes even the tools are too expensive to buy.Not to mention the transport charges.This is because they are...umm...physical. The parts cost them materials,chemicals,casting/forging devices etc...etc.

Now on the other hand for a software engineer, [1]If you are worth your salt its fairly easy to learn anything in programming in time.And I put an emphasize on "in time".

[2]The cost of material is quite nominal (and transport charges free).And this is because mostly programming material or tools are not...umm...physical.They can be easily downloaded from the internet or from any other 'net you are on.

So in my opinion the analogy is just not fair.

PS: For the umm...physical part, I am not satisfied with the word "physical" to distinguish between programming and automobile tools. So please someone give me a better word.

As in hardware vs software?

I'm just going down to the hardware store to buy a spanner and some raw materials.

Even those of them that aren't very good, sadly. But most are.