Software Engineering: Agile Programming and IDEs Considered Harmful

Put away your IDE, code using a pencil, and do a big design up front. Get it right the first time. It can be done. Naturally, I'm trolling a bit, but that link is a very short, very fun read.

It reminds me of an interview with Donald Knuth that I've been thinking about a lot lately. Knuth said:
With the caveat that there’s no reason anybody should care about the opinions of a computer scientist/mathematician like me regarding software development, let me just say that almost everything I’ve ever heard associated with the term "extreme programming" sounds like exactly the wrong way to go...with one exception. The exception is the idea of working in teams and reading each other’s code. That idea is crucial, and it might even mask out all the terrible aspects of extreme programming that alarm me.
Somehow André Bensoussan and Donald Knuth are both capable of designing everything up front, and just getting it right. Since I've always been an agile coder, I find such stories amazing. I wonder if Bensoussan would still work that way these days. The systems are larger, the libraries are less stable, the timelines are shorter, and there are more people you have to integrate with.

Comments

SDC said…
The man Edsger Dijkstra recommended teaching 'a language not implemented on any computers at the University', so students wouldn't be tempted to test their programs before they finished them. This was in an essay called 'On The Cruelty Of Really Teaching Computer Science'. That one also contained the gem: 'Software Engineering takes as it's charter: How To Program If You Cannot'.
darin said…
"Get it right the first time. It can be done."

Indeed, it can...provided that your requirements don't change after you've begun coding. Good luck making *that* happen. :)
> Indeed, it can...provided that your requirements don't change after you've begun coding.

So true.

> The man Edsger Dijkstra recommended teaching 'a language not implemented on any computers at the University'

Wow.
Bill Karwin said…
Methodologies like agile can be used for good or evil purposes. I've worked at a couple of companies that claimed to be "agile" but that was just a euphemism for, "we don't like to write down requirements."

It doesn't mean agile is harmful, because you can certainly have the same irresponsible habits in a waterfall project or while using any other methodology.

I would even argue that if one does no engineering documentation, then one is not using a methodology. At that point, it can't be called engineering, or science, or even art. It can only be called "play," or at best, "labor."

If anything, agile techniques help mitigate the damage when you're stuck doing software development in a mode without project planning. At least agile principles like continuous integration and frequent interaction with the users can correct an errant course of action sooner.

The role of IDE tools is to reduce the cost of doing repetitive work. They are not a substitute for analysis and design, which are non-repetitive. But too many developers start any task by opening their IDE, instead of getting up at a whiteboard or using a pencil.
> Bill Karwin said...

Yep.
Anonymous said…
The error is assuming that one set of practices works for all situations. If you are designing a tight algorithms like shortest path or sorting, thinking hard about the solution will get you further along than just starting to code. On the other hand if you have to demo a user interface or check that business rules have been completely specified the best thing is to just implement it and have the user test it against real data.

And while good thinking and design make things like quicksort possible even Knuth is aware that careful design is no guarantee of perfection, after all didn't he say once: "Beware of bugs in the above code; I have only proved it correct, not tried it."?
CharlesMerriam said…
I remember a great, short lecture on Agile, Scrum, and the like. The crux of the lecture was that these were all methods for correctly specifying the level of quality and depth required for differing features of a product. They worked only in areas where immediate client feedback was possible and features were separable into discrete work units. The result was a product, rapidly developed, with high quality in the features actually cared about by the customer.

This to me is crux of hitting the constantly evolving requirements target.
> The error is assuming that one set of practices works for all situations...

Excellent comment.
Patrick Corcoran said…
That's funny. In the early 80's I would write most of my programs with paper and pencil. And a lot of the time they worked first try, too. (I'm sure they were not as complicated as Mr. Bensoussan's were.)

This was a necessity: coding during high school classes, it would have been too conspicuous to set up my Apple ][ on my desk and start typing. But few teachers would interrupt a student who was busily writing.
CharlesMerriam said…
We may be coming back to a day of pencil and paper, hearalded by the acceptance of terse languages like Python.

In college, I would often write exact code on paper. Then I found myself getting used to idioms, and only writing difficult sections of code. Writing on paper took too long.

I might as well type "RM_Patient *pat; RM_Record *rec; for (pat = RM_FirstPatient(); pat = RM_NextPatient(pat); pat != NULL) { ...". Or I might write pseduocode: "for pat in patients:". I would often find myself typing in the pseducode, looking it over, and then expanding it line by line.

Perhaps with terse languages, it might become worthwhile to debug on paper again.
> But few teachers would interrupt a student who was busily writing.

Very nice ;)
> Perhaps with terse languages, it might become worthwhile to debug on paper again.

I think one attraction of pencil and paper is that it's very flexible, but it forces you to slow down and think.