Crafting Code Podcast

~/podcast

$ cd episodes/014-software-architecture

~/podcast/episodes/014-software-architecture $ ls -1a

. .. episode-summary.txt get-mp3.sh

~/podcast/episodes $ cat episode-summary.txt

Despite the near-universal agreement of the importance of software architecture, it is very difficult to define. In this episode, your hosts share what we've learned from holding the architect role (and title) at various companies. For us, the crux of it comes down to figuring out how to deliver technical value for changing business needs over time.

Timestamps

[00:00:00] Host introductions. The many attempted definitions of software architecture. Keeping the software close to the purpose.

[00:05:49] What matters is achieving business goals: earning or saving money. Good architecture isn't about technical achievement for it's own sake. Be careful when you talk about "the business." Like physical building architecture, software architecture must account for many concerns.

[00:12:08] Be careful about your aspirations; being an architect isn't a sign of being the smartest. Being an architect can often feel dissatisfying if you are not solving a problem for a company. It is about applying your technical skills in a new way, not abandoning what you worked so hard to learn.

[00:18:23] An "enterprise software architect" is the bridge between strategy and technical work. Architects provide options and lay out the tradeoffs.

[00:21:19] Point-in-time architecture isn't as interesting as watching what changes over time and at what rates. Clean and cheap-to-change is better than trying to predict the future. Focus on the socio- part of the sociotechnical system.

[00:27:09] If you have software, you have software architecture. Everyone touching code is participating in architecture, but we usually call someone "architect" when they are working at higher levels of abstraction. Titles are problematic. Architects can augment the CTO, but may not have a seat at the strategy table.

[00:34:23] Architects ought to be like Matt's real estate agent: she brings solutions to problems but never tells him what he should value. Understand what the business wants and give them options to achieve that. Architects have to think about many things at once; including time horizons and levels of abstraction. These concepts also apply to open-source projects; they just have different goals.

[00:41:02] Leaders (executives) in tech companies are responsible for providing clarity on what the software needs to do. Otherwise, even the best architect cannot be effective. Architects and leaders are all human and are going to make mistakes.

[00:44:24] How do you know whether an architect is performing? Humans are hard to measure. Examine choices, delivered value, lead times, error rates, and happiness of those involved in the work. Software architecture is often like wifi; no one cares until it isn't working. Be very careful with what you incentivize.

[00:54:21] Conway's Law. Sometimes our failures come because of a mismatch between the people and the technology. Don't build tech at odds with the culture.

[00:56:50] Juval Löwy may be very... colorful but he taught Matt an important lesson: when designing technical systems, pay attention to what changes. Things that change together should stay together.

[00:58:54] Outro.