Re: C++ fluency
On May 11, 9:04 pm, Phlip <phlip2...@gmail.com> wrote:
Andy Champ wrote:
Really? I've never heard of any avionics programme run like
that. Do you have a reference?
You mean besides Robert C. Martin teaching TDD at Boeing?
http://www.fastcompany.com/magazine/06/writestuff.html
That's an interesting article, because it makes it quite clear
that the organization in question *doesn't* use TDD. "about
one-third of the process of writing software happens before
anyone writes a line of code", "The central group breaks down
into two key teams: the coders - the people who sit and write
code -- and the verifiers -- the people who try to find flaws in
the code." In fact, it almost sounds like they're using the
system where the programmers don't even have access to the
compiler.
I particularly like the fourth point: "Don't just fix the
mistakes -- fix whatever permitted the mistake in the first
place." Any time an error is discovered in a test, you consider
it an error in the process, and also try to find out what went
wrong with the process. (In practice, I don't think that this
should apply to unit tests. Although typically, I find that if
a unit test fails, it's a sign that I didn't think enough about
the code before writing it.)
In fact, it's an excellent (albeit over glamourized) article on
what a good development process really looks like. Which isn't
TDD (at least as you've been presenting it).
The equivalent steps are...
- every code change reviewed during the change
(review of static code, post-change is less important)
- logging every change & every bug
- both white and black box tests
- running the build environment & all tests after every edit
- collecting requirements in realtime...
But those are steps of every process, more or less. And some of
them contradict what you've been arguing: wasn't it you who said
that external code review wasn't cost efficient.
Put another way, if you took that process and then streamlined
out the excesses (pseudocode, multiple teams, multiple
redundancies, strict type checking, automated proofs, etc.),
you would have competitive commercial software development
with a low bug rate.
Yep. Been there, done that. (I've worked in places at SEI 3.)
Except that some of what you've mentionned (e.g. strict type
checking, or even automated proofs, when applicable) aren't
redundancies: they actually reduce the cost of development, at
the same time reducing the number of errors.
(That's an important point to make. At least up to a certain
point---if the places I've worked are typical, that point is
around one error per 100 KLoc of code---improving quality
reduces total development cost. Beyond that, I don't know. I
suspect that making the step from one error per 100 KLoc to one
per 400 KLoc or more would increase cost. Worth it for things
like the space shuttle, but not necessarily for general software.)
Studies of very large projects have shown that the more
carefully they collect all their requirements up front, the
more likely they are to fail.
Which studies?
http://www.google.com/search?q=standish+group+software+chaos
Who cares, since no one works like that. That model is just a
strawman.
There are, of course, exceptions---I've implemented network
protocols where at least a large part of the
requirements----those in the RFC---were available from the start
of the project. But even in those cases, it's not the software
development process which insists on it; it's just the facts of
the case.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34