Skip to content

Instantly share code, notes, and snippets.

@yellowbrickc
Created February 24, 2020 10:50
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save yellowbrickc/695ae08fff5713a2724b56001739e1dd to your computer and use it in GitHub Desktop.
Save yellowbrickc/695ae08fff5713a2724b56001739e1dd to your computer and use it in GitHub Desktop.
Architecture: The Stuff That's Hard to Change - a review

Why this gist? As answer to https://twitter.com/dcarral/status/1231730478002135040

Disclaimer: my experience is based on smaller dev teams, up to 25 people. I never worked with a few hundred devs, I cannot say how my way would work out in such a setup.

I agree and like very much the explanations and tipps which Dylan gave. But:

  • I would never go for sepparated teams for backend and frontend.
  • I would not consider an architect OUTSIDE of a team. We agree that architects must code and I think, there aren't any reasons that they are not part of the team, as devs with a special role. I have this role for years now and I develop features like everybody else in team but also have the responsibility to plan and design and CHALLENGE the architecture. The time spent for these tasks is time invested in product development, in features. Also why not working in a team? If I didn't had time for tasks, I discussed it with my team and they didn't relied on my presence. If I started tasks but didn't had time to finished them, my team took over. Anyway I reserved always time to make code reviews and this way not only staying in touch but also having the chance to coach and enable the team to understand and follow the architecture - IMHO the most important job for an architect.
  • my last observation is really a minor one: I'm convinced that monitoring and observability is an essential feature of every product. This means, it should not be considered a side-track, it must be enabled and developed on purpose by the team. Additionally, When building application or business monitoring the team can understand much better how good or bad the application we built works.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment