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.
I am a professional software developer, and I would like to argue that the top 5 most impportant things about good software is (in order of preference, most preferencial first):
1. Stability
2. Robustness and speed
3. Sufficient comments (one comment every 3 lines)
4. Passing large objects as constant references and not by value
5. Viewing your code in assembler afterwards and using a profiler to look for bottlenecks
Of course, the above mentioned things are not enough, but I believe it is a good place to start. Any other ideas?
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
Mod parent comment (pun intended) up ... comments are evil. Code should
first and foremost be self-documenting, by the
choice of proper variable names and subroutine
names. Only comment things that are not obvious,
like tricks that are employed. The point is that
comments are not read nearly as much as names,
and get stale more quickly, rendering them useless.
In the Fortran variant I was working in until a few years ago, local variable names were limited to five (5) characters, and many otherwise obvious functions were performed by a series of external subroutines with six-character names usually beginning with SY (for "System").
That meant that the code itself could be quite hard to follow without some sort of logical commentary accompanying it.
I tended to comment my code quite heavily in that context, since I'd already had experience with uncommented code in that context and knew how hard it could be to follow...
(Try reading Fortran that's all in column 7 and which is mainly composed of arithmetic IFs and CALL statements sometime and see how intuitive it is!)
When using more modern languages, I tend to comment less, sometimes a lot less. It usually comes down to a judgement call on my part as to whether or not I think the code would be easy for a newcomer to maintain...
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.
At my company the management has started an MDA (Model Driven Architecture) project, because some developers presented it to them as the holy grail in software development. They use a GUI to make associations between classes and ASL for the code. They say that you are less likely to make a mistake because you code in a platform independent way (so, you do not have to pay attention to all the little details) and the translator is responsible to make the actual code.
Some of us more experienced developers do not think it is the holy grail. It looks like you can make as much mistake as in convetional languages. Also, development with a GUI (see at www.kc.com) is much more cumbersome.
Is there anyone who used MDA and ASL and has some experience about it?
Government cannot make man richer, but it can make him poorer. - Ludwig von Mises
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.
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).
This is only partly correct. If you design your software via Use Cases and Scenarios or User Storiers, then the possible pathes are in gereat deals predefined. That means you can do black box tests with out any need of white box tests.
To check wether your black box test cover all the code you do a coverage analysis.
White Box tests finally have total different goal!
With doing black box tests, you do tests driven from the outside, usually according to some spec. What you most of the time don't know is wether the spec is closed (has no gaps, does not leave undefined inputs open) etc. The goal is to ensure all legal inputs work.
So you use inspections to spot places where all the black box tests likely won't reach into. E.G. the coverage tool will show you such lines of code. Now you make your white box tests to "cover" those lines as well. The goal then is to catch "illegal" inputs and to ensure the code does at least accept them gracefully.
The question what to do depends on your over all goals and risks. In business applicatins its usually "good enough" to have balck box tests which cover all lines of code.
In an avionic system, thats NOT enough. Here white box tests are much more important.
Finnaly, the way you test affects your system architecture. The way you ensure robustness affects your system performance. And so on
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Comments are valuable at a relatively high level, where you describe what the code is supposed to do. The code itself documents what it actually does, but there's no way for a person reading it later to determine if it is doing what it is supposed to do without a comment that explains the intent. For example: "// Long divide in place, junking the data, but leaving the reminder" is very useful to the person who comes along later and doesn't know that the code actually wants this odd result, and wouldn't have a chance of figuring it out if the code didn't compute it correctly due to a bug.
Any programmer that tries to "convince" management that quality assurance checking is desirable will be first on the outsource-to-India list.
Management doesn't want any backtalk about "quality". They expect the programmers to do things right the first time; that's what they're paide to do. When management has compliant workers in India that work cheap, follow instructions, don't talk back, and aren't around the manager's office geeking up the place, they're not going to bother with "quality assurance" insubordination. In particular, programming methodologies such as Extreme Programming that require greater management involvement in the coding process will be treated with scorn; management wants less involvement, not more. As to whether or not the code actually works - once it's out the door and bonuses are in hand, who cares?
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.
If you are giving a talk to people in small businesses do you want to give them a list of things they can do or have an esoteric discussion over the relative reliability data for C++ and Java exception models ?
.. Rackspace are advertisers
I'm glad you don't think the content is original - that means you are one of the people who actually has some idea of how to write good code and automate/enhance the testing side. Unfortunately to a lot of people out there actually writing code in business the concepts are new.
This was Alan's morning talk to local businesses. I'm suprised it was even worthy of slashdot, when things like Indymedia disks being seized by the FBI and rackspace are apparently not even noticed by the slashdo crowd
Oh wait
8)
Alan
Cox really does highlight some of the best practices out there, but he also skims over some key ones. The biggest problem I've seen out there (and I've done QA Management consulting for a good chunk of those 10 yrs, so I've seen a lot of organizations) is commitment by management. Most QA folk know that there will always be a challenge to find the right balance between schedule/budget, quality of product, and feature set of the product. Do you want it good? now? or stripped down? And most QA folk are willing to work within that mindset. But when management 1) does not appropriately staff QA activities; 2) does not appropriately fund QA activities & annual budgets; 3) does not make it damn clear to all staff that QA is a requirement for project and thus ultimately product success and if you don't like someone testing your code and logging bugs against it, you better move along pardner, the organization pays lip service to QA. Heck even when QA finds a horrible problem prior to release, so there's time to fix the problem, you'd think most folks would be happy (ok, not thrilled because that balance is skewed towards a schedule slip) that there was time to get in a fix. But no, 99 times out of 100, QA is slammed for holding up the process.
Independent testing is a must for an organization to have any real understanding of the quality of the product. Engineers cannot be the only folks testing their outputs. For oone, it's a very expensive way to test - I want geers designing & coding & unit testing not integration or system or release testing. QA folks will cost between 30-70% of a geers salary - why would you want the most expensive resource doing the (in most cases) less technically demanding work? And work they usually don't enjoy doing anyways (grumble grumble, I didn't sign up for this!)
OK, so this is a bit of a rant. I'm just dealing with my current senior management who say they want QA to manage and execute the independent testing, but turn around and find 95% of Engineereing who refuse to participate in the process.
I'll just go have a beer and forget about my problems...mmm... beer... drool drool.
"Content's a bitch."