First Rule of Programming Is Don't Program
- Buy an off the shelf program and take 3 hours to read their proprietary API for extra functionality.
- Use an existing library and read the documentation rather than building your own code.
- Use VB.NET or Delphi for the front-end user interface.
- Buy a properly documented royalty-free library for under $1000 rather than spend months integrating open source code.
- Use Python or VB.NET even tho it just feels right to use Java/C. (Ok, I said it. Now if I can only get this VB.NET flame shield program to finish loading.)
Unfortunately, us programmers tend not to do this. "Oh, we need a queue class? I'll just build it myself, takes like 30 minutes tops."
As coders, we need to think like an engineer who is building a car. No engineer building a car will make the engine or windshield themselves. But us coders do this all the time.
There are 2 parts to every program: [1]: The new scientific code/algorithm you are writing. Which is typically quite small. (5%) [2] Everything else. (95%)
How many times have I got that urge.. "I don't want to do the research. I want to jump right in.. I bet I can finish this tonight.." 90% of the code out there is already written. It is more about adding the glue. And of course, finding it and reading the docs.
89 comments
[ 3.5 ms ] story [ 123 ms ] threadBut 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. ;)
Or: Programming takes eons.
Even those of them that aren't very good, sadly. But most are.
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.
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".
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.
Why is this site called 'Hacker News' anyway?
[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.
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.
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.
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.
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.
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.
- 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. :)
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.
Or, you could use something that's cross platform like Python.
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.
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.
I can't see a furniture craftsman recommend that you just buy a chair at IKEA.
This philosophy leads to becoming the IKEA of software.
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.