Sie sind hier: agile & lean Blogs

OOMCube100.png

Recent Change Note: from The Impact of Object Orientation on Application Development 1993
OOMCube100.png

Interesting little proof that square root of 2 is irrational

Reading “My Mind is Open” about mathematician Paul Erdos (thanks, Mho) I saw but didn’t have time to digest the simple proof that sqrt2 is irrational. So I did it in my head in the taxi on the way to the hotel.

But I have never been happy with proof-by-contradiction, because exactly as the woman in the book said, I always feel like I got lied to in the beginning.

So I invented the “can’t possibly equal” symbol:

cantpossiblyequal.png

for the sole purpose of being able to present the proof forwards.

Here it is, the first-ever proof using the cantpossiblyequal symbol, that the square root of 2 is irrational:

proof sqrt2 is irrational.png


postscript: last night, falling asleep, I was wondering if the square root of any prime is irrational. Applied the same proof with similar results. But it seems to me that any integer root of any prime number is irrational. I haven’t written it down, but it seems to follow the same pattern, just replace the (2) in the sqrt with (i) for (i)th root, and replace the prime (2) with the prime (p).

Any mathematicians out there confirm?

Alistair


A story about the last responsible moment and real options

“Jobs couldn’t decide whether to use the version with his voice or to stick with Dreyfuss. Finally, the night came when they had to ship the ad; it was due to air, appropriately enough, on the television premier of ‘Toy Story’. As was often the case, Jobs did not like to be forced to make a decision. He told Clow to ship both versions; this would give him until the morning to decide. When morning came, Jobs called and told them to use the Dreyfuss version.” (from “Steve Jobs”, by Walter Isaacson, p 331)

A perfect story for Last Responsible Moment reconsidered (discussion: Re: Last Responsible Moment reconsidered) and the real options option. A great illustration also of easy / queasy / nightmares. I’ll bet everyone else was having nightmares, and he slept easy.


oomcube.png

Recent Change Note: Precursor to Crystal, not bad for 1992!
oomcube.png

Sweeping the lines on a clay tennis court

A friend showed up on my doorstep the other day, dressed in tennis whites with smudges from the clay courts. Those were indeed the days when one was supposed to wear white on tennis courts, especially on the clay tennis courts at private tennis clubs.

She wanted my advice on, of all things, the shortest walking distance for sweeping the lines on the clay court after playing.

True… after playing hard tennis for an hour, she wanted to save a few steps while brushing the dust off the lines as required by club rules. (Indeed, most of the tennis players I’ve met would dearly love to know how to cut a few steps off their line-brushing paths. That’s why I’m writing this article!)

So I pulled up a drawing of half of a tennis court:

clay tennis court layout.png

and consulted Euler's Seven Bridges of Koenigsberg problem, the one that started the field of topology and looks almost like a tennis court.

Euler said that if there is a vertex with an odd number of lines into or out of it, then that has to be a starting or ending point.

Consulting the tennis court map, we see there are 12 vertices, of which no fewer than 10 have an odd number of insies/outsies (so to speak)! Egads! That means we get to walk TO one of them at the start, AWAY from one at the end, leaving 8 remaining!

In other words, we will have to pick up the brush no fewer than 4 times along the way.

No wonder my tennis-playing friend was feeling so frustrated.

Doing some math, I found that the walking distance for A (on the diagram above) is shorter than that for B, shorter than for C, D, and E, in that order. And the alleyways are the shortest of all, so we’ll definitely want to use those. In other words, for the 4 times we have to pick up the brush, it will be shortest to use the two alleyways, and A and B, and try not to walk C, D, or E.

This still leaves quite a lot of choices, which is good, because it means my friend can either just get into a groove and brush the lines the same way each time, or can shift around the A and B walks to make quite a lot of different patterns.

My choice for her is shown in the following walking pattern:

clay tennis court sweeping pattern.png

Next time you’re on a tennis court, clay or not, see if you can find the shortest walking path to walk along all of the white lines.

Best wishes :)


On specification

Recent Change Note: "On Specification" 5/28/1987

Different people have varying views of the needs and definition of a specification. One says the minimum requirement of a specification is that it be executable; The other requires assertions and proofs to be possible in the language. Lamport calls a specification a contract between user and implementer such that neither must talk to the other; Brooks says that clients do not and can not know their needs well enough to write such a contract.

