Architecture and Design Huddle

Software is never designed in isolation. In my career I have never seen someone come into a meeting on a green field project with a clear vision, draw what it needs to be done and everyone agrees and development start the next day. That might be the case if you have done that type of project many times but not for something new.

Instead in a healthy environment engineers and architects get together, start with a number of simple proposals, discuss pros and cons of each and the discussion is built up from there. Some might play the devil’s advocate, some question things and some ride their egos.

This decision making process is similar to the Blackboard design pattern where a common base, the “blackboard”, is iteratively updated by a group knowledge sources.

Below are some tips to guide a technical design discussion so it’s beneficial to everyone:

Start the discussion early - The sooner you start the discussion the better. You have more time to think the big problems through. You will have more time for experiments.

Keep attendees small - There is no magic number but a meeting with more than 8-10 people will not be constructive specially if everyone wants to talk. Choose the right people who have the knowledge and authority to make a decision.

Start with the customer - Everything starts from why and how it’s going to benefit the customer. Always start from “why” then go to how.

Requirements and constraints - Everyone should be on the same page about requirements and constraints of the system. Make these things clear. Being fast is not a requirement but a response time of under 2 second for 95 percentile of requests between 9am to 10pm is a sound requirement. Not every requirement comes from the customer. Think of testability, performance, modularity, etc. early in design.

Present your idea - Let your proposal loose, keep it casual, aiming to spark discussion, and get feedback. No need for a presentation because it’s ripe and has a high chance of rejection or change. Discuss each idea thoroughly. If an idea is rejected, document why. Do not jump to another idea too quickly unless you have documented and understood pros and cons. If an application is slow due to using a particular library and devs suggest to use another library make sure they have tested the first library enough and the decision is based on facts and reliable test cases otherwise switching to another library is just a waste of time.

Do simple things first - When solving a big problem start simple. Do not try to solve all the problems in the world at once. Implement the simplest thing first, take it to production and iterate. Create phases and do simple things in initial phases. Do not budge when PM tells you that we only have one shot at it!

Question everything - As the design meeting organiser or architect one of your tasks is to question everything. This might seem intuitive and many people shy away from asking questions or simply asking why.

If you take away one thing from this article it’s this. Try the role of the “questioning guy” in the next meeting and see how it unfolds solutions.

If you are stuck on a hard problem do not forget the power of Six Thinking Hats method. It has saved me few times.

Step back, watch and manage - Once the meeting started you don’t have to be the sole speaker and decision maker. Give space to all, encourage people to share their thoughts and feedback. Allow them to draw on the whiteboard specially create an environment that junior or shy engineers can have a say. Stop people who talk too much and want to be the sole speaker. Ensure the discussion progresses towards coming up with a decision aligned with the goal of the meeting. Good meeting facilitation takes practice and needs authority. Stop unnecessary discussions and off-topics. Do not allow bully, loudness, arrogance and anger to dominate the meeting. Leave egos out of the meeting.

Use tools effectively - Covid-19 taught (hopefully) many organisations how to work from home and use tools such as online whiteboards, documents, etc. better. A design might be clear in your brain but that is not going to be the case for everyone. Draw it for the benefit of all people and share it after the meeting. A drawing with a bunch of boxes and arrows goes a long way.

Address disagreements - If some people disagree with something, hear the reasons. Know the difference between a technical reason and arrogance or reasoning out of ego. Make sure the disagreement and reasons behind it is discussed. Do not let disagreements linger undiscussed.

Finish with notes - Collect the key decisions made and write up the summary, circulating it to the meeting attendees. If you used a whiteboard, take a photo. Assuming there was an agreement, these notes might be the start of a design document. You may also want to keep a Decision Registrar. Do not forget the action items.

Do not drag the discussion - It’s best to make a decision late enough when you know more about the problem. The more you delay the decision-making the batter. This is called the last responsible moment. But delaying the decision making does not apply to everything. Do not drag decision making otherwise you will not achieve anything and there will be a lot of open items in your agenda.

The last responsible moment is a point in time when you must make a decision otherwise there will be dire consequences or it would be irresponsible not to.

Iterate - Depending on the type and complexity of project/problem you are tackling there is a high chance that you cannot cover all the items in one meeting. You will need multiple discussion meetings across your SDLC. Ideally more before dev starts, then a few during dev when you get real feedback and hopefully less during more formal test cycles and production.

Follow up and execute - This is the hardest part! Sometime after the meeting follow up on the action items. Also any discussion for the sake of it is just waste of time. Go to production asap. Demonstration defeats discussion!