Slashdot Mirror
Alan Cox on Writing Better Software
Andy Gimblett writes "Alan Cox recently gave a talk in which he discussed some current and emerging techniques for producing higher quality software. Some of these will be familiar to Slashdot readers, such as validation tools, type checking, etc, but others seem heavily influenced by his recent MBA. In particular, he has a lot to say about Quality Assurance in the software world, and the kinds of things we should be doing (and some people are doing) to make better software. Story and lots of quotes at Ping Wales, and video at IT Wales."
It's quite surprising to me that there's no mention here of unit testing, or any sort of automated testing where the engineers who wrote the code actually write tests.
It should, by now, be clear that "code that doesn't have tests, doesn't work", and that if XP has done anything for us, it's to focus on writing tests. I've seen this in action and it works.
John.
My employer produces a large-ish software package, with 10 years of history and a small, 2-3 people, development team. Since I joined we have made massive strides in automating the build process, include some unit tests, and a few smoke tests in an automated process.
Well, the effort paid off. Before we supported one version of HP/UX, and one release of Linux, now we support HP/UX (still a pain), and 4 looking at going to 6 Linux version/distributions and it is less work to produce a release now than ever just a year ago.
Tools like automake, autoconfig, libtool, cvstrac and of course cvs have made my life bearable.
Funny, that. I recently started working at a company with mandatory code reviews. Here's a list of my recent experiences with it:
1) Checked in code. Spent fifteen minutes justifying design decisions. No changes made.
2) Checked in code. Code contained horrible horrible bug. Code reviewer didn't see it.
3) Checked in code. Defended my design against several more computationally expensive suggestions that were also more complicated. No changes made.
4) Listened to a friend gripe about having to spend a DAY AND A HALF repeating design reasons and fixing bugs introduced by his code reviewer "cleaning up" his code.
5) Received company-wide email about a build that flat-out didn't compile - apparently someone hadn't bothered compiling a patch, and had sent it to a code reviewer, who likewise hadn't bothered compiling it before authorizing it.
Now I'll admit that there are also a whole lot of "well, it only took five minutes, so it wasn't much of a waste" cases. But so far I haven't heard one person talking about how useful the mandatory code reviews are.
Maybe it's just an artifact of the kind of programmers working at this company, or the kind of code being worked on, but so far code reviews have been a net loss in my experience. I've taken to doing major changes in my own personal branch of the repository (which doesn't enforce the code-review requirement) and in a month or two I'll have 3000 lines of code for someone to look at - but at least I won't have nickel-and-dimed them to death with 120 100-line code reviews, 3/4 of which I will inevitably end up deleting entirely.
Note that I'm not saying "code reviews are bad" - what I am saying is that there's a time and a place for just about every technique, and there's also a time and a place where each technique is worse than useless. Pick your battles and pick your tools.
Breaking Into the Industry - A development log about starting a game studio.
...are nifty. They can catch all sorts of stuff and produce lovely reports - or, well, at least functional reports. And running them nightly - or hourly - helps to ensure the code won't get out of sorts.
PLUG: Need to check Java code? Try PMD!
The Army reading list
Reusable, reliable, quality software begins with the interface. If someone cannot tell what a routine or module does with just a quick read, then all is lost. They'll cease to believe what the documentation (if any) says, and go on to write it themselves.
The solution is better interface design. Clear, concise naming without ambiguity. And including the specification is absolutely necessary. With the contract included as part of the interface, there is even less chance for error and/or any ambiguity. Testing is aided because the rules for calling a routine are right there with the routine interface and comment.
Unfortunately, most programming languages refuse to support contracting in any form, and most developers don't see the benefits. Until this hurdle is breached, quality software will not be achieved.
Steve
--
remember Sammy Jankis
This type of sanity checking is especially useful for training junior programmers. It can be very instructive for a senior programmer to sit down with a junior progammer and go through their code together. The primary purpose of a review should be to have a second set of eyes on the code but it is very valuable for training and communication as well.
1. Listen ...
2. Close your mouth
One problem with this: By listening with your mouth closed, you run a very real risk of misunderstanding what you're hearing. Without feedback to verify that you're understanding, you are highly likely to do things completely wrong.
Funny example: A few years ago, I was implementing an interactive web site, and we had a nice test server machine in the lab. In one discussion with The Mgt, I casually mentioned that for testing, I thought we needed to run another server.
I didn't hear any response, so I went ahead and cloned the apache server that we were using, and fired it up on a different port. 10 minutes work, and we proceeded to test.
A while later, I discovered just in time that the managers had heard me say that we needed a second server machine, and were ordering another one. After a bit of discussion, I realized that to them, a server is a piece of hardware, while to us software guys, it is a piece of software.
I managed to explain to them that, no, we didn't need a new machine. I'd already set up a second web server on the old machine, and it was working fine. There was still time to cancel the hardware order.
But still, they had done a bunch of unnecessary work, and had almost spent a good sum of money unnecessarily, all because they had listened carefully without asking questions. If they had asked what hardware the new server needed, I'd have realized quickly that there was a misunderstanding, and we could all have saved a bit of time.
Listening without interacting, and acting on your understanding of what you heard, can lead to a lot of serious problems.
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
(steps 1 and 2 may be reversed if required)
Enjoy good results.
I've fallen off your lawn, and I can't get up.