What is a specification, really? At what point can one say that a thing is fully specified?

I hope this little story gives us some distance to examine our prejudices about specifications:

A vendor needs to transport some fragile items to a sales point. Ne engages a contractor and tells nem:

“I want you to build me a truck to transport these items so they don’t break.”

Contractor replies, “Is that all you have for requirements?”

“Um, no. I have to be able to afford it and it has to fit into the driveway.”

The contractor measures the driveway and the fragile items. Ne subcontracts a customizing firm, giving nem details: truck length, height, weight, power, certain shock absorbing characteristics, as well as customer modifications to be able to mount a special shock-absorbing cage. Ne also subcontract the make of the cage, giving similar information.

To shorten the story, we might skip over the expansion of the details given by the various subcontractors to their workers to ensure that the truck and cage will all be satisfactory.

The contractor returns to the vendor with the bids.

“But this is too expensive!” ne exclaims, to which the contractor explains the various unusual features, including certain shock-absorbing bumpers, built-in roll bar, and built-in music system and radio which come with this particular truck.

The vendor decides it is all worth it and agrees to the extra cost.

This is a happy story in that all parties deliver on time and spec, and the vendor is satisfied.

Some time later, however, ne mentions to the contractor that although the truck is working out quite well, it is a shame about the length of time needed to transport nes items and the noise the truck makes. Ne is shocked to hear the contractor say,

“Well, I didn’t think to mention it, since you asked for a truck, but since you always go to the sames sales point, I could have provided you with a nice teleportation device for the same money…”

Questions

1. Was the order given by the vendor to the contractor a specification or not? Why or why not? Was it any of formal, executable, provable, or verifiable?

2. Were the orders given by the contractor to the subcontractors specifications? How about the orders give to the workers? Which of the specifications were like to have been formal, which verifiable, which executable?

3. What does it mean for a truck to fit in a driveway? Wheels on the pavement or sides not extending beyond the pavement? What does it mean to “afford” a truck (assume a figure was named)? What is the significance of nes suddenly being able to “afford” more on discovering extra features?

4. How does the unexpected possibility of teleportation affect one’s understanding of the original specification?

Some thoughts

  • A specification is given to resolve a problem or desire. One use of specification may be to remove the dependence between client and contractor. It may happen that the client does not know enough to resolve all the decisions in implementing the specification (and that may be fairly normal).
    s
  • A problem or desire allows a certain design space, and is narrowed down to the final implementation by making design choices. Every time a design decision is taken, the design space shrinks.
  • A specification is notification that certain design decisions have been taken and the design space has been reduced. Each new specification should necessarily satisfy the previous; it may well happen that direct implemenation is for many stages not practical.
  • Automatic implementation merely means that there is a known algorithm for resolving all remaining design decisions.
  • The automatic design choices may not be (rarely are) optimal; one hopes they are acceptably efficient, and lives with the loss.

This definition of specification, “a notification that certain design decisions have been taken” is unusual in that it presents the specification as a document of th post instead of a document of the future.

Further, it indicates that a spec is a statement of what may NOT be done, rather than what must be done. This definition allows different uses of specification by different people, viz., decoupling of work efforts, verifying constraints, etc. That a spec adopts a particular model is not in the least improper, as somewhere along the way every design decision much be met anyway.

  • For a spec to be acceptable to a group only means that they all accept the model (design choices) so far. If someone really wishes to disagree with a model, ne can appeal to a higher-level version of the specification.

hmmm, what does this say about the behavior of standards bodies?



(Note: I just found this note in my old papers. A fun find.)


Dunks Farm Puzzle

Recent Change Note: via Wayne Stevens (r.i.p.), the single most interesting puzzle I've seen.
Dunks Farm Puzzle

Alistair in skydive.png

Alistair in skydive.png

Pictures of things it is possible to do without dying 1.png

Recent Change Note: (wish I knew where I got this old postcard)
Pictures of things it is possible to do without dying 1.png

Derivation of Methodology Tools (journal entry 1993)

Just found an old hand-written journal, dated May 1993, with my then-notes on methodologies and methodology tools. I find it interesting reading, as it refers already back then to business scenarios and Warburton, who introduced me to personas also back then in 1993.

Here is the photo of the journal entry. You probably have to be a hard-core geek to read it, but if you are, I think you will also find it interesting.

Derivation of Methodology Tools journal entry 1993.gif


Alistair Cockburns Blog