C++ fluency

[Phlip]

You seem to have ignored or misread a great deal of what this says. For
example, at least by your definitions

If you read the rest of my post I suggested they could throw that redundancy
away. The point: No "big requirements up front", and constantly testing &
reviewing the act of changing. On non-mission-critical software you don't need
redundancy...

>
> Once again, you don't seem to have really read what was written. Of the
> California DMV project, they said:
>
> The project had no monetary payback, was not supported
> by executive management, had no user involvement, had
> poor planning, poor design specifications and unclear
> objectives. It also did not have the support of the
> state's information management staff.
>
> The alternative to a "poor design specification" would appear to be a
> better design specification -- IOW, they seem to be indicating that MORE
> should have been done to collect requirements up front.

Exactly: Whenever the project goes sour, poor up-front requirement gathering
appears to have been the fault. If only we could have done moar!!

http://www.codinghorror.com/blog/archives/000588.html

'Asked for the chief reasons project success rates have improved, Standish
Chairman Jim Johnson says, "The primary reason is the projects have gotten a lot
smaller. Doing projects with iterative processing as opposed to the waterfall
method, which called for all project requirements to be defined up front, is a
major step forward."'

Collecting all project requirements up front adds to your risk.

 

[James Kanze]

That's also how it's done in any Agile management practice.

And in every serious process I've every heard of.

Note that XP is NOT an agile project management methodology
but a development practice methodology.

Interesting. I thought that "agile" was a rebranding of XP.
(Of course, both being "in" technologies, the exact meaning of
them tends to vary with whoever is talking.)

To see Agile management methods you need to look at Scrum,
Lean, and others and these have nothing to do with TDD (with
the last D meaning development OR design). In these
processes, when you find a bug it goes back on the list of
things to do, and goes through the same sets of management
processes that happened before: bidding, scheduling, etc...

You can't just fix bugs willy-nilly as you find them. They
need to go through a process that reviews the bug and decides
what effects a fix will have, how expensive it will be to fix,
and when and if to fix it. The "customer" is in charge in
Agile development, not the developer, as it should be.

And as it always has been, in any well run organisation. Every
place I've ever worked (even the poorly run ones), the final
decider has been whoever pays. (I don't think it's a new idea:
as a kid, I heard a saying about "who pays the piper calls the
tune". Which would suggest that the principle predates computer
science, maybe by some centuries.)

Frankly, I'm super-glad we don't do XP. I could never do pair
programming. For one thing I hate people standing over my
shoulder. For another thing, having to tell another person
what I'm doing, as I'm doing it, when I'm trying to solve a
problem is incredibly difficult. For some reason the areas of
my brain that do programming don't speak english too well.
Once I'm done, I can tell someone what I've done without any
problem, but to tell them as I go requires constant context
switching that is quite slow and frustrating.

That's interesting.

I think different people do react differently here. As soon as
the code is non-trivial, I'll write out exactly what it is to do
in some "human" language. About like explaining it to a peer
programmer, except that the explination is memorized by the
machine, so it is available to all (and I don't tie up a second
programmer for nothing). More generally, if an idea or a
requirement or whatever isn't written down, IMHO, it doesn't
exist. Or it won't exist, at least not in exactly the same
form, at a later time.

Any development methodology needs to account for and adapt to
all personalities or it simply can't work.

Adaptability is the key. It's what is meant by the English word
"agile", and it's a characteristic of all good methodologies
(again, going back to before computers---people didn't wait for
computers to manage projects).

 

[James Kanze]

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.)

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.

 

[Ian Collins]

And in every serious process I've every heard of.


Interesting. I thought that "agile" was a rebranding of XP.
(Of course, both being "in" technologies, the exact meaning of
them tends to vary with whoever is talking.)

Certainly not, XP has never claimed to be a project management methodology.

 

[James Kanze]

[ ... ]
You seem to have ignored or misread a great deal of what this
says. For example, at least by your definitions, they seem to
fully espouse the "big design up front" methodology:
"...carefully planning the software in advance, writing no
code until the design is complete, ..."

That's clear. The organization in question is well known, as it
was the first to attain SEI level 5.

Note that this does not contradict iterative development. It
does mean that each iteration will have a design phase preceding
the actual coding.

They fail to mention one crucial aspect of writing high
reliability. Typical software is delivered by itself, to be
used on whatever hardware the user already posesses, in
conjunction with whatever other software they happen to
have/get. High reliability software is run only on the
specified hardware, with only the specified software
installed. The difference this makes would be hard to
overstate!

