Blog Posts about Software Development & Management

Having witnessed the PC revolution, Traenk pauses to reflect on the GUI world...

Proposed approaches to building products, software or otherwise, will come and go. One thing that seems to be constant through all this change is that the voice of the latest and greatest is convinced that they have solved the problem once and for all.

A few months back, I wrote about the need to have faith in the process that was being used to build a product. This was recently reproduced in the Cutter E-mail Advisor, and generated a question about the diagnostic I referred to, and a question about how to build that faith that I alluded to in the article. Here are a few thoughts on the topic.

I’m sure it happens in any industry, yet it never ceases to amaze me. Once someone gets a bit of prominence, once they have discovered the secret handshake, many people will stop questioning what comes out of their mouth (or fingertips if online), and take their missives as gospel. Crazy, but true, and costly in the technology field.

There is no shortage of indicators that we are in for in for a rough stretch ahead. While there are some that are still debating whether to call what we are going through a recession or a depression, it is clear to everyone that this is no time for frivolous spending. I would argue that we should always be aware of where we spend our money, and always spend with an understanding of the return we expect.

 In many shops, big or small, software or otherwise, agile or traditional (as if that were a true dichotomy) we see fabulous energy in projects where people are committed to delivery. Unfortunately, in too many shops, we also see the down side of fatigue. Sometimes after the project completed (if you’re lucky), but often while the project is trying to progress to completion, the many symptoms of fatigue can have tremendous costs.

Not sure how we've associated improved and secure coding practice with legislation?

In many sectors, 2008 has been a tough year. There are very few people that expect that 2009 will be much better, and most indications are that the foreseeable future will be at least as challenging, if not worse. How people and organizations deal with these difficult times is a strong indicator of how well off they will be as the situation improves - or whether they are still around at all.

Traenk ruminates over what's likely to hit security professionals in the coming year.

Pair programming is one of the agile practices that has most polarized people on both sides of the fence: sitting two people down at the same screen and keyboard to develop a piece of code. Having experienced this practice over 25 years ago and finding it to be extremely productive, I'm in favor of it being applied more than it is now. In fact, I would advocate pairing up (or more) for almost any practice we apply in the process of building our products.

Almost everyone is familiar with Dr. Bruce Tuckman's team model of Forming, Storming, Norming and Performing. This describes a sequence of stages that teams will naturally go through, whether this is consciously managed or not. Some teams never quite make it past Storming, and some seem to get through it relatively unscathed, only to lapse back later. As with many models, teams often exhibit traits of more than one of these stages at the same time, so its linear presentation may be a bit misleading. That stated, though, the model is a succinct and extremely applicable way of describing overall team growth. If we tie this model to a couple of others, though, we get a few more very interesting insights.

Often, out of the sea of different opinions of how things should be done, there rises a few techniques that make it to the level of becoming a standard way of doing things. They can be codified in a Body of Knowledge, if such a thing exists for that discipline, or become generally accepted as a 'best practice', though we all know that these things are quite rare. Even when they are raised to that level, there is danger that they can become overused: while every technique has it's niche, no technique should be used too broadly. Such is the case with Work Breakdown Structures and Gantt charts.