I love your point about there not being an infinite number of ways to write a simple program, too, that’s so true.

As far as programming being a market for the lowest bidder, I think that may be fading away as people come to see the ineffectiveness of hiring a large number of incompetent programmers. The modern trend of the most successful companies has been to hire a small number of extremely competent engineers, instead. (For example, the average size of an engineering team at Google is four people.)

-Max

Let me begin by saying I used to be a programmer. Then I realized that programming was getting taken over by people whose greatest value was that they were always willing to cheaper than I would. I did not want to be a winner in some kind of “race-to-the-bottom,” so I moved on.

Good programming is an art. While there are an infinite number of ways to write a program, there are NOT an infinite number of ways to write a simple program, or an “easy-to-maintain” program, or an “easy-to-understand” program.

A lot of what makes programs simple is, 1) having some rational standards. Take for example variable names. Calling a variable “x” makes debugging a helluva lot harder than calling it “LOAN_PRINCIPAL” or something.

2) Separating DATA and CODE. Can I tell you how many programs are out there where some variable is HARDCODED in the code? Too many.

3) making code MODULAR. How hard is it to repair code when you have a 3000 (or 300000) lines of code to read. It’s easier (though not easy) if each “function” (say calculating a price) is set off in it’s own little module of 100 lines.

4) not using global variables. Yeah. Enough said.

5) having rudimentary error handling. Has anyone every found Microsofts “fatal exception has occurred at ZZ” even remotely helpful? No.

6) Having even rudimentary documentation.

7) Clear APIs. Write your modules with clear instructions about what they will do, what inputs they take, and what outputs they export.

Basic input validation. If you are going to require input, and it has to be a number, make your program check that the input IS IN FACT A NUMBER.

I could go on….but as I said….I have moved on from programming. Now I just write bad requirements….kidding…just kidding.

– B.

1) Who told the project manager than an impossible schedule could be met? (Now, granted, if the project manager didn’t even ask anybody whether or not the schedule could be met, that’s something that needs to be fixed.)

2) Who caved in when project management demanded bad code to meet the impossible schedule?

A whole program can’t go wrong just because of some last-minute hacks that have to be made in order to ship the product. You don’t get something like Windows ME because of last-minute hacks. You get something like that because of consistent, long-term bad design.

So yes, project management definitely has its place in the hierarchy of responsibility. And I’m not saying bad management never ruined a project–in fact, it’s probably extremely common. But most of the bad software that I’ve had the chance to read the code of is just way too complex from the ground up.

Even under pressure, sometimes a developer needs to step back and say, “Okay, pressure like this is going to happen in the future. How can I make things simpler now to avoid things like that in the future?”

You’re right also that technically, I do mean bad programming. But I’ve encountered a ridiculous number of programmers (the vast majority I’ve known) who had no real concept of simplicity, and I tend to think that the vast majority of problems are caused by these programmers (since they comprise the majority of programmers I’ve met), not by good programmers under pressure who do bad.

-Max

Perhaps “good programming” is really what you meant by “good programmer”–it may or may not be the fault of the person who actually types out the code, there’s a lot of other people that go into the development process of complex software who may contribute just as much to the problems of the process