Wired reported today that Hans Reiser was found guilty of murder of first degree. The end of ReiserFS? As least a story about how open source fame can go wrong...

A developer of MySQL (or should i say Sun) pointed me to an interesting article about a very special MySQL performance tuning idea for MyISAM tables with a lot of concurrent writes. Lately at a customer's site i saw a MySQL DB with 118,000 tables. The thrilling bit was that the configuration of the MySQL DB was only allowing for 800 MB of main memory and 256 open tables. And it still worked (a little slow admittedly). Congratulations to MySQL for giving the world such an indestructible database!

Die PHP Unconference in Hamburg ist jetzt in vollem Gange. Mein Highlight gestern war "Ask the core developer" mit Johannes Schlüter, in dem unerwarteterweise viel über die Zukunft von PHP und der Community gesprochen wurde. Mag daran liegen, dass im Publikum Leute wie Stefan Esser, Thies Andtzen gesessen haben. Interessante neue Erfahrung für mich ist, in so eine Diskussion als Vertreter von Zend einbezogen zu werden. Es erscheint mir seit einiger Zeit, als sei die Stimmung in der PHP Community nicht die Beste. Viele rennen den "echten Profis" aus der Java-Welt hinterher oder schielen neidisch auf die Aufbruchstimmung im Ruby on Rails Lager. Wo ist die Begeisterung hin? Wieso kopieren wir Dinge statt wie früher cooler zu sein als alle anderen und Dinge besser zu machen? Eine spannende Diskussion, die wir heute im Rahmen von "PHP is not Java" ein wenig vertiefen wollen. More to come...

Es ist schon witzig wie die Zeit vergeht, wenn man Spaß hat. Was dabei interessant ist: Man bleibt viel länger wach, wenn man mit 5 Leuten im Skype ist. Vielleicht hat das was mit kurzer Aufmerksamkeitsspanne zu tun und damit, das man nur die Zeit von einer bis zur nächsten Message allein überbrücken muss. Jedenfalls überstehe ich problemlos ganze Nächte vorm Rechner, wenn andere da sind, mit denen ich mein Leid teilen kann. Und schon zwitschern draussen die Vögel wieder und es wird hell und ich denke: Soo lange war das doch gar nicht. Morgen schaue ich mir mal das Chatprotokoll an. Wird bestimmt lustig. Bis dahin ein kleines Zitat von Mimi, dem Marienkäfer: "Der Tag hat wieder Spaß gemacht und Gaylord sagt jetzt Gute Nacht!"

Passiert mir nicht oft, aber beim Recherchieren bin ich heute auf einen sogar recht bekannten Namensvetter von mir gekommen: Gaylord Nelson. Er wird auf der Projekt-Homepage eines Projekt namens XMMS offenbar etwas aus dem Zusammenhang zitiert (wobei die Zitate kaum authentisch sein dürften). Diese witzige Homepage gehört zu einem Mediaplayer, der  eine wichtige Grundlage für ffmpeg und damit für die meisten aktuellen Videoportale wie MyVideo, Sevenload, Clipfish etc. darstellt. Keine Ahnung, was diesen Amerikainschen Politiker der Demokratischen Partei mit dem Ungarischen Open Source Projekt in Verbindung bringt. Aber eins steht fest: Wir Gaylords sind offensichtlich zu Höherem berufen...

es gibt guten und schlechen. Allen gemeinsam ist, nach dam was ich kürzlich gelesen habe, dass irgendwelche Verbindungen im Gehirn blockiert werden. Das sorgt dann dafür, dass man noch mehr Zeit verschwendet, indem man blöde Dinge tut wie:

- eMails an falsche Verteiler zu schicken

- den Kinden Sachen falschrum anzuziehen

- sich trotz TomTom mit dem Auto zu verfahren

Da hilft nur: Meditieren, Entspannen, Runterkommen

Soviel zur Theorie. Aber was ist eigentlich mit den Leuten, die nur unter Stress funktionieren? Sind deren Hirnverbindungen im Normalzustand zu weit offen, so dass sie nur unter Stress "normal" sind? Dann wäre Stress ja vielleicht eine Therapieform? Bei Gelegenheit muß ich darüber mal genauer nachdenken. Jetzt aber nicht. Ist gerade stressig...

... and the winner is: Christiane Rösinger for:

"Ist das noch Bohéme oder schon die Unterschicht?"

In typical PHP projects, people are afraid of spending more hours in development that actually planned. As a main reason for this exceeding the estimated (thus paid) budget of hours, usually "technical problems" are given. But the experience (and some empirical studies) show that this is not really true: Especially for bigger projects (>100 person days) a much bigger danger lies in understanding the requirements right. Of course we work iteratively and of course we re-estimate each feature right before we start implementig it. But our customers have internal processes and thus they need to scope the project  very detailed upfront. So we need to tell them what we will deliver and what cost are involved with it. Actually, what we need is an adapted form of planning game as described in agile methods: We need to gather all functional requirements from an unstructured document and we need to roughly estimate on a basis of these requirements in order to define features and scope the project right.

There are a lot of books about classical requirements management for the usual waterfall project model. In the PHP world, things are more dynamic and change more often. We have solved this problem for a quite big project currently. Our PHP-minded approach looks like this:

1. We get a functional requirements document from the customer. This is his "wishlist"

2. We derive the actual requirements from this document. This is important because the customer tends to distribute similar requirements via the whole specification and thus, the structure of his document is usually not suitable for our project organisation.

We list the requirements in an excel sheet that has the following columns:

- Chapter in the original document of the customer
- Brief description of the feature
- Rough first estimation of the development effort (we use person days, but you could also use "feature points")
- Comment field for assumptions regarding the estimation
- a feature number and feature name

While we isolate requirements, we immediately associate them with features. If no feature had been defined before that matches the new requirement, we add a new one. In excel that is easy: just type a new feature name, the completion feature of excel helps to aviod mis-spelling when referring to a previously defined feature. Feature numbers we assign in a separate list and also write to our requirements list.

We put every requirement we find into the list. Even if it is double (i.e. mentioned in a different chapter). This way, we build a relation between chapters in the requirements document and our feature numbers.

3. Now we sort the list by feature. After that we see all the requirements that were redundant. We keep them in the list, but reduce the estimated hours if the redundant ones to 0. This way we keep the relation but avoid doubling the estimated cost.

4. My new favorite feature in Excel: Pivot Tables. I am not a microsoft fan, but this is really cool: Excel can aggregate all estimated hours per feature in such a table. The result is a list if disctinct features with the associated estimated days.

5. This table we can then discuss with the customer. We know where the effort comes from and we know where in the specification document the requirements for this were hidden. The customer might then say: "Let us talk about this feature, i don't want to spend so much time on it". We can then look into the requirements list for this feature and check what the biggest points are and if we can reduce effort here.

6. During this discussion, we add another 2 Columns to our excel sheet: New Estimation and New Comment. After (or better: during) the discussion with the customer, we fill in the newly estimated person days and the comment, what was changed towards the old estimation in these columns. Then we define another Column in the Pivot Table that aggregates this new estimations per Feature for us.

7. Finally we write down the features along with the references to the specification document, the new estimated time and the new comments (if any) in a technical specification document, add some design and architecture information and we have our offer.

We tried quite a lot of approaches in projects of different sizes but this seemed to be the best way so far for us to deal with big specification documents the PHP way. Maybe someday if i have a lot of time, i will write a database driven PHP app replacing the Excel sheet. But so far, it works great this way