Any questions about software architecture? Let us know for the chance to be featured on a DEV podcast!

The DevDiscuss Podcast begins with an interview and ends with commentary from listeners — and we like to feature the actual voices from our community!

This week's prompt: “What are you burning questions about software architecture?”

For your chance to appear on an upcoming episode, answer the question above by:

• Calling our Google Voice at [phone] and leave a message 📞

• Sending a voice memo to [e-mail] 🎙

• OR, leaving a comment here (we'll read your response aloud for you) 🗣

Please send in your recordings by September 30th at 5 PM PT (8 PM ET, 12 AM UTC)

---

Don't forget to check out the latest episode, released on September 16th!

Comments

[ender minyard]

1. What are microservices?
2. What is CQRS?
3. Can you explain why people use frameworks?
4. Assuming people use frameworks just for modularity - is it possible to scale and have a fast website?

You can answer any (or none!) of these :-)

[Gracie Gregory (she/her)]

Thanks, @ender_minyard !! Any chance you'd be interested in sending in a voice recording of this comment? Or a similar one? We'd love to feature your voice on the podcast :) Instructions above if you are open to this!

[Alexandru Muntean]

Hello,

My questions are:
1) Why people are talking they are doing microservices when what are they actually doing is a monolith with several services or REST calls? Where is the misunderstanding? :)
2) Which are the most commonly used software architecture styles and patterns?
3) Are there any steps to follow when starting a new project and you have to design the architecture for it?

Thanks in advance!

[Gracie Gregory (she/her)]

Thank you, @alexandrum ! We'd love to hear a voice recording of this comment if you're open to it! Instructions above if you might be interested in that!

[Alexandru Muntean]

Glad you like them, but I am too shy even for a voice recording. Sorry :(

[Glenn Paquette]

As someone who is starting to work on larger projects and trying to bring in other devs to contribute, I'd love to get a bit of a breakdown on how to approach architecture planning for a project.

1. What things need to be considered? As in, what questions should you ask yourself for every project you plan.
2. What are some red flags that point to potential problems that should be addressed?
3. What is something you wish you knew as a beginner, as in, something that would have made a project easier or saved you from problems down the line?
4. How to deal with opposing opinions on architecture from your team. Example: SQL vs NoSQL, node vs go, etc... Seems like everyone has an opposing opinion on what is best.

[Mike Bybee]

As an architect myself, who learned what not to do from inheriting others' architecture (and who was forced to implement it earlier in my career), my question is:

Why do so many of you make it so damn complicated? And have none of you ever considered that junior devs might make up part (or possibly even all) of the team implementing it?

Go work for a tiny, cash-strapped startup, and you'll see how little of that crap can fly.

[Denis Anisimov]

My perpetual struggle is documenting the software architecture. Boxes and arrows diagrams in a Google Doc works fine, but I keep searching for the better approach. What are the tools, processes, and automations an architect can use to produce and keep in sync the documentation?

[Simon Brown]

In case this doesn't get asked/answered on the podcast ... I created something called the C4 model that might help. It's a hierarchical set of diagrams that can be used to visualise software architecture. The website has lots of information, examples, and some links to tooling too. My recommendation would be to look at text-based tooling, which you'll find easier to keep in sync with changes in your codebase.

[Catriel Lopez]

Should we always follow a design pattern? When is it ok to not use one?

[Drakso]

1. How does architecture affect small scale systems and applications?
2. What architecture is the best fit for small applications and solutions?
3. How do we know when to stop adding complexity to our architecture and prevent over engineering?

[Btara Truhandarien]

There is a sense from job postings that software architecture is solely within the territory of more senior engineers. While the argument for experience makes sense, I also feel like junior developers should be put into more hands on architecture. A key aspect of architecture is design, and if making software isn't primarily seen as the task of designing computer systems, I don't know what it is then. Can you chime in on your experience or thoughts about bringing more junior roles to architecture decisions?

[Henry Quinn]

When I have to implement something I've never done before, I often read a bunch of blog posts, articles, and StackOverflow answers - then homogenize all of that to come up with a solution.

How do architects go about making a decision when they have a handful of viable options for solving a problem they're facing?

[Andres Cespedes Morales]

Hi @graciegregory ,

I've sent it out already but bringing it here as well.

Now, in this microservices world, software architectures are defining distributed systems (a.k.a. microservices) but when it comes to defining the granularity or size of these services there's no definite guideline, so what would be the advice on making this sizing/granularity challenge easier to deal with?

Also, there are plenty of questions that I would love to provide a solid point of view on them. Moreover, to participate in upcoming podcasts too.

Best,
Andres.