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:
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
Indeed, it can...provided that your requirements don't change after you've begun coding. Good luck making *that* happen. :)
So true.
> The man Edsger Dijkstra recommended teaching 'a language not implemented on any computers at the University'
Wow.
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.
Yep.
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."?
This to me is crux of hitting the constantly evolving requirements target.
Excellent comment.
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.
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.
Very nice ;)
I think one attraction of pencil and paper is that it's very flexible, but it forces you to slow down and think.