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 Wales, working in partnership with Know How Wales, Knowledge Exploitation Centre and Cygnus Online, has unveiled plans for an exciting new programme of events specifically targeted at computing professionals from both business and academia.
During the launch breakfast, held in Sketty Hall Swansea, on Thursday 23rd September, Beti Williams, Director of IT Wales, outlined the aims and objectives for the group.
"The IT Wales Advanced Technical Computing Group will help to establish and promote Wales as a country with an international reputation for innovation and excellence in Computing and Information Communication Technologies. It will provide a platform for collaboration between computing professionals from business and academia, enabling them to drive forward the computing industry in Wales and stimulate awareness of the diverse applications of computing. The group will also be well placed to highlight the skills required to meet the future demands of the global computing industries."
Guest speaker Alan Cox, a graduate of the University of Wales Swansea and one of the most influential IT innovators in the world, offered the audience an entertaining and thought provoking insight into the current limitations and human failings of the software development process.
The full programme of events will commence in January 2005 and will link with organisations including the British Computer Society, Welsh E-Science Centre and Natural Computing Forum.
Details will be published through itwales.com and e-mailed directly to IT Wales business club members. For full video footage click on one of the links below
To register interest in receiving information from the Advanced Technical Computing Group e-mail details to info@itwales.com
Presentation:
Real Media File (31kbit, 7.5MB,
320x240res)
mpg video (120kbit, 25.5MB,
160x120res)
High quality DivX and 330kbit mpg files available here
DivX version also available in the business club members section
Questions:
Real Media File (31k, 3.3MB, 320x240 res)
mpg video (120kbit, 11.2MB, 160x120 res)
High quality DivX and 330kbit mpg files available here
DivX version also available in the business club members section
As always, mirrors of the pages and the movies are here: MirrorDot. Enjoy.
~Jay
"no time for social lives"? like they would know what to do if they did?
but seriously, good managers manage. Bad managers threaten, cajole, bribe or whine. software is either a product, which means that management is monitoring to be sure the product is what they can sell; or software is a tool, in which case the manager must ensure that the tool works.
either way, successful software is a combination of good programming and good management.
Our company has some loose rules (we're working on strengthening them) that state that checked in code must be unit tested. This is to prevent things like your #5. But we haven't gotten to code reviews yet. Being on the team that's working on our process, I'll remember your experiences when we get to code reviews.
Against stupidity, the gods themselves contend in vain.
What? Projecting the test cases before the software is written? If you plan to do some black-box testing this is acceptable, once you can plot the test cases based on the software formal specification. But I guess you know there are software testing approachs other than functional (black-box) testing. If you intend to do some structural testing (white box) it is impossible to write test cases before writing the software, once the testing requeriments are defined by analyzing the source code (that's why it is called white box testing).
Stupid job ads, weird spam, occasional insight at
It's an iterative process. You don't necessarily write a complete suite of tests for your interfaces before you start writing a single implementation. Someone in QA might think of a unit test as white box, but they tend to be black box from the perspective of the developer. You should be able to write a unit test before writing the unit.
The point of most unit tests is to verify an implementation's conformance to its interface. When you later change the implementation, you would likely invalidate a white-box test or, if it still happens to be valid, weaken its premise.
it's working again after I upped the server processes a bit :)
my first slashdotting, fun.
Gareth
Don't say:
double sum = 0.0;
for (i = 0; i < len; ++i)
{
double signal = buf[i];
sum += signal*signal;
}
return sqrt(sum/len);
say:
double sum = 0.0;
for (i = 0; i < len; ++i)
{
double signal = buf[i];
sum += signal*signal;
}
return sqrt(sum/len);
In other words, tell me WHY this code added the square of the signal, not THAT it added the square of the signal.
Moreover:
If more folks would follow these rules it would be a HELL of a lot easier to follow their code.
NOTE: If you can say it in the code, do so - if you can specify the exceptions to your function via a "throw(int code)" type statement, then do so rather than using a comment.
Remember - the code tells the COMPILER and the programmer what is going on, the comments tell the programmer WHY it is going on.
www.eFax.com are spammers
For DOS/Windows/OS2 etc:
h tm)
Gimpel Software's:
PC Lint (cheapish)
Flexelint (pricier)
Freeware (checks GDI leaks)
bear.exe (http://www.geocities.com/the_real_sz/misc/bear_.
gdiobj.exe (http://www.fengyuan.com)
Linux:
Electric Fence (free)
Valgrind (free)
Splint (free)
Books:
John Robbins books on debugging. Concentrates on Win 32 but useful ideas wise for any x86 platform.
And now the gags...
Tools I've not found helpful.....
Rational Rose!
Microsoft's beloved COM!
Linux fan and Win32 developer
Quality Assurance is not testing.
Testing is testing, and can run the gamut from unit to use case, from integration to system, from acceptance to beta. But QA is not testing. A lot of people call testing QA, but it is not the same thing.
Testing is what you do when you get the code. QA is everything that you do throughout the software development cycle to ensure that you have quality software. This can include code reviews, process audits, statistical analysis, etc.
I have been doing QA and testing for 11 years now. I have a degree in computer science, and I CHOSE to do this career. You may be able to get away with ignoring QA professionals and still produce high-quality software. But not all software projects are equal. QA is probably the most overlooked part of software development, testing the second.
My beliefs do not require that you agree with them.
"More importantly, write the tests FIRST. Then write the code"
But write which tests first? There are so many possible. Usually there are more ways for something to malfunction than for it to function correctly.
How do you write a test to check that a banking application does not allow a customer to cancel other customer's cheques? How do you write a test to check that someone didn't allow sql injection? How do you write a test to ensure that a user account cannot do what it is not authorized to?
Since there are usually more ways to test something to check limits than to use it within the limits, your suggestion makes changes a lot more expensive. If you do the code first (and haven't finished writing the 10 tests for it) and people say "We don't like the way that works in practice", you haven't wasted time writing 10 tests. Whereas if you do it the other way round, they can only find out they don't like it after you've written the 10 tests AND the actual code.
Your suggestion probably works well for certain scenarios, but appears counterproductive for many others.
First, you confuse "unit testing" with "application testing". You are writing the tests for a *part* of the app, not the whole. So, to use your example, you are writing the tests for parsing a customer's auto-pay entries - not the whole app.
SO:
Your first unit test is a simple "return pass"
You run your test framework and verify everything works.
Commit the changes into the main line branch.
You then change your unit test to "return fail". Run test framework and verify it fails. (NOTE: You do all of this IN YOUR PERSONAL DEVEL BRANCH, not in the mainline code.)
Now, define the first tests for your function - test that it does what is is supposed to do. In this example you would define some simple, correct auto-pay setups and submit them to your module, and confirm the module returns the correct data. At this point, you are now FORCED to give some consideration as to what the inputs, outputs, and API will look like - one of the benefits of this approach.
You now start on the module, creating a stub routine that does nothing.
Run the tests - they should fail as you are not yet "doing what you are supposed to be doing".
Implement the module. If, during this part you discover you have to change the API you also change the tests as needed. Run the tests as you go.
Eventually, you will have a pass - your module is "doing what is is supposed to be doing". Now you add more test data - different valid transactions, and different invalid transactions. You modify the test to pass IF the valid operations pass AND IF the invalid operations are detected and correctly failed.
Run the tests. Watch them fail as your module barfs on the bad data.
Fix the module to deal with the bad data. Run tests. Repeat until tests pass.
Do code review on module. Sally spots a potential problem. Add test case to test. Verify tests fail. Fix problem. Repeat until module passes review.
Merge module and test with mainline code branch and re-run tests.
Now, you have a set of tests for your "auto-pay setup" module. Meanwhile, the others who are implementing the "generate statement", "send bills", and suchlike modules have done the same, so your test framework validates each module. The idea is to limit the scope of failures - you prove each module behaves itself, so the number of possible failures AT THE APP LEVEL is greatly reduced.
Now, George finds a case that causes you module to barf, and writes a bug in the bug tracking system (you *ARE* using a bug tracking system, aren't you?).
You add the bad case to the tests, verify they break, commit change.
You fix the module, and verify the fix. Commit change, mark bug as FIXED.
Your Q/A guys verify that the run before the fix is broken, the run after the fix is OK, and VERIFY the bug, OR they suggest other possible tests that break the system. If so, repeat the last three steps.
Sure, this is no "silver bullet" that will eliminate all bugs. What this DOES do is catch the bugs as quickly as possible, when they affect as little of the project as possible, and VERIFIES that they are indeed fixed and STAY fixed.
www.eFax.com are spammers
Section comments. Within long functions, just a few words every 10-30 lines, breaking it up into logical sections, can make it much easier to understand the flow, or find the particular section you're looking for.
Even better: just make the "sections" a separate function and give them good names.
And for those who don't like exercise, I suggest Joel. Samples:
"The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they've been fixed. There's nothing wrong with it. It doesn't acquire bugs just by sitting around on your hard drive. Au contraire, baby!... it has grown little hairs and stuff on it and nobody knows why. Well, I'll tell you why: those are bug fixes.
One of them fixes that bug that Nancy had when she tried to install the thing on a computer that didn't have Internet Explorer. Another one fixes that bug that occurs in low memory conditions. Another one fixes that bug that occurred when the file is on a floppy disk and the user yanks out the disk in the middle. That LoadLibrary call is ugly but it makes the code work on old versions of Windows 95.
Each of these bugs took weeks of real-world usage before they were found. The programmer might have spent a couple of days reproducing the bug in the lab and fixing it. If it's like a lot of bugs, the fix might be one line of code, or it might even be a couple of characters, but a lot of work and time went into those two characters. When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work."
Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.