Sven C. Koehler, our hard-coding dataminer has sent me an email while his code was probably exploring the DNA of some beauty. I wonder whether it was the beauty the root-team uses in their logo? Hey, just because of the logo, one ought to give root a try.

 What I was impressed about:
 http://root.cern.ch/root/Mission.html
 ``We started the ROOT project in the context of the NA49 experiment at
 CERN. NA49 generates an impressive amount of data, about 10 Terabytes
 of raw data per run.'';

 ``Thanks to the builtin CINT C++ interpreter the command language,
  the scripting, or macro, language and the programming language are
  all C++. The interpreter allows for fast prototyping of the macros
  since it removes the time consuming compile/link cycle. It also
  provides a good environment to learn C++. If more performance is
  needed the interactively developed macros can be compiled using a
  C++ compiler.'';

 http://root.cern.ch/root/Architecture.html
 ``The backbone of the ROOT architecture is a layered class
 hierarchy with, currently, around 310 classes grouped in about 24
 frameworks divided in 14 categories. This hierarchy is organized in
 a mostly single-rooted class library, that is, most of the classes
 inherit from a common base class TObject. While this organization
 is not very popular in C++, it has proven to be well suited for our
 needs (and indeed for almost all successful class libraries: Java,
 Smalltalk, MFC, etc)''.

Sven C. Koehler has started to read "Numerical Methods for Scientists and Engineers". He was so kind to send me a few quotes he likes from the introduction.

 Most books on computing stress the estimation of roundoff,
 especially the bounding of roundoff, but we shall concentrate
 on the avoidance of roundoff.  It seems better to avoid roundoff
 than to estimate what did not have to occur if common sense and
 few simple rules had been followed before the problem was put on
 the machine.

 Another standard algorithmic problem both in mathematics and in the use
 of computation to solve problems is the solution of simultaneous linear
 equations.  Unfortunately much of what is commonly taught is usually not
 relevant to the problem as it occurs in practice; nor is any completely
 statisfactory method of solution known at present.  Because the solution
 of simultaneous linear equations is so often a standard library package
 supplied by the computing center and because the corresponding
 description is so often misleading, it is necessary to discuss the
 limitations (and often the plain foolishness) of the method used by the
 package.  Thus it is necessary to examine carefully the obvious flaws and
 limitations, rather than pretending they do not exist.

update: (sorry, German only;) A big thanks to Sven C. Koehler for this summary

 Ich habe es nun in den groessten Teilen ueberflogen.  Die Ideen sind nicht
 wirklich neu: Umformen von Gleichungen, Vermeiden ungefaehr gleichgrosse
 Zahlen von einander abzuziehen, Approximation.  Beim Loesen von
 Gleichungssystemen schlägt er z.B. vor, ein Verfahren einzusetzen, das
 kein wiederholtes Dividieren benoetigt, dann wird's auch nicht ungenau.
 Trotzdem mag ich das Buch, weil es in mir den Eindruck weckt, dass es
 sehr fundiert ist.  Es ist voll von mathematischen Formeln, die ich alle
 nicht wirklich verstanden habe, aber ich werde in jedem Fall wieder darin
 nach Erklaerungen suchen, wenn ich mal wieder ein Numerik-Problem habe.

 Ich glaube für dich ist as Buch eher langweilig, das meiste kennst du
 bestimmt aus dem Studium. :-)

The bootdisk supports standard (dual)IDE controllers, and most SCSI-controllers with the drivers supplied in a seperate archive below. It does not need any other special hardware, it will run on 486 or higher, with at least 32MB (I think) ram or more. Unsupported hardware: MCA, EISA, i2o may not work. Some newer IDE/SCSI-raid systems may not work either.

Tested on: NT 3.51, NT 4, Windows 2000 (except datacenter?), Windows XP (all versions), Window Server 2003 (at least Enterprise).

DANGER WILL ROBINSON! If used on users that have EFS encrypted files, and the system is XP or later service packs on win2k, all encrypted files for that user will be UNREADABLE! and cannot be recovered unless you remember the old password again

link

I just now came across this link on slashdot. The only thing I can say is that like in the RIAA (sic) cases one really wonders about our politicians. And this is the weakest way of putting it .. oh boy! Lessing has said it correctly: *If we don’t fight for our freedom, we do not deserve it*. I am so sick of all these stupid trivial patents like double-click, hyperlinks, etc. .. does anybody care that obvious prior art exists?

The /. link

Some nice quotes :-)

 Ministers were being trusted to represent the view of the government that sent
 them... but it seems as if business interests have found that these
 individuals are a weak link that can easily be "bought off" and convinced to act
 on their own.

 The corporations won the war.

 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.

 Quote:

 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 homepage

Slides Dmitry Borodaenko presented about Samizdat ath the Euruko 2003

 Inside my head, I sometimes refer to Del.icio.us as the Google In Reverse.
 Google has amassed a solid mound of ranked and twined web sites. The
 standings shift about with caution, the behemoths are tough to dethrone.
 And if I ask for Ruby, the answers in place may hold through the end of
 the year.
 ...
 Del.icio.us is perfect! The activity bred by competitive linking would
 be enhanced by the sharing of richer media.
 ...
 Better client software is needed to make this happen.

The organisation will next week show off a Wi-Fi enabled bus at the Paris-hosted Public Transport Exhibition 2004. It will also launch a public trial of the technology, on the number 38 bus, which runs between North and South Paris. Buses on the route have already been equipped with Wi-Fi, RATP said. Travellers will be able to connect their (suitably equipped) PDAs and notebooks with the bus’ on-board access point. However, Internet connectivity is only provided at Wi-Fi speeds when the vehicle passes within range of a fixed hotspot - at a major terminus, for example. For the rest of the journey, connectivity is maintained through a GPRS link. link

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.

 >Because it is important for the customer to have an idea of how much
 >> everything will cost ...

 In 99% of the times customer neither needs nor wants "everything"! One
 of the big dangers of BRUF is that it imposes the wrong feeling that
 "everything" is important. This is a major distraction that inevitably
 leads to scope-creep and eventually project failures. When we have the
 first meeting with a new customer we ask the following 3 questions:
 1. What is your biggest pain?
 2. If we solve this and only this pain, will your life get better?
 3. Are you willing to pay X amount of Euros to us to solve this pain.

 If any of these questions is answered with "no" we just thank for the
 coffee and walk away. If all 3 questions are answered with yes, we move
 to the first planning game...

 Put it in another way: I do believe it is extremely dishonest and
 incorrect behavior to conduct 9 months BRUF only to reach the
 conclusion that the customer does not have enough resources to
 continue. It is dishonest because as I wrote in an earlier posting,
 _all_ good developers I know are able to estimate almost immediately
 the scale of any software project without conducting BRUF.

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

 "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.

 I assume this popped up on everyone else's RSS aggregator as well, but...
  From Darrell Norton's blog [1] and Artima developer forum [2]: the
  current issue of CIO magazine is all about agility:
  http://www.cio.com/archive/081504/index.html

 A quote from "Pirates of the Caribbean: The Curse of the Black Pearl":
 --You're pirates. Hang the code, and hang the rules. They're more like
 guidelines anyway.

link