Approximity blog home
843 to 852 of 901 articles

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.

Succinctness is Power!   25 Sep 04
[print link all ]
(Source: Paul Graham)

"The quantity of meaning compressed into a small space by algebraic signs, is another circumstance that facilitates the reasonings we are accustomed to carry on by their aid."

  • Charles Babbage, quoted in Iverson’s Turing Award Lecture

paulgraham.com/power.html

The first person to write about these issues, as far as I know, was Fred Brooks in the Mythical Man Month. He wrote that programmers seemed to generate about the same amount of code per day regardless of the language. When I first read this in my early twenties, it was a big surprise to me and seemed to have huge implications. It meant that (a) the only way to get software written faster was to use a more succinct language, and (b) someone who took the trouble to do this could leave competitors who didn’t in the dust.

Brooks’ hypothesis, if it’s true, seems to be at the very heart of hacking. In the years since, I’ve paid close attention to any evidence I could get on the question, from formal studies to anecdotes about individual projects. I have seen nothing to contradict him.

I've never been a Project Manager before   25 Sep 04
[print link all ]
Check out the excellent Dilbert

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.

Case stories   25 Sep 04
[print link all ]
Been skimming the XP-ML this morning.

About the $200M Oracle-Ford Desaster: the management did not give them enough power to go fully agile

Chet Hendrickson:

 It was a very frustrating situation.  The team asked Don and me
 to help with preventing the Oracle consutants from making changes
 directly to the production system.  This was about $150 million into the project.

 We tried to sell them on a more agile approach (as you might imagine), but by
 this time they were pretty far gone.

 It was unfortunante that we were not operating at a level in the organization
 that would have allowed us to get the plug pulled sooner.

 chet

Georg Tuparev has a nice case story, too: speak out if you are put on a death march.

 Few years ago I was called to lead a huge team stuck in one and half
 year design phase. The team was supposed to build a control software
 for a network of telecom satellites. Cannot disclosed names and
 resources, but one could imagine ...

 Three days in the project I had a phone conference with the CxO's of
 both companies involved. Told them that the way it is going no
 satellite will ever fly and that I know a better way. After getting
 green line, the design document was burned with a small celebration at
 a BBQ, and 85% of the initial team members were sent to an indefinitely
 long vacation. With the rest (15%) of the team we had the first
 functioning version 2 months ahead of the schedule and 50% lower then
 expected expenses.

 So the lessons:
 - it is never late to change direction of a project in order to save it.
 - I do not agree with Kent that this is a sad story. If you are a good
 programmer put on a death march project you should speak out! If no one
 listens - walk away. There is just one very precious life in front of
 us - do not waste it! And if these folks wasted 2 years of their lives,
 well, it is their business ... but they should not expect my
 sympathies.

 BTW, Philip is right - the project I was telling about had a 9 months x
 40 people "Big Requirements Up Front"!!! Then the design started...

 Just my 0.02

 Georg Tuparev

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

XPlorations: The Humble Yo   25 Sep 04
[print link all ]
(Source: Bill Wake) "The Humble Yo" The humble "Yo!" is a simple convention for getting help. link Nice explanation of why not asking for help can actually hurt the team.

fit   25 Sep 04
[print link all ]
Ward Cunningham has released an acceptance testing tool called fit fit is about tests that people can read.

The Cook’s Tour offers an excellent howto to get yourself and your customers into the test-writing mode.

An intro article by Bill Wake.

Communication is the Transfer of Emotion   25 Sep 04
[print link all ]
Seth Godin has put together a nice pdf about how todo decent powerpoint slides. By the way, his new book "Free Prize" is out, too.

I always enjoy reading his weblog.

Working on a book: Driving Software Projects with Examples   25 Sep 04
[print link all ]
Brian Marick posted this to agile-testing.

I’ve started work on a book, tentatively titled _Driving Projects with Examples: a Handbook for Agile Teams_. All that’s done to date is the Preface.

Two years ago, this would have been about driving projects with tests, but I think the role of examples in projects is larger than that. Also, examples fit more obviously into the whole "individuals and interactions over processes and tools" thing. Examples are something people use to explain themselves to each other. Conversations and learning are more obviously part of the picture.

Because I’m so hot on examples, I’ve put the draft book on a new site, exampler.com. Here’s the book: <www.exampler.com/book/>

(And, rather than "QA", "tester", or even "ECaBian", "exampler" might be a good name for those people on an Agile project that exhibit certain traits more strongly than other team members.)

Some of you practice the style of development I’m documenting - or variants of it. If you do, I want to talk to you, be it on the phone, or via emai, or in person. (I am budgeting travel money to visit worthy sites.) I’m serious about the "handbook" in the title: I want to fill it with tricks, tips, techniques, and stories. The more people I gather them from, the better the book will be.

 

powered by RubLog
843 to 852 of 901 articles Syndicate: full/short