I have heard and participated in a lot of conversations recently about tracking the time actually taken to complete a card. This is usually imposed to the team by management. I have never seen a team interested in how much time they actually spent on a work item. What are the reasons to track actuals ?

The first reason is to track how people spend their time. The idea behind it is usually that you cannot trust people to work hard. And that may be true in some contexts. However, the same people who distrust people’s work ethics entrust them with gathering the data. And so they essentially get the ideal values randomly adjusted so that they look real. While this is a useful practice at a personal level (see the pomodoro technique for instance), at a team level it really comes from the ‘look busy’ frame of mind. Throughput should be the thing management cares about.

The second reason is to try to get better at estimating. So managers want to try actuals and compare them to estimates. And then if the actuals do not match the estimates put pressure on the team to get better estimates. So for those of you who believe in that, here is what happens. Developers will start by padding their estimate so that they are pretty sure the actuals won’t exceed the estimate. Second, remember you hired them because they are smart, so they will never finish early to avoid the suspicion of padding. So you will get perfect detailed estimates and still the project will be late. And if, being clever yourself, you cut the estimates and people do not have time to finish within the estimate, then they will cut corners, drop quality and finish within the estimates anyway. And the project will be late because of those bugs that need to be fixed. By the way did you know that the best estimation is usually at a coarse grain level because then errors tend to offset each other ?

The third less harmful reason for tracking actuals is to improve the time forecast. This is essentially a statistical use by we try to measure the relationship between ideal days (or points, or size) and actual days. Even with this innocuous goal it is a waste of time. First the information is already available in the burn up (or down) chart. Second it tends to be wrong because early in a project there is not enough data to make it statistically relevant and later in a project chances are circumstances have changed (personnel, techniques, technology may have changed, technical debt may becoming a burden etc).

So why waste time and moral on actuals ? Even better, once you abandon actuals, precise estimates become irrelevant and you can get away with relative sizes. And relative sizes are very quick and easy to get consensus on and you therefore save time that too. So please abandon the collection of actual times !

I was troubled a few days ago when I heard a development manager talking about strategic initiatives and “tactical” solutions. I felt very strongly that the implied meaning was low cost, low quality solutions.

I am very grateful to Tim over at thedwick for writing that we should essentially reconsider that implied meaning. I would go even further, every single solution implemented by a development team is tactical in nature. Tactical does not so much refer to scope or quality as it does to the amount of control one has on the outcome and the time scale.

Strategic is when you have some level of influence on the goals and outcome but no real control. Tactical is that you may have some influence on the goals and full control on the outcome through your actions (your actions therefore have to adapt to local conditions and oppositions and overcome them). A strategy usually results in plenty of tactical decisions and actions that do not need to be fully defined in the plan.

The second aspect of the difference between strategic and tactical is the time scale. Strategic plans are liable to change as the environment changes until the strategic goals are achieved. The strategy will also change based on the tactical situations reported. Some goals may be modified or even abandoned if it appears they have become too expensive to achieve. On the tactical side, the goal is usually firmly defined and achievable in a relatively short time frame (a few hours to a few days) which leaves little room for changes.

One corollary of these two aspects is that when a tactical goal is achieved there is no reason to come back to it to achieve it again but better. To use a military analogy, let us imagine that the goal is to take a house in a city. The unit blows a couple of houses around to remove resistance and then storms the objective. Three weeks later, after the city officials complained, the unit is asked to rebuild the two houses and asked to put back the opponents that were in them and then take the same house again without destroying any other buildings in the city. That is exactly what is usually implied when a development manager talks about a tactical solution.

PS: It will be obvious that, in the analogy, the tactical goal has actually changed but let’s keep it simple.

Funny how things take a new light when you measure them. Take bugs for instance. When I started on measuring the time our current, reported, bugs have been opened I was expecting something like this:

For full disclosure, we use five level of priorities and we have a policy to fix all outstanding P1 and P2 bugs before shipping a release. What I found was this:

So effectively, we are not fixing anything that is below P2 in a reasonable amount of time. P5 are unlikely to be fixed anytime. Still we spend time managing that inventory of bugs (trying to avoid duplicate bugs, reviewing the priorities from time to time). In pure waste.

A second thing came to my mind looking at the mean time bugs stayed open. Given the amount of changes the code base undergoes in 6 months, what is the validity of a bug that was recorded at that time and was not considered important enough to be fixed ?

I will throw in a few ideas here that could lead to improvement in this area. One thing I would love is to be able to time expire defects.
Anything older than a coupe of releases should disappear automatically. Assign a high priority to defects reported from the production as they are truly visible and of value to the users who reported them. Reduce the number of priorities to three. Do not bother to record things that are evaluated below P3 in our current scale. Stop the line for anything
that we know we want to fix at the time of discovery. Each of these ideas will require a dedicated post (coming soon).

What are your thoughts on defect management ? Are these ideas outlandish ? How do you manage defects efficiently in your projects ?

It used to be that I did not care much for defensive programming outside of a system’s boundaries. It used to be that I did not really care or believed in strict source control (as in authorise only some people to touch a particular file). It used to be that I did not really believe in code reviews.

I now care for these and it is not a good thing. I care about these things because I do not trust the developers I work with to do the right thing, whether it is making the code better, improving their style, teaching me new things, or even write descent unit tests.

No that I am perfect in any ways but I used to be able to trust people in the team to correct me and help me get better. I used to be able to trust people on the team to catch my mistakes and fix them.

Work is a lot less enjoyable when that trust is gone.

In the recent past I noticed an interesting property of self adjusting systems. They self adjust !

So when work in progress started to accumulate and stories ‘completed’ piled on the doorsteps of QA, production of new features essentially stopped. Granted, part of it was due to the number of bugs found. But given the level of energy displayed by the team, that was not the whole reason. Here is how physical systems work: when a pipe is blocked water stops flowing and typically an equilibrium is reached where water becomes stagnant at a stable level. When no equilibrium is reached it is called a flood.

Since then our team’s management has had a good idea, tell people what they were expected to finish by the end of the year. Not surprisingly, setting a clear goal energised people a bit and production has started again. Work in progress has tripled and the pile in on QA’s doorstep has doubled. Nothing short of normal in a two iteration period.

On the positive side we have the opportunity to get the development team rolling into the new year with the warm feeling of mission accomplished. Sure we now all know what mission accomplished means. It means there is a whole more work to be done before the work is actually done and delivered. But having a sense of accomplishment, given the tough economy and looming work force reduction, will be invaluable.

On the negative, let’s brace for a good month of flooding.

Hopefully, if some day I actually manage a project (or worse manage developers) I will not forget this.

The amount of effort required to ensure developers are productive is bigger than the lost effort from slackers unless the team self polices. Also it is sometimes more productive to let a poor developer slack than to force him to do something that will eventually put him in the way of more efficient developers (see what Jay Fields had to say about that).

When there is no buy in from the team, if put under pressure, the first thing that will drop is quality because everybody knows that the clients will magically find money to pay for the bug fixes (or the support) that they did not have before for development.

It is good to prepare communication privately but it has to come out eventually. When communication is not forthcoming vertically it spreads horizontally with rumours and nags. Pretty soon instead of open and candid communication channels you have mistrust and scepticism.

It is good to read a management book once in a while just as it is good to stay technologically sound when you are a developer.

I obviously have no scientific base to support all that I have a bit of empirical evidence.

Here are excerpts of a document entitled “A little guide to a little etiquette” that provides guidelines on what to avoid doing in a work environment designed to be collaborative.

“Walk, don’t yell”, “Use your inside voice”. Basically the designers understood that open floors have no barriers against sound. They also recognise that the natural behaviour when you see someone that you need help from is to ask them directly from the distance, shouting to get their attention. And they found a solution: change your natural behaviour (and do some exercise at the same time !).

Regarding personal items, “One rule of thumb is that if you can see it from a public space or across the room (…) it needs to go”. Interesting as from my perspective anything that is on a desk can be seen from a public space on an open floor. Note that there is nothing here to suggest that this treatment is reserved to offensive material. Well, okay Dilbert may be offensive to some. Also there is a ban on plants and tape to make sure that in reality you cannot display anything personal in this neatly designed, beautiful place.

Other gems include:
“A reminder that all holiday lights should be viewed at (edited name of a city spot), not your desk. Also please remove any holiday items by January 2.”
“Walk Around. Please use the main walkways and go around the perimeter of workstations instead of cutting through work areas.”
“Please avoid ground-hogging – peeking over the workstations walls in order to talk to co-workers.”

Aside from the fact that it is the first time I get to read a written form of the furniture police manual what strikes me, and I guess it is good news for us software professionals, is that even for interior designs we have decided to replace hardware (walls and doors) by software (behaviour). It is really unfortunate that the designer failed to understand that one of the prime examples for open floors, trading floors, are places made specifically to enable people to yell and sign at each other from across the floor.

