Why Software Development is Different ...

I've debated this topic with many people, and while I think/wish it was true that developers were special people among the professional class; it isn't.<p>The things that make a good software developer are the things that make any professional good: learning = good, creativity (hard to measure stuff) = good, no consensus/uniqueness thinking = standard human problem, requirements are always hard and always suck.<p>Software development isn't different. It is just more loudly voiced on the internet because programmers have the most voice on the internet (by virtue of building the damn thing).

Elitist crap. What does he mean by significant contribution? Even the best developers need some help with any significant project because nobody develops code in a vacuum and the best projects tend to be used by many people with varying skill sets who over time tend to add their own contributions to the code.

It's hard to take seriously an article about how software development is different when it neglects to mention what exactly it is allegedly different <i>from</i>.

I get where the first point is coming from in that the best developer can be many times more productive than an average one but that doesn't mean the average one can't make a contribution. Many great programs have come from people that have admitted that they don't find themselves to be the best programmers but picked a goal and worked hard towards it.

This is one of the crappiest blog postings I've seen... ever.<p>The "one programmer can be 1000 times more productive than another programmer" thing is true... but mostly not true.<p>The reason for that is that some programmers are active liabilities; there was, for instance, the guy who was "working at home" on two different projects. Whenever I asked him how my project was doing, he'd say he was too busy doing the other one. I'm sure he said the same thing to the manager of the other project.<p>Some guys spend a month developing a system, that is put into production, that it then takes somebody else six months to make correct (work that your firm has to do ~unpaid~.)<p>Once you get to the range of programmers who actually make a contribution, the differences aren't so clear. I mean, what is "productivity?"<p>If I spent two years developing an application which is well-implemented, but unwanted by the marketplace, the value of my labor is $0. On the other hand, some kid might write a 2500-line Perl script in a month that's critical to a $50G hedge fund, he might claim that his code is worth millions.<p>I'll agree with him that consensus-building can be a real challenge, but "requirements gathering" can't be dismissed -- projects frequently 'fail' in the requirements gathering phase, but tragically, the failure is often detected much later, after many many man-months have been wasted.<p>I think most developers who feel "highly productive" are in a place where requirements gathering is easy, sometimes so easy to be almost imperceptible; if you're developing, say, an implementation of "MapReduce" your programmer's view of the product matches the view that the end users, other programmers, would have.<p>On the other hand, if you're making a product aimed at, say, salespeople, you need to work with a marketing team that sees things the way end users do. As he points out, it's a challenge to get consensus in software projects -- especially when dealing with stakeholders who don't understand anything about how the system works: who don't have an intuitive sense of "this ticket can be resolved in 15 minutes" from "this ticket can be resolved in 2-3 years."

Software development is different because software developers who have blogs love to have a circle-jerk about how special software developers are.

uh, do you have any data to back any of this stuff up, particularly the conclusions?<p>btw, it's buffett. buffet is all-you-can eat luncheon etc., pronounced a la francaise.

This could be evidence of the argument that a lot of what people have to say has to do with the magnitude of their thoughts and less the actual direction.<p>I.e., if I say, I'm <i>really, really</i> happy right now. A trained psychologist, or someone who looks at it objectively, might note: there is this issue with happiness that I'm going through. Similarly, all of the points in this blog post usually are introduced via the very opposite stance (esp. the latter two -- i.e., requirements are the most important thing except for maybe measurement). But you can actually learn things from people if you look very objectively at <i>what</i> they're talking about and less the direction of their conclusions.

&#62; A good developer will be orders of magnitude more productive than an average developer.<p>In the real world, average developers tend to more successfully sell themselves into roles developing new systems using the latest programming technologies, while good developers are most useful in roles maintaining existing systems, i.e. cleaning up the crap left by the "average" developers who've moved on to another job.<p>So the measured order of magnitude tends to be low in practice.

I've seen these exact same ideas before on other blogs. In fact I get a weird sense that I've seen the exact wording before. Whether it was someone quoting <i>No Silver Bullet</i> or Peopleware or Joel Spolsky I don't know...