Be on time for meetings

We recently had a team meeting where we discussed how important it is to be on time for meetings. A comment was made that "It's disrespectful to be late for meetings".

As a prime offender, I kept my mouth shut, but certainly had a few pointed questions I really wanted to ask. It's great to SAY we should all be on time for every meeting, and we should respect everyone's opinion, but DOING that is a little more problematic.
In the past, I personally had an average of about 3 hours of meetings per day. These were recurring, scheduled meetings, that I typically sat in and listened to other people talk. Truly there was probably about 2 hours of meetings per week that I actually had conversations and constructive/useful information that was communicated.

I actually think the problem should be turned around and we should make sure that meetings are useful. To me, a 1 way dissemination of information is best served by an email message. Meetings should be reserved for face to face interactive discussions. If you routinely have to say "we don't have time to talk about that right now" then you probably don't need a meeting because you don't want a discussion, you simply want to dispense with information or instructions.

Grand theft childhood

I saw an interesting article about violence and video games and their impact on children. There is evidently a book called "Grand Theft Childhood" that examines this.

I might have to take a look.

Hammers and Screws again

I had an interesting situation back in January. I was called into a last minute minute meeting and asked to explain why I thought we needed JBoss and why websphere wasn't OK.

Frankly, I was stunned. I was told the meeting was to discuss what sort of hardware we needed and where it was going to be deployed.... Suddenly I'm asked to justify using JBoss instead of websphere to a bunch of fairly skeptical folks who where VERY interested in using websphere at all costs (for some reason).

Well, I stammered and stumbled since I wasn't really prepared to answer this and I could almost hear the folks on the other end of the call tapping their fingers on the table, waiting expectantly for my answer for them to instantly debunk.

I stopped for a full minute, my entire mind switching gears from "what sort of hardware/capacity might we need" to "why do you want to use JBoss instead of Websphere".

I then proposed the obvious thing (to me) "Well, Jboss is free".

Of course this was a ridiculous reason for using software. I was promptly schooled on how we would NEVER, EVER deploy FREE software, we absolutely MUST pay for it. After all, who would support it?

So I was a little bit shaken (not stirred) and had to think about it. To me, it is really great to be able to actually diagnose production problems by looking at the source code and figure out what went wrong. Most closed source companies don't really like you doing that (unless you pay them a WHOLE LOT of money).

Xn= kXn-1(1-Xn-1)

It's interesting how things just sometimes go "click". I was perusing the net reading about various topics on software development and business management and stumbled across an interesting paper discussing disaster response (I think it's actually referred to on the agile wikipedia entry) What Disaster Response Management Can Learn From Chaos Theory

This paper goes into some depth explaining how nonlinear functions can be used to analyze disaster response. I got increasingly interested as I realized that, in some ways, information technology has parallels to disaster response. More importantly, nonlinear math has a huge potential to help analyze and solve many information technology problems.

I did a little more research and stumbled upon this gem and began reading it:

Organizations and Chaos: Defining the Methods of Nonlinear Management
Book by H. Richard Priesmeyer; Quorum Books, 1992. 258 pgs.

This is written by the same person who did the disaster response paper and is a compelling read. The reason it's so interesting to me is that these problems have exact correlations to many problems I see with software development. For now, I'm going to finish this book and I'll follow up later with some 3/4 baked ideas.