Why Software Development is Different ...

http://www.p3ll0n.net/why-software-dev-different.html

by p3ll0n • 16 years ago

13 21 16 years ago

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.

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.

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

hello_moto3• 16 years ago

You got that right brotha!

I'll add a bit more to your last statement about internet and programmers: these bloggers usually have had experienced the pain with software development in general but they rarely offer constructive criticism (like this article) or they would treat the symptoms (.e.g: coming up with new process, new tools, or new whatever).

The basic problem is still there: people (including themselves) are the problem.

Sort of the blinds leading the blinds.

Software Development is not too much different than gadget/hardware development. Just ask Nokia...

robryan• 16 years ago

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.

slantyyz5• 16 years ago

Reading his points, I wonder how much experience he has and what the scope of his experience is.

My experience is that if you've got multidisciplinary teams populated with reasonable people who have a good grasp on real world constraints (usually a delicate balance of compromises between scope, quality, time and money), all of his four points break down.

On the measurement point: While I'm sure some of the more clueless companies might use some arcane and pointless measurement systems, I haven't seen any half-decent dev shop use any of the measurement practices he talks of.

hello_moto3• 16 years ago

That's because half-decent dev shop thought that they're full of good developers and their best developers managed to convince the management that measurement and metrics suck, just because software development is different!

Really, we need some kind of measurements or metrics. Otherwise, how else do we know we're progressing or improving or at least not sucking more.

I agree that metrics is hard to do and easy to game. That's why don't put a specific number or targets. And also don't tight metrics with employee performance. Put it on team's performance (still not perfect, but I'm sure it's better).

One example of metric that probably might have made sense is that if your shop is doing Agile (code review, code coverage, unit-test, # of bugs etc.) is to make sure that these numbers don't go down in every iteration. Make sure these numbers either stay the same or go up (in the case of improvements or new development). If the numbers go down for 2 consecutive iteration, someone or some team doesn't care about quality. Track improvements, not specific number.

Side note: I would suggest people to read Standish Group Chaos Report to understand how bad our industry was and how far have we improved over the years.

adrianscott• 16 years ago

uh, do you have any data to back any of this stuff up, particularly the conclusions?

btw, it's buffett. buffet is all-you-can eat luncheon etc., pronounced a la francaise.

greenlblue• 16 years ago

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.

slantyyz5• 16 years ago

Something that still resonates with me from university (which is pre-www) is a quote from one of my most cynical professors:

Most people who call themselves experts at something usually just read a couple of articles more than the next guy.

These days, you just have to write a blog entry with a slightly more authoritative tone than the next guy.

hello_moto3• 16 years ago

That's usually what happened in this day and age isn't it?

One of your most vocal developers read a blog or an article and tomorrow he'll implement the new core threading part of the system because the idea was just damn good and suddenly y'all lose customers :) and he'll get the pat in the back.

ant5• 16 years ago

It reads like a justification for arrogant cowboy programming, eg: Developers that have to spend a long time cleaning up after you are just the mediocre ones that can't keep up.

tmsh• 16 years ago

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.

I.e., if I say, I'm really, really 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 what they're talking about and less the direction of their conclusions.

zb• 16 years ago

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

reynolds• 16 years ago

The author mentions manufacturing processes in the article.

slantyyz5• 16 years ago

Only in relation to one bullet point out of four, requirements gathering.

That particular bullet point is perhaps the most disturbing flaw in the article, I might add. All the projects that I've seen go off the rails are the results of -poor- requirements gathering.

Granted, poor requirements gathering seems to be the rule more than the exception, I have worked on plenty of projects that had excellent requirements that went extremely well, even with the usual set of unexpected scope changes.

gphil• 16 years ago

Yeah I agree. Additionally, I think that the points in the article are generalities that are applicable to basically anything.

jim_dot• 16 years ago

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

Goladus• 16 years ago

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 No Silver Bullet or Peopleware or Joel Spolsky I don't know...

terra_t• 16 years ago

This is one of the crappiest blog postings I've seen... ever.

The "one programmer can be 1000 times more productive than another programmer" thing is true... but mostly not true.

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.

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

Once you get to the range of programmers who actually make a contribution, the differences aren't so clear. I mean, what is "productivity?"

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.

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.

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.

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

vorg• 16 years ago

> A good developer will be orders of magnitude more productive than an average developer.

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.

So the measured order of magnitude tends to be low in practice.

Why Software Development is Different ...

Related Stories