Rants and comments on lifestyle, virtuality, software engineering and other worthy issues
Ha ha ha. I am laughing my ass off.
I just started reading chapter 27 of the second edition of Peopleware, where DeMarco and Lister poke (serious) fun at “those damn posters” that make your skin crawl by insulting your intelligence. Guess what example they use. Yes, exactly. The very same one that I ranted on ages ago. They even quote the whole thing as I did.
Funny? Sad? Pathetic?
Anyway. I’m off for the weekend to visit the lovely historically interesting San Simón island.
I have started another blog. Yeah I know!
I named it Laetril and it’s in Spanish. My goal is to discuss a variety of topics on the way we knowledge workers carry out our jobs, and I decided to start it after a few (Spanish speaking) friends and colleagues asked me about related issues that I have been mentioning here and in some informal chats.
I am aware that by writing in Spanish I am making it hard for some of you out there; however, writing in English would make it as hard for some others. And since NEH is already in English, I thought that a Spanish-language forum would make sense.
So here I am. Have a look at Laetril!
Today I skim-read Peopleware. I had read it already, maybe 10 years ago, but I needed to find some details so I grabbed it from the shelf for a minute and ended up re-reading most of it again. I am still impressed at how good this book is. It’s just a little pearl, so current and so insightful, especially the section on work spaces.
I’m so used to the mediocrity that surrounds us, and so ashamed to admit it, that dropping by Consultoría artesana en la red, Julen Iturbe’s blog on IT consulting services, is like climbing up a ladder from a revolting, glum and humid belowground cellar and coming into a crisp and sunny winter day.
What’s even more surprising is that Julen and I are so geographically close to each other!
This is a poster that I found hanging from a wall a few months ago.
Teamwork
Just in case you can’t read what it says:
TeamWork – The Fuel That Allows Common People to Attain Uncommon Results
What do you think? Do you think that common people can attain uncommon results by working as a team? Let us agree on some definitions first.
By common people I understand people with average skills and capabilities with regard to the area of expertise we are talking about. If we are talking software development, then we mean average software developers. What is an average software developer? Well, take a random 10% of the software developers in the world and you’ve got it. Perhaps not scientifically valid, but enough for our poster discussion.
By uncommon results I understand results that surpass, in volume and/or quality, the results that one would expect from the same people not working as a team.
By team I understand an organised group of people that approach a common set of activities with shared goals.
I hope you agree with all these definitions. Now, do you agree with the poster?
Joel Spolsky has posted his best article ever. Not only it says important things. It is also beautiful.
Some time ago I read the book by Jack Greenfield and Keith Short on software factories, and I liked the overall idea. I even got involved with a workshop at OOPSLA on this topic, kindly invited by Greenfield himself.
Since then, I have been reading papers, opinions and news related in various degrees to the concept of “software factories” as described by Greenfield and Short. A few days ago I attended an event where different Spanish government and corporate parties presented their ideas and objectives about software factories, and I was surprised to hear that everybody is into software factories now. Every single company talking at the event told tales about how they have created a software factory with 300 or 500 engineers in some low-tech, rural area of Spain. It was unclear why everybody used the term “software factory” to refer to a large building chock full with “engineers” developing software; we have always had that kind of place. It seems that development shops become now “software factories”, developers become “engineers”, and software development is not software development anymore but software manufacturing. So chic.
Some years ago I used to work for a small software development company. This company was composed of 6 developers plus some additional staff. One of the developers was also some sort of project lead for the others. At any point in time, the company was handling between 5 and 8 projects, which meant that most projects were allocated to a single developer more or less full-time, plus a small timeslice of the project lead’s brain.
Is this an optimal strategy?
Most projects were small enough not to need more than 1 (or perhaps 1.5) developers allocated to them, which was good because the absence of real teams made coordination issues and overheads practically inexistent. However, it was also bad, because a single person was usually carrying the load of a whole project, and nobody else in the company knew enough on that project to be able to work in it if needed. This is particularly dangerous if we think that a developer falling ill or having an accident meant that his/her associated project was completely halted until further notice.
I didn’t like this way of doing things, and neither did the project lead. But we could not find an alternative organisation strategy that was efficient enough. Any ideas?
Nothing Ever Happens 2 