7 Behaviours To Avoid In A Software Architecture Role
- Daniel Watts tl;dr: (1) Don’t ignore the engineering team. (2) Don’t ignore the domain. (3) Don’t prescribe or mandate architectures. (4) Don’t just seek architectural consistency. (5) Don’t forget about the current architectural state. (6) Don’t get too attached to the desired architecture. (7) Don’t let review processes stagnate.featured in #224
Moving BBC Online To The Cloud
- Matthew Clark tl;dr: Key principles behind the move include: (1) Don’t solve what’s been solved elsewhere. (2) Remove duplication, but don’t over-simplify. (3) Break the tech silos through culture & communication, and more.featured in #213
Systems Design For Advanced Beginners
- Robert Heaton tl;dr: Practical run-through of a typical architecture setup for a web and mobile application. Robert explains concepts like webhooks, databases, and more.featured in #196
Drawing Good Architecture Diagrams
tl;dr: "Start with a basic high level concept diagram which provides a summary. Then create separate diagrams that use different lenses to zoom into the various parts of your system."featured in #195
How Does Spam Protection Work On Stack Exchange?
tl;dr: A layered approach using HTTP errors, IP blocked and spam-flags, used in tandem with a custom bot called "SmokeDetector, which "looks for spam and feeds it into chatrooms where waiting users can spam-flag it."featured in #190
Architecture Jams: A Collaborative Way Of Designing Software
- Gergely Orosz tl;dr: Gergely provides a useful framework for how to conduct jams, starting with (1) be mindful of who you invite (2) start with the goal (3) lay out constraints and principles.featured in #186
Rebuilding Our Tech Stack For A New Facebook.com
tl;dr: The FB team built a client driven app anchoring the rebuild with 2 mantras. (1) As little as possible, as early as possible, (2) engineering experience in service of user experience.featured in #183
The Elephant In The Architecture
- Martin Fowler Ian Cartwright tl;dr: Asked to perform assessments on architecture, the question that doesn't come up is "how different systems contribute to business value, and how this value interacts with these other architectural attributes."featured in #177
featured in #177
Simple Systems Have Less Downtime
- Greg Kogan tl;dr: Easier to manage, simpler systems require less proficiency and troubleshooting, and provide more alternatives. The post outlines three principles of simple systems.featured in #176