Story

Software development is full of uncertainties. Most teams I've been part of generally start development with little-known facts and a lot of unknown ones - both on the business and on the technical side, from what we should exactly deliver to how we should do it.

The summary of that is: "We can't do X yet, we need to talk about it before"

My experience is exactly the opposite - ie that generally we need to do it to be able to talk about it.

This is in a way another side to the Delaying decisions post I made a long while ago.

Working with uncertainty

The reason talking may not solve the problem is linked to two unsaid assumptions:

• That talking can indeed clarify the problem - either because someone has some information that the rest of the group does not or because talking will make better solution/clarity emerge from the existing amount of knowledge
• That "going in" without this crucial step will be costly or cause irreparable damage to the team/project/company

Those are generally untrue. Of course, if a stakeholder has a lot of information that has not been shared, it needs to be, but in all but the most dysfunctional teams, the information is shared - at least to a reasonable extent. That includes typically the root user problem.

Once the knowledge in the group is mostly equivalent, talking about it (solutions and way of working) has a sort of diminishing return - there is only so much you can do in the abstract.

Trying things, even with high uncertainty is generally not that costly - you can draw some mockups to see how a feature could work, or even put some code to evaluate a solution's actual complexity - without incurring heavy costs or unchangeable decisions.

The learning and the end result

Even if the code/mockups/whatever artifact produced had to go directly to the trash (sometimes it has to), it generally produces much more knowledge than the starting discussion - and probably much faster.

That is often a good time for that discussion to happen - as it can now start on an actual work in progress instead on an abstract idea.

I've seen a lot of heated debates dying down directly as the solution become obvious (or obviously bad!) to everyone when facing some concrete result.

Software development is not physics - but being confronted to the hard reality generally makes a lot of theoretical options die, making decisions much easier.

Let's reality solve the debate

I've seen more and more than even as a manager (where I do have the decision power) I was better to let ideas/proposals be tried than to talk about them. This is true about code, but also about things like organization - it's often complicated to evaluate how a new process would work or help - so if the proposal is not too big/complex my default answer became "let's try it for two weeks - then we'll evaluate".

Things that work tend to become obvious in days - things that don't die by themselves well before the due date. In addition to being cheaper/faster, it tends to avoid a lot of ego-related issues - as suddenly it's no more about who's the most confident or loudest or fastest talking person.

I've won a lot of time and sanity (due to less debate) by cutting discussions short with "Sacha is going to make a first attempt at it, we'll discuss once she has a first working prototype".

Opinions? Let me know on LinkedIn!