First Rule of Programming Is Don't Program

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.

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.

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.

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.

In some languages, this is rule #0 btw.