First Rule of Programming Is Don't Program | Hacker News Reader

First Rule of Programming Is Don't Program

68 pointscyman87 comments

While us programmers tend to say "I'll just program it myself" it is actually much faster to:

- 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.

View on HN

That looks like the manager's (or any other person spending money, not writing code) point of view... In reality you missed a couple of things:

- 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'd say that if you're buying an off the shelf program, it's likely because implementing it would take FAR longer than the (example) 3 hours to investigate their proprietary API.

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 actually think the reverse of this is the biggest problem in our industry.

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 also think that the "use a third party library" mentality can, but not always, cripple programmers.

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.

It's worth noting that your learning experiences and experiments don't need to become production applications, though. This is what gets many people into trouble.

Not being able to write your own code to deploy into a production environment won't get you very far as a software developer.

Merely my $0.02.

But unless you're a web host or something, you are not being paid to write web servers. In the limited amount of time you have to solve your business's actual problem, do you want to learn the ins and outs of HTTP, or do you want to learn the ins and outs of the actual problem you are trying to solve?

deploying is one of those cornerstones that you need to get right once, right at the beginning. #twitter

You are not Twitter.

This is an extreme example of my previous point: when is it a good choice to learn vs a complete waste of time.

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.

I'd say it can be simplified even further:

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.

I believe this is actually a much better rule.

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.

Agreed. I tell my partner "We can write that easy!" and he always replies "We CAN do ANYTHING, Joe. What SHOULD we do?"

This is one of those mantras that I lived by when I got out of college, and then found that the reality was far more complicated than I initially believed.

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."

I think another point to emphasize is that using a third-party solution shouldn't in all cases be a long-term solution.

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 would never buy a library, but I've never had that option either. Every tool I use is open source, and I build small proprietary applications around the open source stuff. (Making web pages and parsing CSV files is not my business domain, so I let the community handle those.)

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.

Bought libraries are static; you can't get them changed. Open source may be architected wrong; not componetized the way you need; have bugs; build on the wrong platform...BUT you can fix all that. There is probably something in there you need, that has already been debugged, and that's why I consider Open Source first.

Even if it were "much faster", this isn't really the goal, because code writing is usually the quickest step; at least, it is if your employees are competent. What matters more is how maintainable your project is, and how easy it is to deploy.

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.

#1 Rule or programming is: programmers start counting from 0, not from 1.

unless you are programing in Lua or Ada. Counting from 1 makes sense.

So, what's rule #0?

Nah.

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.

Most people fall for the songs of the unwritten-code. When confronted with existing code, they can see all of the unevenness of the terrain, the special cases that needed to be shoe-horned because the original architecture didn't allow for them. It is at this time when the unwritten-code starts luring them inside their heads, a sweet, seductive melody. They (who am I kidding, we) think of a perfect generic architecture which will take into account all cases. This architecture will be so extensible that when new requirements arrive, it will take care of them without mutating the design. And performance will be equal or better.

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.

Each line of code is a liability. Even tests.

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.

The first rule of programming is indeed "don't program". But that's not because buying off-the-shelf code makes you more productive than writing code yourself. It's because software solutions are usually worse than manual solutions.

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.

tl;dr version:

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

he could have used that concept for the post text :)

I wonder what OP has seen to reach these conclusions because this is not my experience. Not even close.

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.

I think "Don't solve the same problem twice" might be a good way to say the same thing.

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 seems to be some tension in your argument regarding the use of code.

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.

Virtually everyone I meet nowadays tells me they are using some high level framework like Rails, CakePHP, Django with jQuery/Prototype etc. or building on top of Wordpress. Even .net is pretty high level.

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

Agreed. I would broaden the #1 Rule of Programming to be:

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.

Yup, you are right. But solve problem your best and as fast as you can :-)

Not programming is hard work. You will spend about 90% of your programming time integrating other software whether you like or not.

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

"keep it simple" is really good rule. But "Don't program" is good too. As i can see, many people try to code many complicated library methods even don'tknow about methods.

Often - actually, almost always - third-party code is too general for the task at hand. If the job you're doing is simple, it can cost less in cognitive complexity to implement it directly, particularly if it's a problem domain you're expert in.

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.

I always try to find a library which does what I need before writing one myself. However, I rarely consider proprietary libraries.

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.

Also: 9 times out of 10 you can do something faster by hand even if you think that a shell script, regex/sed command, or custom emacs extension would do the job better.

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

#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

The second line is a great counter-argument.

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.)

