Tag Archives: Development

Conference in my living room

a kids drawing easel thing by IKEAToday (uh make that yesterday since we’re now past midnight here…) around lunch I drove my two kids over to my parents in law and got back to my house to host four friends (associated with a company that shall remain nameless in this blog – at least for now) coming over to discuss some work stuff.

It was great fun sitting in my living room chatting for a few hours, having a cup of coffee and instead of using a fancy company white board I brought my kids’ drawing easel (oh we love IKEA). The picture is the actual model we used, called “MÅLA”.

And we did indeed manage to get some good decisions done and some proper architectural stuff set. Admittedly, my kids’ drawing pens were a bit thin and not as thick and “powerful” as the ordinary office white board pends tend to be.

The Mythical Man-Month

The Mythical Man-MonthFrederick Brooks wrote this classical book already back in 1975 and added a few extra chapters for the twenty years anniversary 1995…

Large portions of it feels of the age and there’s a lot of talk about Fortran, System/360 and PL-1 as if we should know about them (which made me fast forward over some chapters). But there are gems as well, and the most significant things people seem to remember Brooks’ book for are still pretty valid and fine.

Adding more people to a project leads to the need for more communication and thus it may slow down development rather than speed it up. Also known as Brooks’s law.

Given the complexity of software and software development, there’s no single method or concept that will lead to an improvement by an order of magnitude – within a decade. There’s No Silver Bullet. (This section was not in the original edition of the book.)

The risks involved when rewriting something and wants to fix everything that was wrong in the previous version so you over-work and over-design the successor. The so called Second system effect.

A lot of the book is spent on thoughts and theories around how to manage really really large software projects, like when you involve thousands of persons. Is it even possible to make such huge projects successful and if so, what does it take? The extra chapters do indeed add value since they offered Brooks a chance to re-evaluate his earlier claims and ideas and to check what seemed to be truths and what mistakes he did in the original edition.

A very interesting read that I’m glad I finally got time to get through!