October 2012 – In Search Of

A Fast Start

Posted on October 30, 2012Leave a comment

Sometimes, you have to get something started. At work, at home, where ever. You are starting something, because there is nothing. If there was something, you would just use it, do it, enjoy it, etc. Sometimes you can start by picking up where others have left off. Other times, you can start by putting together pieces that are unassembled. Once in a while, you have to start completely from scratch.

Starting from scratch is overwhelming. It can be overwhelming because you don’t know where to start. It can be overwhelming because you don’t know how to finish. It can be overwhelming because of all the things you don’t know yet. Starting is overwhelming because of the Unknown Unknowns. Continue Reading

Problem Solving Revisited

Posted on October 23, 2012Leave a comment

Why is it that you always find the cause of a problem in the last place you look? The correct answer, I think, is because when you find it, you stop looking. This post is a response to a conversation that I had with a manager I work with. We were talking about why people (software developers) take too long to correct software defects. My response was that often it is that they are lacking a problem solving framework that keeps them focused.

In my experience, there are two key behaviors that act to slow down problem solving:

1) Getting Stuck – not knowing what to do next or how to do it. This happens when I don’t know enough about the technical domain or the business domain of the product that I am working on.

2) Rabbit Holing – becoming focused on things that cannot lead to a solution of the problem at hand. This happens when I either don’t know that there are other possible causes for a problem, or I am unable to effectively evaluate the probability of a potential cause, or understand the cost of proving that something is the cause of the problem. Continue Reading

Progressive Requirements Elaboration

Posted on October 16, 2012Leave a comment

In my former post about progressive elaboration, I promised some “examples” from different domains of software development. This is the first of these. As I said before, progressive elaboration is about acknowledging that we can’t know everything we need to get to done before we start.

One of the difficulties of requirements elicitation is to maintain a consistent level of detail, both in documentation and in our conversation with practitioners, subject matter experts, and individual contributors. Another typical difficulty is understanding whether requirements are sufficient to begin some subsequent activity like design or coding.

While some methodologies have made recommendations, most merely call out the need. This leaves it up to the requirements analyst to build their own practice. In fact, most analysts do not subscribe to any specific methodology that they practice. I have often used these interview questions for analysts that I expect to elicit and organize requirements for software applications.Continue Reading

Performance vs Effectiveness & Productivity vs Efficiency

Posted on October 8, 20124 Comments

Everybody wants these things. They are all great. The problem is that we don’t know what they mean or how they relate to each other. We act as if these terms are somewhat synonymous, but they are not. Continue Reading

Hiring Talent

Posted on October 1, 2012Leave a comment

Hiring is a tricky business. We screen for experience. We screen for skill. How do you screen for talent? We should recognize that talent and skill are not the same thing. Skill is the ability to apply technique correctly. Talent goes beyond that. Talent includes the ability to know which technique will produce the right result. Talent is the ability to know when none of the techniques I know are a sure winner. Talent is the ability to quickly learn and assimilate new technique.

Talent != skill and experience – five years of c# programming experience does not equal talent.Continue Reading