Words on software and web development


Tactical Software Development

Much of the discussion about software development focuses on what I call strategic issues. It’s a bit of a stretch to make the division between strategy and tactics when most of the so-called “strategies” are really tactical improvements. For example, Scrum emphasizes the daily standup meeting, limits the length and topical coverage, and divides participants’ roles according to whether they are involved or committed. I still call this a strategic process because it doesn’t involve details of how code is written.

I am a strong advocate of lightweight but pervasive peer review via Technical Walk-Through (TWT for short, pronounced “twit” – my friends in the UK can stop snickering). By my own definition this is a strategic process.

An example of a tactical change is defining commenting guidelines. While some would claim this is best left to the local organization to decide, it is all too often taken for granted. “Good” programmers write comments, but what should comments do? How informative should they be? Is it possible to write too many comments? This is an important topic.

Another example of the tactical approach is implementing coding guidelines. Most organizations, once they reach a certain size, will usually decide on some soft of relationship with coding standards and guidelines. Some may be rigid, even requiring the use of formatting tools to enforce standards, whereas others may adopt simpler guidelines.