My experience as a programmer and as webmaster of Mises.org has taught me a few things about writing software. Here are some things that people might find surprising about writing code:
- A programmer spends about 10-20% of his time writing code, and most programmers write about 10-12 lines of code per day that goes into the final product, regardless of their skill level. Good programmers spend much of the other 90% thinking, researching, and experimenting to find the best design. Bad programmers spend much of that 90% debugging code by randomly making changes and seeing if they work.
“A great lathe operator commands several times the wage of an average lathe operator, but a great writer of software code is worth 10,000 times the price of an average software writer.” –Bill Gates - A good programmer is ten times more productive than an average programmer. A great programmer is 20-100 times more productive than the average. This is not an exaggeration – studies since the 1960′s have consistently shown this. A bad programmer is not just unproductive – he will not only not get any work done, but create a lot of work and headaches for others to fix.
- Great programmers spend very little of their time writing code – at least code that ends up in the final product. Programmers who spend much of their time writing code are too lazy, too ignorant, or too arrogant to find existing solutions to old problems. Great programmers are masters at recognizing and reusing common patterns. Good programmers are not afraid to refactor (rewrite) their code constantly to reach the ideal design. Bad programmers write code which lacks conceptual integrity, non-redundancy, hierarchy, and patterns, and so is very difficult to refactor. It’s easier to throw away bad code and start over than to change it.
- Software obeys the laws of entropy, like everything else. Continuous change leads to software rot, which erodes the conceptual integrity of the original design. Software rot is unavoidable, but programmers who fail to take conceptual integrity into consideration create software that rots so so fast that it becomes worthless before it is even completed. Entropic failure of conceptual integrity is probably the most common reason for software project failure. (The second most common reason is delivering something other than what the customer wanted.) Software rot slows down progress exponentially, so many projects face exploding timelines and budgets before they are killed.
- A 2004 study found that most software projects (51%) will fail in a critical aspect, and 15% will fail totally. This is an improvement since 1994, when 31% failed.
- Although most software is made by teams, it is not a democratic activity. Usually, just one person is responsible for the design, and the rest of the team fills in the details.
- Programming is hard work. It’s an intense mental activity. Good programmers think about their work 24/7. They write their most important code in the shower and in their dreams. Because the most important work is done away from a keyboard, software projects cannot be accelerated by spending more time in the office or adding more people to a project.
{ 60 comments }
Well said, thanks! I’m an up & coming programmer, and have undoubtedly failed in all the above respects with my own programming hobbies. I’ve spent days programming only to throw it away and say what am I doing?? It was only after a serious program, and a look back on all my waste time, that I understood the enormous benefit of true software planning.
Like most things.. we learn from our mistakes
Illuminating. Without knowing much about programming code, I can see how a great programmer is so much more efficient than a merely good one.
Please accept my thanks for your hard work. Mises.org is an invaluable resource. The web site, which is easy to navigate and otherwise use, performs its function very well. Thanks again.
Very true!!! I teach economics and an spend inordinate amount of time stressing that one must “think like an economist”. (Of course that ends up leading to great and lasting intellectual accomplishments and professional scorn and ridicule. While the opposite leads to Nobel Prizes and a gig moonlighting at a decaying dead tree establishment spewing nonsense!!) I also used to teach computer programming, and it was the most difficult task to get students to think like a programmer. I used have my students first write simple instructions, on paper no less, first. Then write pseudo code, on paper. Then write an outline of the code, and only after that, begin to code. I tried to reinforce the idea that they should spend far more time thinking and planning their code before they write a single line.
And the hardest part was all the simple, menial, programming tasks I assigned. Things like counting the number letters and words in a sentence, ordering simple sets, min/max, repeat items, all kind of calculations, etc. Boring and tedious. But it illustrated so much, that programming is a a discipline that requires great thought, attention to detail, etc. And without that, they never got it.
I wrote some small software programs for my school a few years back and they still run exactly as designed and without a problem. I’m not even what I’d call a “good” programmer. I just applied good techniques. No short cuts, no “copy and paste” (we can call that artificial credit!!).
Hold on: you’re saying that good programmers produce code that’s easy to maintain? How is that good code??? If the code isn’t expensive to maintain, how is the programmer supposed to make money? Claim IP rights in the software or something? Pfff!
Good programmers don’t want to be stuck maintaining their own code, much less anybody else’s, and will go to great pains to ensure that somebody else can do that grunt work. Development is much more fun than maintenance.
BTW, give it a rest on the IP stuff. We’re trying to have a geek moment here. *grin*
I don’t claim to be a good programmer, but as someone who does program I have to agree with you. Development is about solving challenges. Maintenance is boring. The whole reason one typically programs (outside game design) is to remove some mundane obstacle. Maintenance is inherently mundane.
As far as “IP” goes, I am coding primarily at work but it’s all internal tools, I don’t get payment due to having IP. In fact I share as much as I can with others at work and when I do code at home I look at it the same way. Programming is where you see the most sharing of IP.
If programmers ‘owned’ a sizable portion of what they create, we might see more respect for maintenance, since the programmer is concerned about how much he might sell his code for. Indeed, if programmers and others in an IT company ‘owned’ their labour, we might see more projects succeed, since the workers would be working voluntarily on each project, and would have a financial stake in that project, not just the company as a whole.
And some projects would never get off the ground, because no worker would want anything to do with them. In effect, I’m recommending that companies model themselves on free market principles instead of a hierarchical, military structure.
Of course, this form of ownership collapses in the absence of copyright et al.
As I programmer, I disagree about the maintenance. I don’t want anyone else putting their mitts on my code. They add new code that I would have done differently and that bugs me for a long time unfortunately…
You’ve not had the glorious experience of trying to maintain/fix/update someone else’s code, then? Oh, it is a joy! Such a joy! Especially when the code documentation is nonexistent.
Forget somebody else’s code. I have had painful episodes trying to maintain my own code! I think any programmer with a little experience has had that moment when he looks at code he has written a year ago and thought, “What the *bleep* was I thinking?!”
If you didn’t think that, it would mean you haven’t developed professionally since then.
I find that many programmers who are too possessive of their code are that way because they are ashamed to have anybody else to see their code! That applies to myself as well, BTW. I have in the past tried to “own” code, so that nobody else would see what a horrific kludge it was.
The other end of the spectrum is the programmer who sees his code as a work of art that, in its sublime magnificence, should not be sullied by unclean hands. It may even be true that the code is a work of art, given the original requirements… but requirements change. And given that fact, a piece of code that cannot easily be changed (by other than the original coder), is not really such a piece of art, after all. Timeless works of art belong in a museum. The art of programming is change, grasshopper. *grin*
Much the same can be said for architects.
Yes. In fact, yesterday my Microcontrollers professor (who spent much of his professional life developing software) gave an analogy specifically about architects/civil engineers in regard to programmers. He mostly talked about the first point.
The first point is very important. A good builder wouldn’t just start building a house (except maybe a dog house) without a blueprint. But it’s amazing how many programmers (and managers) think programmers should just start coding without some similar sort of plan. There’s even an acronym for this: it’s called the WISCY Syndrome. As in “Why Isn’t Somebody Coding Yet?”
“Good programmers think about their work 24/7. They write their most important code in the shower and in their dreams.”
it’s disturbing, but it’s true. programming is more of an art than a science, and computer science has little to do with programming. it’s glorified math, really.
Computer science let’s you understand the difference between hashing and encryption.
I wouldn’t hire a programmer who didn’t understand that.
But would you hire one who didn’t know the difference between lets and let’s?
This is true, and I find that it makes billing tricky as a freelance programmer. I may only spend an hour of actual keyboard time writing a program, but I may have spent 20 hours thinking about it and designing it in my head, while showering, driving, or working in the garden, which results in being able to type it all in one rush. So do I bill for one hour, or 21, or something in between? I could quote a total for the job in advance, but that just shifts the question: do I quote for the one hour I expect to spend typing or 21? Usually the 20 hours aren’t spent exclusively on that project, since I’m doing and thinking about other things too. So I try to compromise on a number that seems fair, which too often ends up being lower than it probably should be, leading to poverty.
“A programmer spends about 10% of his time writing code, and most programmers write about 10-12 lines of code per day that goes into the final product, regardless of their skill level. Good programmers spend much of the other 90% thinking, researching, and experimenting to find the best design.”
I think the 10% figure doesn’t take into account the amount of coding that goes into “researching, and experimenting”. 10% may be a good estimate of the amount of time a programmer spends writing code that is actually kept in the final release. But I bet he spends a lot more time on coding that doesn’t make it into the final release. Good debugging more often than not involves removing code, not adding it. Also, I bet the 10% figure doesn’t take into account a programmer who likes to write tools that do his work for him.
You’re right Russ, I should have been more clear about that.
The same can be said for writing. Compare, say, the carefully measured and tight syntax of Hans Hoppe with the meandering mendacity of Paul Krugman. One lifts the mind and spirit, the other pollutes both.
Didn’t this kind of thinking (“the person I disagree with is a heretic and must burn!”) go out of fashion when the Enlightenment took hold?
Krugman isn’t a heretic, he’s an idiot.
In Germany today, a person can be thrown in jail for expressing pro-Nazi opinions. While I’m not endorsing that policy, I think that expressing socialist opinions can be every bit as harmful (if not more so, since fascism is not taken seriously nowadays, while socialism is). I don’t think there is anything wrong with saying that the opinions of others are not just different from mine, but mistaken opinions, or even morally wrong opinions.
Actually, no.
“it’s disturbing, but it’s true. programming is more of an art than a science, and computer science has little to do with programming. it’s glorified math, really.”
nice words written!
Conceptual Integrity? Modularity? Debugging? Hogwash! All worthless fads! Why back in my day when our COBOL caused the mainframe to crash and we had to manually re-input all the data, we LIKED it!
You kids and your fancy polymorphic functions! In the good old days of hungarian notation, changing the data type of a variable by manually changing its name is what we did for kicks on the weekends!
*Is actually a snooty functional programmer in reality.*
Darn tootin’! Programs are hard to write, so why shouldn’t they be hard to maintain, and hard to use?! And forget about fancy stuff like Hungarian notation, you young whippersnapper. Back in my day, with BASIC, variable names were one character long, with a $ attached if it was a string. And we had to walk barefoot in the snow to get to the computer lab, and it was uphill both ways! And we liked it!
Oh yeah? I write all of my functions without variables at all!
*is a big fan of point-free <.<*
So, you’re such a hardcore anarchist that you even make your programs state-free? *grin*
BAHAHAHAHAHA
That’s brilliant! I’m stealing that line.
Bah!
You kids know nothing. Back in my day, we had to hand crank our difference engines, the way God intended!
You mean you didn’t use the emacs command?
Your’s had hand cranks? Well, I guess that’s OK, if you want to do things the easy way!
I read this with interest on a couple of levels–as a former programmer, and as an observer of the flailings of various legislators trying to write law (which, if you think about it, is a kind of programming, isn’t it?)
Unfortunately, ALL legislators today seem to be very, very bad programmers indeed. And their various (special-interest) subcontractors are even worse.
The result is a legal system that’s such a mess of spaghetti code that would make even a 1970′s FORTRAN programmer dizzy. (Remember the GOTO! Even when it was “considered harmful.”)
It’s not that the original kernel of our political operating system (the Constitution) is that bad, it’s just that all of the cruft that’s built up around it over the past 219 years is, essentially, corrupted code, to the point where the program does the opposite of what it is really supposed to do.
It doesn’t help that the current crop of incompetent programmers have no clue what the design philosophy of the original OS was . . .
“Unfortunately, ALL legislators today seem to be very, very bad programmers indeed.”
Ah, but this isn’t true. You are making the mistake of assuming that the purpose of the “code” is really what the “marketing” says it is. But the real purpose of the code is simply to bake in job security for the programmers, i.e. to get politicians re-elected. When looked at from this viewpoint, legislators are very good programmers, even though from everybody else’s point of view, their code is malware.
Well, yes, I did take that broader view . . .
But your point is well taken, we have people busily installing trojans into our society’s OS which have the purpose and effect of doing the exact opposite of what the original concept was.
Maybe that’s a T-Shirt/billboard idea: ObamaCare: Don’t click on it–it’s MALWARE! (Replace ObamaCare with pretty much anything that comes out of Washington nowadays, as needed.)
Legislators are good students of this:
http://freeworld.thc.org/root/phun/unmaintain.html
(I wonder if there is a similar page for legislation.)
Here is my favorite from the days of yore.
Note especially the item on APL. This implies that anybody who writes 10-12 lines of APL code per day is too verbose.
I agree with Russ, but even if politicians were actually trying to do the ‘right’ thing, they’d likely make the mistake of assuming that a new law, L, will apply to the existing society, S, whereas in fact the new law, L, will apply to S’ = S + L.
That’s a pseudo-mathematical way of saying: look out for unintended consequences!
In programming, few problems are unique. Most problems are quite similar. Great programmers see this truth early in their careers. Great programmers write a handful of great routines to solve these similar problems and re-use their code, time and again.
1. Programming is easy to a surprising degree, especially to those who have the mind to used restricted, man-made languages with highly structured expression rules to solve workflow problems.
2. A programmer spends more than 80% of his time writing “glue code” tying together chucks of code he or she has written already to solve alike problems.
3. Programmers who only spend 10-12 lines of code per day are unproductive, in short, a sinkhole to their employers. Employers should root them out and fire them.
4. The BEST programmers see great degree of alikeness in nearly all problems in which they are being asked to capture with a programming language to make computers compute.
5. Most commercial-oriented computer languages suffer from intense, unneeded complexity, which appeals to CTOs, CIOs and others as way to build a fiefdom of employees, gain higher pay and insulate themselves from job loss. C++ and Java come to mind, immediately.
A language like REBOL shows how easy programming is and how within reach programming to nearly everyone with a suitable intellect.
“3. Programmers who only spend 10-12 lines of code per day are unproductive, in short, a sinkhole to their employers. Employers should root them out and fire them.”
Yes, all employers should use code metrics to evaluate programmers’ productivity. That way, all programmers will write 1000 lines of code per day to do what could be accomplished in 10. That will make them 100 times more productive.
It’s not that a programmer is writing X lines of code per day that makes him a good programmer, it’s that he is writing the right X lines of code per day.
Your argument falls flat. No one says the answer is an infinite number of lines of code is the way to measure productivity.
Smack,
You captured why I left programming as a career: it got too easy. After I had seen and learned enough patterns, I realized that there wasn’t much new under the sun. Good programmers are lazy programmers because they reuse good, proven code, don’t want to have to go back and fix their code, and if they do have to, they want to be able to figure it out quickly because they surely will have forgotten what they were thinking when they wrote it (thus, it needs to be easy to follow).
I disagree with #5, but get where you are coming from. Regarding Java, most of the unneeded complexity is not in the core language itself, which is really quite concise and elegant, it comes from the huge numbers of libraries. Sorting through wich competing libraries are worth using consumed a large amount of my time. In Java’s case, as it became more popular commercially, many overweight libraries became very popular as the level of “average” competence declined as more people chased the market to the languague. I also believe weakly typed languages invite sloppy thinking, but I know many smart people disagree with me on that.
And I really have to back Russ up on #3. I could do in 20 lines of code on what an “average” developer would expend 100 lines. Why? because I spent 90% of my time thinking about the problem instead of writing code. Although I do admit that 10 lines of code a day doesn’t sound like much, but I’m guessing that doesn’t include the 50 lines of non-production test code to support the 10 lines of production code.
Sure W.M.
I know what you mean about my point #3. Of course, it depends on the language.
Weakly typed languages can save space if you can internalize in your mind, but they do make it harder to understand code that you didn’t write in a short period of time. Personally they are a wash for whether they are beneficial or not.
W.M. wrote to Smack: “You captured why I left programming as a career: it got too easy. After I had seen and learned enough patterns, I realized that there wasn’t much new under the sun.”
To claim that programming is easy is like claiming that math is easy. Programming is open-ended. Whether it is easy depends entirely on the task you set before yourself and the effort you put into it. Design patterns, while undoubtedly useful in their context, should really be seen as a failure of your chosen language to express the abstraction that would make the pattern unnecessary in the first place:
http://norvig.com/design-patterns/
I like what Joel Spolsky is/was always saying : Programmers work like trains. It takes a bit for them to get going, but soon they’re flying (and don’t get in their way).
“It’s an intense mental activity. Good programmers think about their work 24/7. They write their most important code in the shower and in their dreams.”
From the invisible world to the visible world, thanks to the intelligent and imaginative use of the human spirit. This is universally true in all endeavors and we can all be very thankful for the division of labor!
Not unlike any profession, even digging ditches. The important work is thinking it out, doing it is the minor part. The ability to think is the differentiator among men.
As a software engineer by profession, I can attest to all of David’s post being true. In fact, there are entire work days where I won’t write a single line of code — but that doesn’t mean I’m not thinking about the problem(s) at hand. But as Russ the Apostate said, it’s all about the code quality over code quantity.
Programming is easy; it’s the design process that’s difficult. That’s why so little time is (or should be) spent coding. This is the most difficult lesson for students to learn; beginners typically want to design and code concurrently, yet none of them would consider starting the construction of a building until the design and blueprints were complete.
As a hardware engineer, I like to remind the software weenies they are really only glorified typists. So there!
I took a look at the source code for the r600 FOSS driver – it seems you types like making it difficult for the typists. Probably a better example would be fglrx’s power management codebase, which I’ve heard is larger than the entire open stack for the hardware.
Well, somebody has to dissent, so it might as well be me. This 10x productivity claim that nearly everyone seems to believe in, is based on a study 50 years ago that nearly everyone hasn’t read. There are dimensions of code quality today that didn’t even exist in the 1960s.
If these differences are real, why isn’t anyone studying how the high performers operate so they can improve the rest of the developers? Or perhaps cultural beliefs have not proved fertile ground for scientific study.
Fascinating list.
As an investor I must say the same applies to portfolio managers. Most of the work done away from the market, a good investor takes few but well informed decisions, a bad one makes a lot of useless and loss-making trades, a great investor (Warren Buffett e.g.) is worth almost infinitely more than a bad investor
“Programming is hard work. It’s an intense mental activity. Good programmers think about their work 24/7. They write their most important code in the shower and in their dreams. Because the most important work is done away from a keyboard”
It’s related to cognitive science, it’s very interesting that we are using different level of memory everyday. in my experience many good solution come to my mind when Im in relax mode and out of office. If you are interested in this area put cognitive science in your study plan, it will work for you!
Thanks for your post.
Almost every programmer thinks he’s a professional. And almost every programmer could find himself in this list
Great comment re. development of algorithms – a lot is indeed being done in a sleep or at breakfast. As for actual typing, there is great rule:
Do not write for a computer, write keeping in mind the poor soul that will be asked to maintain it a few years down the track. And it may be you!
It is about a clear formatting, meaningful names and comments. This is also a way to distinguish between professionals and hacks.
Comments on this entry are closed.