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."
he has a lot to say about Quality Assurance in the software world
Quality Assurance in 4 easy steps!
Dear Managers,
1. Listen
2. Close your mouth
3. Plan everything around #1
4. Profit!!! (notice there is no line with ??? because you listened!)
The dangers of knowledge trigger emotional distress in human beings.
...isn't just for end-users! If you anticipate that others will be working on future versions/releases of your software, good commenting can make the job SOOOOO much easier for the next codemonkey.
I'd say commenting is doubly important in OSS projects, as it involves many sets of eyes trying to comprehend what you coded.
There's a Mercedes gap too. I want one and can't afford one, but it's not government's job to do anything about it.
Who cares about what Alan Cox has to say? He's soooo 2.4
Unit testing is essential, but it's not a panacea. In particular, beware of two pitfalls:
1) "The unit tests passed, so it works." This assumption is flawed on several levels. First, and most fundamentally, even if all unit tests pass, there is still the issue of whether your software works as a whole. Software often has "emergent logic" and UI scenarios that are difficult or impossible to test (after all, that's not what unit testing is for, but some people seem to think it is).
Second, just because a test passes, doesn't always mean the API works. This is especially important if you didn't write the tests yourself. Just because a unit test CLAIMS it tests X, doesn't mean it does. Is the test complete? Any false positives? Is the test just a skeleton that was intended to be implemented later but never was? I've had all these bite me in the past.
2) "That particular test has NEVER passed, so there's something wrong with the test. We just ignore it now." Bzzzt! Wrong! There's a REASON it never passed. It's either not implemented properly, just a stub that fails waiting for someone to write an implementation, or maybe you just think the feature it tests actually works. Look closer. The test might be trying to tell you something.
If you are careful with unit tests, they can be very rewarding and useful (especially for regression testing, where they are invaluable), but put too much confidence in them or depend on them to do the kind of overall testing they were never designed to do, and you will fail long before your first test does.
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.
Unfortunately, when schedules get tight, it's things like unit testing (and testing in general) that get cut. The more emphasis we get on the importance of QA the better our industry will be.
Against stupidity, the gods themselves contend in vain.
The kicker is, this year that same manager wants to re-use the code that my coworker was origionally going to write.
Against stupidity, the gods themselves contend in vain.
This has several important benefits:
www.eFax.com are spammers
I'll leave the results as an exercise for the reader...
These are some things i guess is necessary for good software
1) Reviews at all stages.(Reqs/design/dev)
2) While at development, u sure must know whats the most efficient way to code a design (which libraries are more suitable etc)
3) Unit testing and Integration testing (when the project is huge)
Some practices that managers can really use to take the pressure off the team
1) Try giving buffers to the team (seriously, it works)
2) Proper Code management (Lotsa rework and pressure come due to lack of this)
3) Proper tracking and status updates to the customers
So now we're taking software writing advice from PHBs now? :)