Lessons from `Saving’ Software Development

Posted on May 19, 2008
Filed Under Computer Science, Programming, Quote, Software Development |

My post “How Reddit Will (Maybe) Save Software Development” went through a few iterations. It started as a condemnation of crappy computer books (lack of rigor). It then transformed into an encouragement of rigor in design and coding, and went through minor revisions.

I then started thinking about “internalizing the externality,” and either penalizing bad work, or rewarding good work. The computer-age equivalent that I thought of was Reddit, so I envisioned a system where teammates could comment on the work of others, and vote on code/tests/etc. I decided this system was ultimately flawed because of social reasons, as I stated in the post.

Since it’s been a while since I’ve really stirred the pot, I decided to ignore my usual moderate style and use the bombastic headline. At the very least, I would see what other people thought of the idea, circumstantial though my evidence may have been.

Mini-lesson:

If you need the extra traffic, go for the bombast. I had my biggest traffic day since January.

In the future, I will not make extraordinary claims without extraordinary proof. However, doing so certainly brings you attention.

Reaction

The reaction, as I anticipated, ran the gamut from “pretty good” to “nonsense”. Some of the criticism I received has some good lessons, which I will share with you.

Reddit user `hox’ states:

And we need water to stave off dehydration!

Seriously, attaching a paltry karma system to programming collaboration software will provide an incentive? I think you are vastly overestimating how many actual professional programmers who frequent Reddit care about karma.

A points-based reward system that is community-driven can be incredibly polarizing. Such a system rewards those who love to dive into every detail and express their opinion on what they like and dislike, not necessarily what is good and bad for the project. A community rewards system can also have social consequences the author may not have considered. While I do not object to peer review, whittling peer review down to a simple “+1 -1″ karma-based system is a complete overgeneralization and does not provide appropriate feedback. Members of a development team would only know that their peers either liked or disliked their work, not why.

I would much rather be rewarded with a friendly work environment, meaningful projects, and equity in the firm. These are real incentives that can be generalized across 99% of the software development world.

This is an important point. People will probably respond more to real incentives than to fake incentives. Peer review is important, but for the only reward to be karma points? Screw that! I myself don’t really reach for the Karma points that social sites offer, so why would I when I code?

This is also related to the idea, as others mentioned [2 links], of shifting the focus from the project. If the focus is on the karma system, then certain people will game the karma system any way they can.

On the `this post is nonsense’ front, Reddit user Whisper points out another factor that I hadn’t considered: expectations.

Whisper says:

I’m sorry, but this is just nonsense.

People are forever coming along and proclaiming that software engineering is in a state of crisis. And always their reasoning is that (other) programmers aren’t smart enough.

They, of course, are special magical code gunslingers with superhuman intelligence, members of the top 5%. (Surely software engineering is blessed to have 90% of its practitioners located in the top 5%!)

But the truth is that there is no crisis, and there never has been. The only problem, and the reason software projects keep failing, is that of unrealistic expectations.

Software is hard. Really hard. This should not be surprising to anyone who understands that it is really the field of assembling instructions for doing… anything. Anything that people want to get done. It’s sort of a meta-field that encompasses almost all other fields, with more being added every day.

Of course it’s hard. The only real question is why people consistently underestimate its difficulty, especially why they underestimate the difficulty of any particular software engineering task.

I think there are a number of reasons for this:

  1. “It fits in the little box, how big can it be?” Humans, particularly those who aren’t technical, have a tendency to judge difficulty with their eyes.
  2. “It’s just a word processor.” Everyone understands what they are building, what the set of instructions is supposed to do, and they probably know how to do it by hand, albeit very slowly. They tend to assume that writing the software is just a matter of telling the computer to do the same thing, but faster. What they do not realize is that they don’t really know how their brain works at all, and that all the details which they can just leave to their giant neural net when doing it by hand, have to be figured out and brought consciously to the software.
  3. The Cult of Smart. Programmers, on the other hand, have figured out that software is complicated, and that being smart really helps; in fact, nothing is a substitute for it. This causes them to emphasize it, convince themselves that they have an abundant amount of it, and to convince themselves that results are not the result of them learning about problem domains, and building better and better versions iteratively, but just the inevitable consequence of bringing their enormous brain to bear. This leads to things like the “Agile Methodology”, as in “I’m so Agile I don’t need a Methodology.” Instead of realizing that you have throw one away (usually more like ten), they think they can be so magically smart they don’t have to.
  4. Expectations based on hardware. Chips are square. A linear decrease in CMOS transistor size results in a quadratic increase in the number that can be packed on a chip. Code is linear. A linear decrease in the amount of time it takes to produce X amount of code is merely a linear increase in the amount of code that can be produced. This results in an ever-widening design productivity gap, where capacity forever recedes away from our ability to exploit it. We can waste some of that excess capacity to save programmer time (this is why high-level languages have an expanding role in the field), but this is never going to go away. It isn’t that software is inherently blighted. It’s that hardware is inherently blessed.
Personal attack? Nope… Upon questioning, it looked like my idea was just in the wrong place at the wrong time. Anyways, I was going for the bombast, so it is not so surprising that I got called out on it!

Whisper replies to me:

You bring up a lot of good points not addressed by the post. However, the author never claimed that he was in the top percentage of anything…

Wasn’t accusing you of it. Just taking aim at the vast universe of talking heads out there who are always trying to sell us silver bullets. The subtext is always that if someone is smart enough, they can just come up with a general solution that will make the nasty complexity of programming go away.

What you, specifically, said that was nonsense is that there is a crisis in software development. There is no crisis.

A crisis isn’t a constant state of affairs. If things have always been this way, then no matter how bad we find it, or how much we dislike it, it’s not a crisis. It’s the way things are.

Software has always been hard. Software will always be hard. This is because what we attempt will always be determined by the level of our capabilities. The most complex thing that we are still able to deal with is axiomatically going to be very complex for us to deal with.

Do you think that there is a way to manage expectations, like Evidenced-Based Scheduling

I think that such things can be a good weapon for engineers to defend themselves against unrealistic expectations, but the need for such a thing indicates that the expectations are there. It’s a tactic for managing the problem, not a solution.

do you think this is something that can only come with experience of failure and success?

I’ll do you one better. It’ll go away as people die. At some point, there will be no one living who remembers a world without computers, no one living who wasn’t brought up with software development going on in the world around them.

Already some of most savvy groups of software consumers (hardcore gamers, for example) are starting to develop rather accurate expectations about how long development should take.

I’m sure you can find lessons for yourself in that exchange, but here are the main things that I got from the exchange:

Popularity: 13% [?]

Comments

Leave a Reply