| When Should We Test?
|
|
25 Sep 04 |
|
[print
link
all
] |
|
Kent Beck, one of the people that invented extreme programming (XP) offers
an economic model. The financial risk management community and the software
development community can learn a lot from each other. Think of this
article as: When should you put Risk Management into place?
Amongst other things this article tells you when best to have children :-).
groups.yahoo.com/group/extremeprogramming/files/when%20should%20we%20test.pdf
|
| Lean Software Development: An Agile Toolkit by Mary and Tom Poppendieck
|
|
25 Sep 04 |
|
[print
link
all
] |
Very interesting book. Highly recommended. This books brings the lean
production principle to software development. Seven lean principles:
- Eliminate waste: Spend time only on what adds real customer value
- Amplify learning: When you have tough problems, increase feedback
- Decide as late as possible: Keep your options open as long as practical,
but no longer
- Deliver as fast as possible: Deliver value to customers as soon as they ask
for it
- Empower the team: Let the people who add value use their full potential.
- Build integrity in: Don’t try to tack on integrity after the fact -
build it in
- See the whole: Beware of the temptation to optimize parts at the expense of
the whole
Link
|
| Simple things ..
|
|
25 Sep 04 |
|
[print
link
all
] |
I was just now doing some research on bus ticket clearing houses and I came
across his post in rec.travel.europe from 2001 by Michael Forrest.
>Reciprocity is not guaranteed on airlines (or toll bridges - it
>has always amused me that the toll on the Severn Bridge between
>England and Wales is GBP 4.20 for a car to enter Wales but there
>is no toll the other way, ie entering England). (Maybe it shows
>how the two countries value themselves?)
All of the bridges in the San Francisco Bay area only charge toll in one
direction. Some genius realized that, on the average, just about as many
cars went each way for the obvious reason that most trips across the
bridges are round trips. So they doubled the toll and took down the toll
booths going one way (except for the Golden Gate Bridge where the toll
booths remain, unattended). There has been considerable saving in toll
collection costs and the toll booth traffic jams in one direction are gone.
Is it possible the Severn Bridge does similarly?
|
| Quote of the day
|
|
25 Sep 04 |
|
[print
link
all
] |
|
(Source: Kent Beck posted this to the XP-mailinglist)
This from a lean manufacturing consultant:
Find the simple path to what works and follow it, always looking for a
simpler path.
Patrick D. Smith
|
| Re: Forth, Befunge, Whitespace, or Malborge: which is hardest to write buggy code in?
|
|
25 Sep 04 |
|
[print
link
all
] |
(Source: comp.lang.forth)
>>Here is a version of Forth that runs under Windows, written in Whitespace:
>
>>
>>I can't get it to run. Do you think my browser has clobbered the code?
Hmmm. I did exactly as the web page[1] suggests: "What do you do? Simply
print it out and delete the file, ready to type in at a later date.
Nobody will know that your blank piece of paper is actually vital
computer code!" I sure hope that I didn't mistake my only copy of the
source code for an ordinary blank page!
Perhaps writing my Befunge[2] compiler in Malborge[3] and then making it
to a Forth[4] compiler written in Whitespace[1] wasn't such a good idea...
References:
1 http://compsoc.dur.ac.uk/whitespace/
2 http://dmoz.org/Computers/Programming/Languages/Befunge/
3 http://www.freebsd.org/cgi/query-pr.cgi?pr=28147
4 http://www.cbel.com/forth_programming_language/
|
| Forth "versus" Whatever
|
|
25 Sep 04 |
|
[print
link
all
] |
From comp.lang.forth
>>Which brings me to an excellent 'forthism' I once read in a
>> newsletter. It stated:
>>
>> "You can do anything in Forth - but you must be prepared
>> to do it yourself."
In a recent discussion in c.l.functional, about why popular languages
are popular, I summarized the relationship between Lisp and Forth
more-or-less as follows:
"From the Lisper's perspective, every other language is a cute subset
of lisp; whereas from the Forther's perspective, every other language
is a cute extension of Forth."
|
| Modeling on White boards
|
|
25 Sep 04 |
|
[print
link
all
] |
|
(Source: Scott Ambler) I just posted "Software Modeling on
Whiteboards" at link.
It describes how whiteboards can be an effective modeling tool.
Basically it’s an ad for Whiteboard Photo. ;-)
|
| Forth Database
|
|
25 Sep 04 |
|
[print
link
all
] |
Richard S. Westmoreland postd this to the Forth-ML.
In years past, we have implemented some extremely complicated databases in
Forth. The first was done in the mid 1970's for the company Cybek in NJ,
and it was used in some extremely complex applications. FORTH, Inc. also
did some very complex databases for other companies, one of which was still
in use last time I checked, at www.calmuni.com. That one was a
2-dimensional database, with a huge bit matrix in the center used to
calculate overlapping bonded indebtedness. A few years ago my contact there
told me that a state agency had just spent several million $$ trying to
replicate it using modern database tools, but the result was too large and
too slow to be usable.
In the late 1980's we added class-based techniques to it, which many people
liked (although I personally preferred the earlier, simpler version).
It's hard to describe the whole approach in a newsgroup post, though. It
certainly didn't resemble SQL!
|
| Software Bug Causes Soyuz To Land Way Off
|
|
25 Sep 04 |
|
[print
link
all
] |
|
A mysterious software fault in the new guidance computer of the Soyuz TMA-1
spacecraft was the cause of the high-anxiety off-course landing over the
weekend, according to NASA sources.’ Which is why I will never trust
the Strategic Defence Initiative - the star wars project. It only takes one
line of mistyped code in what will always be a beta release. www.msnbc.com/news/909677.asp
|
| XP style process and battle-fields
|
|
25 Sep 04 |
|
[print
link
all
] |
|
Not that I want to promote war in any way, but these posts in the
extremeprogramming-ML made me smile:
Phlip:
During the planning game, you review last week's
finished stories, and they inspire you to write some
new cards, to edit some cards, and to toss some cards.
Then you (the Onsite Customer) re-sort all the cards,
and draw off the top batch for the next week.
But another input into this system that affects the
planning game - the competition.
The USA occupied Iraq using an effective new battle
technique. In traditional advances, you send a
diversionary force against one of your enemies flanks,
draw them that way, then send your main force against
their other flank.
Modern soldiers, with cell-phones and such, follow a
more agile approach. You simply send two forks of your
forces, probing towards both flanks. You use sensitive
algorithms to detect the defending commander's
decision which flank to defend. If you can rapidly
turn one advance into the diversion, and the other
into the main attack, you will soon collapse the
opposition's ability to effectively make decisions.
Agile onsite customers can play this card too. If you
detect your competition's marching orders, in
real-time (using either sensitive algorithms,
good-old-fashioned industrial espionage, or just
reading their self-congratulatory Web site), you can
then request iteration features which provide the
minimum amount of code needed to start your project
towards blocking the competition's advance. This
technique will, again, collapse the competition's
ability to make decisions.
Or convince them to hire an XP coach or three. So
either way it's a win-win-win for us! ;-)
Steven’s reply: :-)
Or you could follow the agile strategy that Microsoft
pioneered - announcing products with your competitions'
features before you even start implementing them.
|
| Industrial waste - Process waste
|
|
25 Sep 04 |
|
[print
link
all
] |
|
(Source: Phlip posted this to the XP list) "Industrial waste" is
when a factory produces something it shouldn’t. Heat, smoke, extra
chemicals. This is wasteful because it represents energy and materials that
went into the factory, but did not come out as product.
"Process waste" is the behaviors that don’t produce a
working product. The biggest waste in the industry today is
"programming in the debugger". This is so endemic nobody even
calls it waste. Our vendors work very hard to supply us with advanced
debuggers, so we can merrily cause problems and then fix them, instead of
preventing problems.
Another big waste is delayed integration. Some shops account for how many
modules we must write, then specify the modules’ interfaces, and tell
each programmer to write a module separate from the others. Then at the end
of this cycle the programmers start trying to integrate. They might not
even have build scripts to plug the modules together; they might find
themselves manually integrating by clicking on the user interface to an
IDE.
Delayed integration costs some orders of magnitude more than the cumulative
cost of continuous integration does.
Get ahead of these problems. Write tests first, constantly review code,
don’t own code, and integrate continuously. Write and maintain build
scripts that support all these behaviors seamlessly.
Don’t delay surprises. If "our product has an installer"
appears as a motherhood story, integrate the installation system early, and
test it every day. Don’t wait for the last iteration.
The ideal is that the last week before a big release should look and feel
just like any other.
|
| Lean Manufacturing and Software
|
|
25 Sep 04 |
|
[print
link
all
] |
|
(Source: Bill Wake) Is writing software more like manufacturing cookies or
more like designing cookie cutters? It’s easy to wish that we could
develop software like a factory stamps out cookies, but software has a
design or creation element that is missing in that analogy.
But there are similarities: software is developed in stages, it is created
in a process amenable to change, and it’s developed in a team. Lean
manufacturing is a different approach than a traditional assembly line, and
offers some lessons for software development. xp123.com/xplor/xp0312/index.shtml
|
| What's the Second Directive?
|
|
25 Sep 04 |
|
[print
link
all
] |
|
(Source: Ron Jeffries, aka Mr. XP) I’m been struggling for years with
notions like having empathy with our mistakes, Kerth’s Prime
Directive, and the like. Springing from a couple of notes on the
extremeprogramming group, and a blog entry from Dale Emery, here’s my
latest rant. xprogramming.com/xpmag/jatPrimeThis.htm
|
| Where is the snow?
|
|
25 Sep 04 |
|
[print
link
all
] |
Summertime .. so all we do is to ski-roller. High time for the snow to come
back and cool it down a bit. I found that pic a long time ago on I have
forgotten what website.
|
| Skolelinux: V1.0 with codename Venus is out! |
|
25 Sep 04 |
|
[print
link
all
] |
Skolelinux is made as free (as in speech) software, and is an overall computer solution based on school's resources and needs. It is based on Debian and runs very well on older hardware, too.
- Skolelinux is a network architecture tailored for use in schools.
- Skolelinux is designed to be easy and cheap to maintain.
- Skolelinux gives the students their own usernames, home directories and services.
- Skolelinux includes OpenOffice.org
link
|
| [XP] Alistair interview on IT Conversations
|
|
25 Sep 04 |
|
[print
link
all
] |
|
I was just sent the link for an online interview about agile development.
The interview was done last month, it got posted yesterday. You don’t
have to register to listen
link
|
| The Linux Incompatability List
|
|
25 Sep 04 |
|
[print
link
all
] |
|
Saw this on /.
"The Linux Incompatibility list is
a wiki project that attempts to document hardware that is incompatible with
Linux rather than list what is compatible. In the wiki, it is possible to
add alternitives so as to push hardware manufacturers to make good binary
drivers, publish specifications, or even better, publish open
drivers."
|
| Extreme Leadership
|
|
25 Sep 04 |
|
[print
link
all
] |
|
An interesting read. Patterns of extreme Leadership by Kent Beck. pdf
|
| My LinuxTag 2004 photos
|
|
25 Sep 04 |
|
[print
link
all
] |
|
Some photos from LinuxTag 2004 in Karlsruhe. I especially liked the Xbox
booting Linux screenshots. pics
|
| Selling XP
|
|
25 Sep 04 |
|
[print
link
all
] |
|
Alistair Cockburn has a very interesting paper on "The Costs and
Benefits of Pair Programming". Of course Pair Programming is not the
only "extreme" aspect of extreme programming but Alistair’s
article contains some very interesting metrics (seems a lot less
"extreme" after reading Alistair’s article). members.aol.com/humansandt/papers/pairprogrammingcostbene/pairprogrammingcostbene.htm
|
|
|