The difference isn't that black and white. Most large scale
servers run on "dedicated" machines, but those machines (and the
OS on them) are still standard commercial offerings. You can't
reach the reliability of the space shuttle software with them
(since the OS itself isn't that reliable), and there's no point
in your software being more robust than the OS, *IF* it costs
more to make it so. (Typically, you can be several orders of
magnitude more reliable than the OS at negative cost---the steps
you take to improve reliability reduce development costs.)

 

[James Kanze]

It sounds like you either have an enormous number of tests, of
they go beyond unit tests. I'd expect to be able to run
several thousand unit tests per minute.

Each unit test checks only a single set of input. Most
functions have billions of possible input, if not more. How
exhaustive do you test? (The answer, of course, depends. But
given the non-linearity of computer logic, you often need quite
a few.)

 

[Phlip]

Certainly not, XP has never claimed to be a project management methodology.

You might notice some posters here are projecting whatever they don't like about
bad software practices on XP, without bothering to learn it...

 

[Phlip]

Each unit test checks only a single set of input. Most functions have
billions of possible input, if not more. How exhaustive do you test?
(The answer, of course, depends. But given the non-linearity of computer
logic, you often need quite a few.)

Given a website with 50 different skins (CSS folders), I tested all the
skins like this:

max = SLOW_TESTS ? 50 : 5

skins.sort_by(&:rand)[0..max].each do |skins|
test_this_one(skin)
end

You integrate in FAST_TEST mode, and only test 5 random skins. The test
server runs in SLOW_TEST mode.

Oh, and any skin-specific tests that you just changed in the last 10 minutes
run when you integrate, too.

 

[Noah Roberts]

>
>
> And in every serious process I've every heard of.

I'm sure you're right. I was responding to the apparent statement that
Agile was somehow different here.

>
>
> Interesting. I thought that "agile" was a rebranding of XP.
> (Of course, both being "in" technologies, the exact meaning of
> them tends to vary with whoever is talking.)

Not sure of the exact history but it appears that "agile" came first and
Scrum before XP.

http://en.wikipedia.org/wiki/Agile_software_development#History

In reality, most places that are successful at developing software
probably use many methods similar to "agile" methodologies without
calling them "agile". See the 12 "principles":

http://agilemanifesto.org/principles.html

And as it always has been, in any well run organisation. Every
place I've ever worked (even the poorly run ones), the final
decider has been whoever pays. (I don't think it's a new idea:
as a kid, I heard a saying about "who pays the piper calls the
tune". Which would suggest that the principle predates computer
science, maybe by some centuries.)

"Customer" has a particular meaning in agile methodologies that isn't
exactly the same as the normal sense of the word. The "customer" is
anyone who represents the customer in the team, or set of teams,
involved in the project. It's an actual position in the team. They are
the ones who decide what features go on the top of the stack of things
to do and the person you go to, as a developer, when you have a
question. The difference between "customer" in the normal sense and in
the "agile" sense is that they are actually PART of the team in agile
methodologies.

In our case, since we don't usually write software by contract, we don't
exactly have a "customer" in the normal sense--someone that hired us out
to write something. What we have instead is someone who works for us
that represents the target audience for the product we're hoping to
sell. They act the part that a customer hiring us to write software
normally would.

wiki has a decent overview of Agile software development:

http://en.wikipedia.org/wiki/Agile_software_development#Introduction

 

[Gerhard Fiedler]

(I've vaguely heard of systems for small, embedded processors, where
you could control the timing of external events, but I've never
actually seen one.

Not that relevant here, but since you brought it up: There are several
simulators that combine a SPICE-like engine for external circuitry with
a simulator for the microcontrollers that executes programs. There are
also much simpler simulators that just simulate the microcontroller and
let you define input states and changes at exact times, usually in
multiples of the instruction cycle. Most manufacturers of smaller
microcontrollers supply a simulator of the latter type.

In both cases you can control the exact timing of external events that
are inputs to the micro and the program that runs on it. (This doesn't
solve the explosion of possible combinations, of course.)

Gerhard

 

[James Kanze]

Certainly not, XP has never claimed to be a project management
methodology.

Well, there seems to be a good deal of confusion in the
literature about both---the price of being commercially
"successful", I guess. Still, XP does seem to be a component of
agile programming (at least in the majority of web sites which
turn up when I search for both), and the same people seem to be
behind both.

 

[James Kanze]

James Kanze wrote:

I'm sure you're right. I was responding to the apparent
statement that Agile was somehow different here.

I understand that.

When it comes down to it, if you take the word "agile" at its
literal English meaning, all of the processes I've seen are
"agile". About the only thing that wasn't "agile" was the
absense of any process. But I've been lead to believe that
"Agile" is somehow something different than "agile"---a buzz
word which means the way the author is trying to sell.

Not sure of the exact history but it appears that "agile" came
first and Scrum before XP.

In reality, most places that are successful at developing
software probably use many methods similar to "agile"
methodologies without calling them "agile". See the 12
"principles":

http://agilemanifesto.org/principles.html

Thanks. At least now I know what we're talking about. Some of
the "principles" are provably false, of course, or at least of
limited applicability. ("The most efficient and effective
method of conveying information to and within a development team
is face-to-face conversation." for example. Complex information
can't be conveyed except in writing. In a real sense,
information doesn't even exist until it's written down. The
spoken work is too volatile.) Others are sort of vague, and
maybe contradictory: "Our highest priority is to satisfy the
customer through early and continuous delivery of valuable
software." (What happens if the customer doesn't want
"continuous delivery"? In my experience, most don't.)

"Customer" has a particular meaning in agile methodologies
that isn't exactly the same as the normal sense of the word.
The "customer" is anyone who represents the customer in the
team, or set of teams, involved in the project. It's an
actual position in the team. They are the ones who decide
what features go on the top of the stack of things to do and
the person you go to, as a developer, when you have a
question. The difference between "customer" in the normal
sense and in the "agile" sense is that they are actually PART
of the team in agile methodologies.

That's an important clarification. The statements about
"customer" in the "Agile Manifesto" were very bothersome,
because they seemed to contradict what my customers want. (What
they want is to not be bothered until the system is delivered.
Obviously, we can't always give them that, since I've yet to see
a request that didn't need clarification, but they certainly
wouldn't accept being involved in a weekly meeting.)

In our case, since we don't usually write software by
contract, we don't exactly have a "customer" in the normal
sense--someone that hired us out to write something. What we
have instead is someone who works for us that represents the
target audience for the product we're hoping to sell. They
act the part that a customer hiring us to write software
normally would.

The customers where I work (and this had been true for most of
the places where I work) are other departments, in house. They
have a perceived need. What they want is to vaguely express
this need to us, and for us to magically deliver a system that
meets it in all the details (including those not mentionned),
without bothering them in the meantime. Practically, this means
that most of the people in the team are domain experts (in order
to accurately guess what is really needed).

wiki has a decent overview of Agile software development:

http://en.wikipedia.org/wiki/Agile_software_development#Introduction

If that's it, it doesn't sound very applicable to most of the
projects I've worked on. Projects just aren't that small, and
you need some higher level management.

 

[James Kanze]

Not that relevant here, but since you brought it up: There are
several simulators that combine a SPICE-like engine for
external circuitry with a simulator for the microcontrollers
that executes programs. There are also much simpler simulators
that just simulate the microcontroller and let you define
input states and changes at exact times, usually in multiples
of the instruction cycle. Most manufacturers of smaller
microcontrollers supply a simulator of the latter type.

In both cases you can control the exact timing of external
events that are inputs to the micro and the program that runs
on it. (This doesn't solve the explosion of possible
combinations, of course.)

I've used in-circuit emulators for the older Intel processors.
I don't remember being able to control the timing of external
events, but that was many, many years ago; things obviously have
changed since then.

 

[James Kanze]

Given a website with 50 different skins (CSS folders), I
tested all the skins like this:

max = SLOW_TESTS ? 50 : 5

skins.sort_by(&:rand)[0..max].each do |skins|
test_this_one(skin)
end

You integrate in FAST_TEST mode, and only test 5 random skins.
The test server runs in SLOW_TEST mode.

That sounds like a good idea. Not sure how to integrate it into
my makefiles, however---maybe two separate targets (localbuild
and export?). (Obviously, choosing all of the tests randomly
isn't always the best solution, but you can probably find a
reasonable subset somehow.)

Oh, and any skin-specific tests that you just changed in the
last 10 minutes run when you integrate, too.

That will be a bit trickier to add to the makefile.

 

[Ian Collins]

Well, there seems to be a good deal of confusion in the
literature about both---the price of being commercially
"successful", I guess. Still, XP does seem to be a component of
agile programming (at least in the majority of web sites which
turn up when I search for both), and the same people seem to be
behind both.

I'm not aware of anything called "agile programming". There are a
number of agile processes, XP and Scrum being the most widely known.

In my current organisation, we use Scrum for project management and we
are adopting XP as our development process.

I suggest you do a little more more research before commenting further.
You appear to be deriding something you have never tried.

 

[Noah Roberts]

Thanks. At least now I know what we're talking about. Some of
the "principles" are provably false, of course, or at least of
limited applicability. ("The most efficient and effective
method of conveying information to and within a development team
is face-to-face conversation." for example. Complex information
can't be conveyed except in writing. In a real sense,
information doesn't even exist until it's written down. The
spoken work is too volatile.)

Yeah, I don't like that one too much either but for a sort of different
reason I guess. I don't like having face-to-face conversations that
never happened. It's hard to show that something DID happen if you
don't have a written record of it.

I've also found, in my experience, that face-to-face conversation isn't
even half as effective as email or IM. Get everyone together for a
meeting and nothing happens; have the meeting through email and stuff
gets decided.

I agree with much of the rest though.

 

[Noah Roberts]

Others are sort of vague, and
maybe contradictory: "Our highest priority is to satisfy the
customer through early and continuous delivery of valuable
software." (What happens if the customer doesn't want
"continuous delivery"? In my experience, most don't.)

"Continuous delivery" helps the developer as well. Constantly keeping
the product ready for release at a moment's notice makes sure the thing
is tested regularly to the degree that would be required to release.
Sort of like unit testing on a larger scale, you have a fairly good idea
that the features that have been developed so far are stable enough for
a customer.

Where I work, the previous method was for the testers to basically start
mass testing at the later phases of development. Many times I would end
up having to debug something I wrote a year ago. It's much better if
the testing is done in parallel with my development so that when I'm
assigned a new task I have a good idea that I won't have to go back
again. It takes time to learn even your own code sometimes and the
human brain simply cannot keep enough information in it to encompass
several features and the design of the objects that construct them.

In fact, I'd say that previous to implementing "agile" development, this
company used what would very much resemble the "waterfall" method.

"Agile" development specifies a system that causes the tests to be run
in parallel with my development. This is a more efficient way of doing
things. Even if you look at it and say it's nothing special to
constantly be running tests, it helps to have something with a name on
it telling you to when you try to convince an owner who is worried about
switching methodology when they've been doing it that way for decades
and successfully selling products.

But there are some subtle differences I think, between "agile" methods
and simply iterative development. It might help to analyze the
difference between the unified process and the "agile" unified process:

http://www.ambysoft.com/unifiedprocess/agileUP.html

 

[James Kanze]

James Kanze wrote:

[...]

It's a statement of fact: Verbal communication is more
efficient at transmitting information, simply because of the
extraordinary amount of verbiage that can be excluded. For
example, a raised eyebrow from the listener, at the right
time, is a cue to skip ahead to the next topic.

The actual, proven fact, is that verbal communication is not an
effective method of ensuring information transmittal. That's
why, for example, contracts aren't verbal. And who's ever heard
of a verbal reference work.

If the information isn't written down, you don't have it.

You are requesting a different valence and intent for the
communication - not that it can transmit, but that it can be
referred back to.

The two are related.

The best documentation is executable "customer tests" that
actually pass when their documentation is correct. That idea
is as old as "literate programming", and here's three overly
documented versions of its modern incarnation:

http://fitnesse.org/
http://cukes.info/
http://assert2.rubyforge.org/

The above sites seem more marketing than technical.

The goal is to merge two activities - testing and documenting
- so neither wastes the other's time. (The last site is that
project's own unit tests, decorated into a cute website to
document their API. Customers are programmers!)

And the result of merging is that neither is optimal. They
target different problems, so need different solutions.

 

[Phlip]

The above sites seem more marketing than technical.

Ding! argumentum ad crumenum! Back two squares!

 

[woodbrian77]

James Kanze wrote:

    [...]

It's a statement of fact: Verbal communication is more
efficient at transmitting information, simply because of the
extraordinary amount of verbiage that can be excluded. For
example, a raised eyebrow from the listener, at the right
time, is a cue to skip ahead to the next topic.

The actual, proven fact, is that verbal communication is not an
effective method of ensuring information transmittal.  That's
why, for example, contracts aren't verbal.  And who's ever heard
of a verbal reference work.

If the information isn't written down, you don't have it.

If you allow "written down" to include written down
by the heart, in other words, valued, I would agree.
Unless someone first writes something down in their
heart, I don't think the results of writing by hand
are going to be very good.


Brian Wood
Ebenezer Enterprises
www.webEbenezer.net