Code the thinking, not the artifact

Questions, thoughts and tasks that a software architect has to keep in mind when starting a new project.

Web sites and applications have increasingly complex life cycles. The introduction of new features or revamps of the user interface are on the sprint agenda. To meet this need, software architecture must be dynamic and can no longer be extrapolated from a designer’s static artifact. It must become part of the design flow.

Some rules

0. Don’t set up the project thinking about the product release and MVP. Aim to simplify the implementation of new features and make them easier to maintain. Whenever possible, play ahead.

1. Know the weaknesses of your team and secure the project immediately. A new project is the best opportunity to try out practices and technologies, especially if you aim to solve the flow problems of the previous project. Good confidence is key for initial enthusiasm.

2. The code must be resilient, especially at this stage. Resilience depends on the quality of code and team practises (review, pull request, pair), but also on how the project is interpreted. The more the code structure is similar to the project thinking, the easier and faster it evolves.

3. Know the contents that will be inserted, where they are saved and the database structure. When views are able to reflect data properties and relationships, it is likely that the introduction of a new feature will not require a refactor.

4. Know the dependencies of the project. Should it integrate with existing systems? Which components already exist? What technology are they based on? Or on the contrary: which projects will depend on this? How will it be distributed and used?

5. Know the dependencies of the dependencies. Legal conditions and privacy policies, branding or marketing needs, market researches, usability tests (...) are all factors that help to better understand the project.

6. Know your designers. How they approach the project? What are the foundations on which they build? What relationships they create between the data? Try to implement the same reasoning in the construction of the view. Ask them to explain what proposals have been submitted and why they are rejected in order to exclude solutions and reduce scenarios.

7. Know your product owner and your customer. What’s after the MVP? What are the goals of the product? What are the stakeholders’ goals? Which part of the project do you want/need to plan more carefully so that a technology becomes added value for the customer and their business? Try to be proactive and to identify and discuss these possibilities as soon as possible.

8. Know other teams and people you need to interface with for dependencies or shared tasks. What is their technology stack? What are the strengths of this team? Who is the most suitable person for a given topic? Establishing a direct and professional relationship with these people concretizes (and reduces) the abstract distance between teams, allowing you to create more interoperable products.

Connect the dots

If the foundations of the code will respect all these interdependencies and relationships, if instead of developing a project you can develop the idea that thought it up and built it, then your work will became part of the project and not just an artifact, reducing frictions, timing, bad moods and margins of error.