So, you have this great idea for an application/product/service that will live on the Internet…
Or, you have an existing legacy product that you want to bring into the 21st century…
Or, you have an application that needs to be refreshed, and you’ve decided to redesign it and take advantage of the opportunity to re-architect the technology behind it…
These are all real-world examples of work that Mad*Pow has done for clients, and common issues that we have helped teams make decisions around. The process usually starts with a round-table discussion. Product managers along with senior developers and architects gather to put together their recommendations for the technology architecture. These meetings are interesting, at the very best, and heated, at the very least.
Mad*Pow has a method to productive architectural-decision-making. Here are some of our secrets:
Start with a blank canvas
First, we must start with a blank canvas; removing all previous biases and toolsets, and evaluating the project based on the needs of the product. In architectural decision-making, there are two types of engineers:
Brings their own tools: Some engineers like the toolset that they have been working with and prefer using them. To them, the hammer in their hand will turn everything into a nail.
Shiny new object: Some engineers like to learn the latest new framework or toolset and have assembled some or all the different toolsets they want to learn.
The only thing that these two types of engineers have in common is that both will have to leave their preferences at the door. This is an opportunity to re-architect some or all of the front-end. Remember the mistakes of the past and try not to repeat them. Also, take advantage of this moment to build the best front-end architecture that will meet the needs of the product. That is the only goal, and it is important that it should be mentioned at the beginning of the process and reiterated throughout.
Let’s make it interesting…
There is no reason we can’t make the process fun:
“And the winner is…” Ask all participants to write down what they think the technology stack should be and place them in an envelope. Collect them at the beginning of the meeting (it would be prudent to not broadcast your intentions so that members don’t lean towards a technology decision that would favor them and what they have written in the envelope). Once the tech stack has been selected, open the envelopes and see who got the closest.
“Erase it all” Ask everyone to write their technology stack suggestions on the whiteboard. After it is all done, call for a coffee break. Once everyone is on a break, take pictures of the whiteboard. After the break, once everyone has taken their seat, erase all suggestions written on the whiteboard. The message here is “We are starting with a blank slate. Remove all the pre-conceived notions.”
There’s more than meets the eye
The expansion of the front end and the role it plays has made it more nuanced and therefore deciding how it should be assembled calls for the same nuanced mentality. This is the first in a series of articles around assembling a front-end architecture and examining each considered individually.