Let me re-read Peopleware.

César touched on hiring and promoting a while back. This came in conjunction with a number of other things that I have heard or lived in the recent past. It is all about the “right” person.

What is the “right” person ? Is she the person that satisfies all your criteria ? Will your criteria become obsolete as the environment evolves ? Or even worse you will discover that you had the wrong criteria ? What if the job you envisioned for the person has changed before they could actually start ? And if the “right” person does not want to work with you, will you settle for a “wrong” one ?

Hiring is all about compromise. The firm needs to make a compromise between diversity of opinions and common values. It needs both to be innovative. Compromise because a job always needs a mix of qualities a fine balance between expertise, character and ethics. There is also an important compromise between immediate results and long term contributions by the new hire. For instance, do you prefer to hire a cheap graduate that you will have to train but you will also get to grow or a seasoned veteran that has done the same thing ten times and will do it again for you ?

Earlier in my career I tended to interview people as a reflection of myself rather than as separate contributors. It turns out no one like me wanted to work with me. As I have aged I now realise that a job definition will always be stereotypical. The person hired to fill it will largely influence its actual shape. And the social group (team, department, company) is the result of the co-evolution of all the persons that compose it. Therefore the “right” person would be right in the situation as it was before you hired her. There is no telling what the situation will be after.

So as a conclusion, if you are deterministic, the person you hire is necessary the right person. For the rest of us there is no such thing as the “right: person. In other words nobody is perfect and right implies a contextual perfection that does not exist. More importantly, looking for the “right” person clouds your judgement as a recruiter. You have to be agile as a recruiter as well.

I recently got to feel the weight of social conditioning in the enterprise. I was asked to temporary (three weeks to be precise) fill in in a somewhat managerial position. I started with the idea that I have great confidence in my team mates and that therefore I would not need to do much in this interim period aside from fielding a few e-mails and showing up in a few meetings (I was even spared the administrative burden !).

I soon discovered however that I was trapped in the conventional thinking that is continuously hammered into us that people will not do what they should and that, as a result, if you are delegating the work, you should also verify it very thoroughly. Even knowing it is not good (see Peopleware for convincing arguments) I still felt compelled to do it. Worse, I had to refrain myself from over doing it and try to be more supportive than prescriptive !

The awful thing is that it is an attitude I don’t like as a subordinate, it is something that does not happen when the relationship is truly a peer to peer one. I came to realise the reason I was trapped in this attitude is that I felt singled out as the individual responsible for the outcome. It did not feel like a team responsibility but my responsibility.

That is what I would call the management trap. The illusion that things are at stake for you personally rather than the group. It is the social trap that we use everyday to ensure a control structure rather than a collaborative one.

Let me put first questions that aim at determining that you have a Computer Science background. It may also be that in some environments they are formally use and also test required skills. I am referring to questions about algorithm complexity and cost or about describing some specific algorithm (well known to new graduates) such as sort or data structure exploration. I like them because it is something I don’t get to reflect upon frequently. In practice, in the jobs I worked on they are seldom used formally.

Then there are the problem solving questions. Some of them are extracted from the vaunted google and microsoft interviews. You can find a few tihomir’s blog. From the ones listed only a handful are actually useful. Many are simply trick questions (like the angle between your watch’s hands at 3:15). Some have this particular quality that they test the creativity and the reasoning of the interviewee. This kind of question is all about the path your reason takes to solve the riddle.

I found two main categories. One is composed of the questions for which it is clear that the interviewer does not expect a precise answer. My personal favourite (which I was asked by Amazon) is “How many piano tuners are there in Seattle ?”. The other is composed of questions for which a definite answer exists but requires a creative jump to find. I found a few interesting ones in books (including the The Olduvai Imperative, a book I highly recommend even if it dates back to 1993). The main difference between the two is that the first one is resistant to publication. Whereas once the answer is published for the second category it becomes useless.

Their strong point is that they enable to evaluate a candidate’s problem solving abilities and the capacity to articulate the solution (as the authors of the Olduvai Imperative point out this is one of the primary activities of software developers). Specifically they require you to use creativity to solve the problem and they require you to organise the result as an articulated solution.

These are the questions we need more of in order to do a serious evaluation of software development candidates. Candidates who give appropriate answers to this kind of questions will be able to adapt to changes in technology and they will foster creativity and innovation in the software you are developing. Well I guess that some recruiters are not looking for that but that certainly is the part that I prefer in my job.