Where to start?

The Developer: “Let’s start coding. We don’t have time for solution design.”

The Designer: “No, we should design first. It’s not a waste of time. It will reduce rework.”

The Analyst: “Guys, please! How to start designing, if we don’t know what the problem to be solved is?”

The Tool-lover: “But how to diagnose the problem without a tool? Let’s choose the tool first.”

The Architect: “Yes, but to choose a tool, we first need to make sense of the context and only when we know where we are, we can have criteria for choosing the right tool.”

The Tool-lover: “Doesn’t that mean we need a sense-making tool? Again, as I told you, we need a tool first.”

The Analyst: “No, this just means that we have to first analyse the context of the context. Let’s focus on that.”

The Developer: “20 lines of code ready while you are discussing.”

The Designer: “That’s a waste of time. But you, developers, don’t have a sense of time anyway.”

The Architect: “Time is an interesting thing. Good you mentioned it.”

The Analyst: “Is ‘time’ the problem?”

The Tool-lover: “We probably need a stopwatch.”

The Architect: “What we rather need is to stop and watch.”

… and so on.

3 thoughts on “Where to start?

  1. From my experiences organize an adequate faciltation/elicitation meeting to get requirements.

    In such these meeting each participant use his favorite technique to allow other to visualize and envision a shared understanding ( the requirement of the problem, architecture, security, compliance, business process, etc ). A second will be to agree on an prioritizing points to be done,

    in fact the simple way of success is show me don’t byzantine me : the problem, the context, the drivers, the values, etc

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.