When I started out as a developer and designer, I know I was clever. When folks asked me to design and develop a software product, I would ask a few questions to confirm that I understood what was asked of me, listen to their answers, then set about making the product. Request, build, ship. Easy!

My mentor, who was definitely smarter than me, used to yell at me to Stop and Think.

When this first happened, I assumed he meant that I had to stop and think about the software I was going to design and create. But that made no sense to me. Why? Because even back then I knew to run a software development process, not to jump straight into coding. And that process would take care of this undefined stopping and thinking. I would have to think to write down what as asked (as Requirements), what was expected (Deliverables) and what I was going to implement to make that happen (Design). All of those required thinking. What was he on about?

Over drinks, he explained it to me.

The stop and think was not about the product asked for, he agreed that the development process would take care of that. The stop and think was to step back and look at the bigger picture, the context, the motivation, the larger workflow or process that this requested product would become a component of and who or what would be impacted by this project.

I had, naïvely, assumed that the client always knew and deeply understood these things, had done their homework and had come up with the request, requirements and deliverables based on their perfect understanding of the context. The reality is that they had felt a need, guessed a partial or bare solution and had asked for it, with no bigger picture or further thought.

That bigger picture, that further thought, that was on me, the designer and developer.

Stop and think was meant to make me ask questions outside the regular development process, questions like

• How will the deliverables be used, who will use them, and what are their needs?
• Why is this product needed at all?
• Is there a reason that the product needs to be done the requested way?
• What business problem, no, what real problem, are they trying to solve?
• And how important, in the flow of things, is this project?

The answers to these non-product questions are what he needed me to stop and think on. You see, if the answers supported the requested product and its deliverables, then we’re good. But more often than not, the answers to the bigger picture questions did not match what was asked of in the product — because that person asking for it had not Stopped and Thought either. By asking these questions, the need, context, purpose, scope and nature of the product would clarify, solidify and change.

For example, a simple data load project sounds straightforward, get the data, write it somewhere. Most folks would spin up a script to load and dump the data into a table just as it came in. Its fast, works, and how most folks do it. But if the developer of the loader knows who would read the result, and how they wanted it and why, the developer could design data cleansing and transformation routines, better naming conventions and remove extraneous columns that would load the data to better suit the needs of downstream, saving both teams time and money — for the same development cost.

What really comes out of stop and think are better product definitions, better ideas on how to design and implement them, and a better resulting product.

My points:

• Knowing the bigger picture helps design a product that fits that bigger picture instead of creating more tech or business debt for later on.
• Knowing the bigger picture will often change what the product does, saving rework later when it does become clear, and makes everybody happier.
• Knowing the bigger picture also helps to prioritize projects and project dependencies, and will help when planning and scheduling work.
• Inversely, not knowing the bigger picture, or assuming the client does, leads to worse software, confusion, miscommunications, and the litany of problems all IT teams face daily.
• The intellect and knowledge of the software designer is underrated. Maybe the software folks have a better way of getting to the same goal with different deliverables and a different product build.

Follow the author as @hiltmon on Twitter.