Approximity blog home
893 to 902 of 903 articles

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

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.

.. like Xmas   25 Sep 04
[print link all ]
I came across this nice discussion between Phlip and Juergen Ahthing in the XP-ML
 "Without test-first and refactoring, clients think
 they must assemble as many program requirements as
 they can afford to have written. This effort snarls
 all relative business priorities together, making
 Scope Control impossible. It obscures opportunities
 for simplification. Designing and implementing many
 features all at once is very hard, leading to our
 industry's reputation for very large failures. Putting
 tests in front of development's inner cycle permits an
 outer cycle of incremental feature growth. That
 relieves the Customer of the responsibility to predict
 the future and guess which complete set of features
 will maximize productivity."

.. Juergens answer:

 Nice description.
 Sometimes I try to explain that to non technical people
 with the following picture:

 If you have only one chance to get your wishes on a
 list, it is like Christmas for a child. You make sure
 you get every little wish on that list and hope for the best.

 If you are sure that you can get your wishes on the list
 at any time. You will just put the most important ones
 there which come to your mind easily.

What is XP?   25 Sep 04
[print link all ]
Ron Jeffries posted this well known Kent Beck quote in the XP-mailinglist. They talk about the 2nd ed. of XP Explained by Kent Beck.
 But anyway, when I last asked Kent what XP is, he said
 "XP is a community of software development practices based on
 values of simplicity, communication, feedback, and courage".
 That was about two or three years ago.

 I look forward to seeing the second edition as well.
 I'm sure it will be enlightening ...

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.

Extreme Leadership   25 Sep 04
[print link all ]
An interesting read. Patterns of extreme Leadership by Kent Beck. pdf

XP is fractal.   25 Sep 04
[print link all ]
(Source: Ken Boucher posted this to the xp-mailinglist)
 > Surely, you're not calling design documents you built in the middle
 > of a project "up-front" design?

Let’s talk about "project" and "up-front" for a second.

In the old world I came from, a project had a feedback loop. This feedback loop could be considered to have covered design to unit testing, roughly a period of 6 months to a year on many projects. In other words, I would get feedback on my design 6 months after I made it.

Now let’s enter the fractal nature of XP.

My design to unit test feedback loop is the duration of a card in most cases. In some cases it’s as small as design/refactor/new test/new code/refactor/ (which may be a scope of minutes). In some cases it may be as large as an iteration (after all, we didn’t pick the cards in this iteration at random, we had a plan). It may even have been as large as a release plan.

The difference is that I get my feedback quickly and the design I do at any given stage is as small as it needs to be instead of as large as it can be. But I still do design "up-front". I have a plan before I leave the release meeting. I have a plan before I leave the iteration meeting. I have a plan before I even start refactoring before that first unit test. I have to make the same decisions I would have made in the BDUF, the only difference is that I make them as late as possible. In short, I make them just before I do the task that requires that decision to have been made.

XP is fractal. It’s possible to think about an XP project as a large collection of projects, each small enough to be written on 3*5 cards. And I do design for every one of those projects up front.

Knowledge Management from personal content management tools   25 Sep 04
[print link all ]
I shamelessly copy this blog-entry from here
 Below is a quote from Dave Pollard, the former Chief Knowledge Officer from
 Ernst & Young. It is a great paragraph because is is truly representive of
 why enterprise knowledge managment solutions failed. He is talking about the
 fact that knowledge managment systems have to be personal content management systems first.


 I believe personal content management tools are the place to start, because
 since the earliest days of business, the principal way of sharing information
 has been peer-to-peer, the most valued 'repositories' of business information
 have been personal filing cabinets, and the principal schema for organizing
 work has been the personal desktop. It makes sense, therefore, that tools
 that facilitate and reflect these well-established 'knowledge processes',
 information sources and networks should be much more successful than the complex,
 centralized, hierarchical knowledge management tools and repositories that have
 been foisted on users for the past decade.

 End Quote:

 It is a great quote because how is it possible that anyone could believe that
 a centralied hierarchical tool could work when it was in no way related to how
 people did and have done knowledge work since the beginning.

Samizdat - 0.5.2 is out   25 Sep 04
[print link all ]
Samizdat is a generic RDF-based engine for building collaboration and open publishing Web sites. It will let everyone publish, view, comment, edit, and aggregate text and multimedia resources, vote on ratings and classifications, filter resources by flexible sets of criteria, and cooperate and coordinate on all kinds of activities. It intends to promote values of freedom, openness, equality, and cooperation.

Samizdat homepage

Slides Dmitry Borodaenko presented about Samizdat ath the Euruko 2003

How Org Charts Lie   25 Sep 04
[print link all ]
(source: Harvard Business School) In an excerpt from Harvard Business School Press Hidden Power of Social Networks, learn how "social network analysis" reveals problems your org chart ignores. link


powered by RubLog
893 to 902 of 903 articles Syndicate: full/short