I find it hilarious that IDG.se out of all publications put together the “best developers in Sweden” and lists the top-75 ones (article in Swedish). It is funny because IDG is not exactly a place flooding over with technical (or any kind of in-depth) knowledge, so obviously they got this list by getting input from others and how on earth can they then compare person A against person B when they’ve been mentioned by different sources? Also, just lumping every kind of “developer” into the same pile and then trying to order them is also an interesting challenge. Clearly some of these devs are more project managers, theorists and similar, while others are hardcore kernel-hackers, C coders or Java dudes.
I don’t mean to bash the people present on this list, as I’m sure I would also liked being present if I had been that. I just think the list fits so well into IDG’s style of populistic journalism. The audience wants top-lists, let’s give them another one!
Or perhaps I’m just jealous that I’m not included! 😉
Today (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.
Frederick 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!