Regardless of its originator, to me the quote just serves as a reminder that my true productivity and progress are based on the quality and speed with which I can write (or integrate other people's) code (as opposed to talking about features, dreaming of all the way things could be done, etc.).

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.

This is a balance one has to make when working for someone else. Often, all of your suggestions you made end up with more limitations than freedoms.

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.

Of course, "Don't PROGRAM" is a greate rule. If you can use libriry of algorithms or something else that is made by really professional programers and fulfit all your requerements it's good. To buy this library will save your time (=money).

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

I'm not sure your definition of high-performance software development and mine coincide here, in any sense imaginable.

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.

I ment runtime-performance.

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

You subscribe to the rose-colored glasses version. :) I'm sensing a trust issue or two w/r code written by others, but that's okay.

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. ;)

Yup it is mix. You know, Life has alot of compromizes

Fortunately, academic pursuits only require compromises in terms of politics. ;)

Yup it is mix. You know, Life has alot of compromizes

If you ever want to create something better than what's out there, you'll have to program itself, and if you want to get to the situation where you can create something better than what's out there, you're going to have to do a helluva lot of programming, not just read documentation and try to fit together other's people's software with the minimum effort.

bleghhh, maybe you are underestimating the joy/morale of writing what you want to write.

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.

Ok - this is a cute post but I'm going to play devil's advocate.

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.

If you like you may programm but it will be your HOBBY. IF you need something special or it is fater to program yourself DO IT. But Biz needs fast and quility solution.

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.

Ok - I program in a software product company. Our business depends on getting out the best solution - not the fastest solution. It's definitely not a "hobby".

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 kind of agree: however I think if you only spend 3 hours learning the proprietary API and reviewing the code in the package your going to end up in almost as bad a place.

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

"Everything that can be invented has been invented." Attributed to Charles H. Duell, Commissioner of the U.S. patent office, circa 1899

I wish the patent office had taken that to heart and stopped issuing patents.

As an odd corollary, in matters of system administration, the exact opposite is usually apposite: AUTOMATE EVERYTHING.

It's kind of the same rule. AUTOMATE EVERETHING == Let something or someone todo your work == Use work of another people == use library == DON'T PROGRAM

Usually the process of automating is writing high-level glue code. So it is a kind of combination; it's using third-party code, but it's also very much programming.

Yup it is. You know the main idea of all this advices is Try to save your time and power. For administrators: Write code thatwill do your job. For programmers: find someone who have done this work with needed quolity

I started out in programming, but became a de facto system administrator when I found the best way to accomplish a job was to assemble other people's components. Now my title is system administrator, and I'm solidly in the "automate everything" school of sysadmin.

Great advice. Otherwise, you might learn something. By doing. Which is so passé.

Why is this site called 'Hacker News' anyway?

"Use VB.NET or Delphi for the front-end user interface."

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

Using which Pythonic stable, tested, documented drag-n-drop GUI/RAD toolkit?

There are a lot. the built-in TK library has worked well for me in the past. It supports some drag and drop.

I'd be interested to hear what some of the successful founders in YC have to say about this one.

I'd say first rule of programming is KISS. It kinda includes your rule.

There is something to be said for writing code you can be proud of. I'm always working on finishing projects faster and not introduce bugs in the name of speed.

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.

>This philosophy leads to becoming the IKEA of software.

As in the most succesful?

IKEA is a furniture vendor, not a furniture retailer, furniture consultant, or furniture user. If you are choosing whether to build a business application on top of Microsoft's BizTalk, you are not choosing whether to be Microsoft!

Perhaps, and for those who wish to produce the next Windows ME, this is good enough.

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.

If that is what you are going for, then yes. There is nothing wrong with that strategy. I haven't found anything remarkable at IKEA (except for price).

One remarkable attribute of IKEA is its epic success. In fact, its owner is arguably the richest man in the world [1].

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

I have. My office leather chair was bought in IKEA more than ten years ago. It was cheaper than alternatives, I bought the alternative because I wanted something good that last. It lasted 6 months of use, I had used a lot of chairs in my life,and all broke fast(I'm tall, maybe that's it) I think my IKEA is way way better in terms of quality, not only price.

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.

Would mint.com be a good example of this philosophy..?

I prefer: No code is better than no code.

Or: Programming takes eons.

#1 Rule of Programming Is..There is no Rule #1

sure there is. mine is: automatically assume that every user is out to hack/deface/fuck with your app.

Well what's rule #34 of programming, then?

In some languages, this is rule #0 btw.

http://bogdan.org.ua/2009/01/05/unix-sex-linux-command-refer...

I would like to take a poke at the automobile engineer analogy. I think the reason they don't build there own parts is because of one of the two: [1]They don't know how to build it.These parts are sometimes too advanced for a single engineer to build.This is because there field of engineering has advanced to a level to which,I think, software engineering has just not reached.

[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.

How about "hard"?

As in hardware vs software?

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

"tangible"?

In Java, you usually do not invent the wheel but rather take an existing open-source jar.

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

Reply on news.ycombinator.com