Skip to main content

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.


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'.
Anonymous 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. :)
jjinux said…
> 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'

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.
jjinux said…
> Bill Karwin said...

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."?
Unknown 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.
jjinux said…
> The error is assuming that one set of practices works for all situations...

Excellent comment.
Anonymous 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.
Unknown 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.
jjinux said…
> But few teachers would interrupt a student who was busily writing.

Very nice ;)
jjinux said…
> 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.

Popular posts from this blog

Ubuntu 20.04 on a 2015 15" MacBook Pro

I decided to give Ubuntu 20.04 a try on my 2015 15" MacBook Pro. I didn't actually install it; I just live booted from a USB thumb drive which was enough to try out everything I wanted. In summary, it's not perfect, and issues with my camera would prevent me from switching, but given the right hardware, I think it's a really viable option. The first thing I wanted to try was what would happen if I plugged in a non-HiDPI screen given that my laptop has a HiDPI screen. Without sub-pixel scaling, whatever scale rate I picked for one screen would apply to the other. However, once I turned on sub-pixel scaling, I was able to pick different scale rates for the internal and external displays. That looked ok. I tried plugging in and unplugging multiple times, and it didn't crash. I doubt it'd work with my Thunderbolt display at work, but it worked fine for my HDMI displays at home. I even plugged it into my TV, and it stuck to the 100% scaling I picked for the othe

Drawing Sierpinski's Triangle in Minecraft Using Python

In his keynote at PyCon, Eben Upton, the Executive Director of the Rasberry Pi Foundation, mentioned that not only has Minecraft been ported to the Rasberry Pi, but you can even control it with Python . Since four of my kids are avid Minecraft fans, I figured this might be a good time to teach them to program using Python. So I started yesterday with the goal of programming something cool for Minecraft and then showing it off at the San Francisco Python Meetup in the evening. The first problem that I faced was that I didn't have a Rasberry Pi. You can't hack Minecraft by just installing the Minecraft client. Speaking of which, I didn't have the Minecraft client installed either ;) My kids always play it on their Nexus 7s. I found an open source Minecraft server called Bukkit that "provides the means to extend the popular Minecraft multiplayer server." Then I found a plugin called RaspberryJuice that implements a subset of the Minecraft Pi modding API for B

Creating Windows 10 Boot Media for a Lenovo Thinkpad T410 Using Only a Mac and a Linux Machine

TL;DR: Giovanni and I struggled trying to get Windows 10 installed on the Lenovo Thinkpad T410. We struggled a lot trying to create the installation media because we only had a Mac and a Linux machine to work with. Everytime we tried to boot the USB thumb drive, it just showed us a blinking cursor. At the end, we finally realized that Windows 10 wasn't supported on this laptop :-/ I've heard that it took Thomas Edison 100 tries to figure out the right material to use as a lightbulb filament. Well, I'm no Thomas Edison, but I thought it might be noteworthy to document our attempts at getting it to boot off a USB thumb drive: Download the ISO. Attempt 1: Use Etcher. Etcher says it doesn't work for Windows. Attempt 2: Use Boot Camp Assistant. It doesn't have that feature anymore. Attempt 3: Use Disk Utility on a Mac. Erase a USB thumb drive: Format: ExFAT Scheme: GUID Partition Map Mount the ISO. Copy everything from