Approximity blog home
722 to 731 of 801 articles

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

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

New Russian bestseller :-)   25 Sep 04
[print link all ]
A big thanks to Leftenant Berezka for the pics :-).

Been coding hard now on SW and CFaR. I would really need some good vodka now before getting up early tomorrow morning to catch the train.

Hope you all had a good weekend, -A.

This vodka bottle reminds me that I am way behind on Futurometer. We will kick ass there soonish!

Is Tableau the Next Google?   25 Sep 04
[print link all ]
link

example graphs

 Will this company be successful and become another Google?
 First, graphical data mining has never been a big hit. And second,
 there are lots of competitors in the business intelligence sector,
 including at least Business Objects, Cognos, Hyperion and MicroStrategy.
 So make your bets and wait for the next multibillion-dollar IPO.

Only hire people who pair?   25 Sep 04
[print link all ]
(Source: Chad Woolley posted this to the extremeprogramming-ML) Here’s an interesting experience I had when interviewing for an XP shop, and one I will definitely keep in mind in future interviews, whether I am the hirer or hiree.

As part of my interview, I was required to sit and pair program for about half an hour. We worked on an writing a unit test for an actual defect that currently existed on the project (although it could easily have been a real user story, or a contrived scenario if the project had not yet started).

I thought this was a great idea, and a great source of knowledge for both sides. I was able to show that I did indeed know how to program, write unit tests, knew my way around an IDE, had acceptable interpersonal communication skills, etc. I was also able to get a different perspective on what the team dynamics were like, which I could not have gotten from a formal interview setting.

The interesting thing is that both me and my partner (one of the interviewers) taught each other about some tools and approaches that we were not previously aware of.

Even though I didn’t get the job (the position was withdrawn), I kept in touch and became friends with the interviewer/partner, and the things we taught each other came in useful in our future development work.

This company also asked for code samples and a mini-presentation, which I also thought was a great idea for separating the wheat from the chaff.

Since I have had responsibility for helping interview, select and recommend job candidates in the past, I know for a fact that the best resume and interview performance in the world is inconclusive. You can still get a lemon, even though the lemon may be very good at piling on the BS.

From my perspective as a job candidate, I am confident in my skills and my abilities. I know that I can quickly adapt and excel in any position within my skill set. However, its very frustrating when I cannot convince the potential employer of this through only a traditional resume and interview.

In future interviews that I go for (which will hopefully only be with XP/Agile shops), I am going to suggest this as a way for the hiring company to get a better idea of my skills, knowledge and abilities, both technical and interpersonal. If I am ever part of a hiring team in the future, I will definitely propose that code samples and a pair-programming session be part of the interview process for candidates who make it to the final stages. This is admittedly very time-consuming, but probably much less net investment than being forced to live with (or try to get rid of) an employee who looked much better "on paper".

Thanks, Chad

Kaizen Events   25 Sep 04
[print link all ]
(Source: Keith Ray) Keith Ray has an interesting entry on Kaizen Events in his blog. Kaizen Event definition from Ray’s blog: The Kaizen method is a "rapid improvement process" utilizing a cross-functioning group of managers and employees working as a team to meet targets in a results-oriented focus on a predefined project area. The process may take the following steps: define the problem/opportunity, choose the best people, and correct the problem in one week or less using Kaizen tools and techniques. The ultimate goal is to significantly reduce costs, reduce lead times, reduce required inventory space, enhance workforce empowerment, eliminate waste, and focus on continuous improvement. The Kaizen process may include: new product development, robotics, total quality control, Just-in-Time, statistical quality control, labor and management relations, or other concepts.

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.

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.

How to Construct Bad Charts and Graphs   25 Sep 04
[print link all ]
(Source: Gary Klass) A short but good article in the style of Edward Tufte, the big guru when it comes to displaying data in a meaningful way. Fundamental rule of efficient graphical design: minimize the ratio of ink-to-data The three fundamental elements of bad graphical display are these: Data Ambiguity, Data Distortion, and Data Distraction. link Make sure you check out these classic bibles about envisioning information by Tufte: Envisioning Information and The Visual Display of Quantitative Information

Adapting Extreme Programming   25 Sep 04
[print link all ]
Kent Beck posted this today to the XP-mailinglist.

I’ve been thinking about the problems of applying XP to whole organizations. Turns out this is ground thoroughly covered by the lean production folks.

Here is a paper I found helpful: www.nwlean.net/no_harm.zip The premise is that every step of the transformation must pay for itself.

Getting people to understand that their problems are tractable can be hard, I’ve found. Rob Mee was talking to a guy about TDD on a gig of ours recently. "Sure, yeah, TDD is a great idea." "Why don’t you do it?" "It’ll make us go slower." "But it makes you go faster." "Yes, of course, but it’ll make us go slower." "But it’ll make you go faster" *iterate N times for annoying large N* "Okay, it makes people go faster everywhere but here."

 

powered by RubLog
722 to 731 of 801 articles Syndicate: full/short
A unique and safe way to buy gold and silver