Software Architecture Tips I WISH I Knew Sooner

[@frankweiler7121]

It always feels like you are accompanying me on my career path. Thank you for that 🙂

[@SimoneColaci]

I absolutely agree on that

[@HartleySan]

This channel is quickly becoming my favorite software engineering-related channel. Thank you, Dave! Also, to #1. Context, I love this quote from Einstein: "If I were given one hour to save the planet, I would spend 59 minutes defining the problem and one minute resolving it."

[@drhilarius]

"Software architecture is a complicated topic": I couldn't agree more. That's the reason, why I find the often quoted "one sentence descriptions" of some of the renowned experts in the field misleading and often self-indulging in their abstraction and (unjustified) shortening: Sounds catchy, but does not help a bit, especially for non-technical management to incorporate in their thinking. Additionally, they often fail in including the importance of software architecture to build a bridge between management (business) and implementation/operation (IT) and the role of IT to have become an enabler and not being a cost center anymore (thanks to Gregor for doing a really great job on that). Thank you, though, for your very interesting (as always) take on the subject!

[@nufosmatic]

2:28 - The first step, the architecture step, in a system is to abstract the system concepts as an API to deliver what the system is expecting in a system "language", then implement that API to the available resources on the target hardware. The engineering step is to work both ends until they come together in an efficient way. And there may be multiple layers and multiple abstractions necessary to accomplish this.

[@matthewtrow5698]

Perhaps that elevator between the engine room and the boardroom is often the problem when it comes to software architecture. A lot can change on that journey from the engine room to the boardroom - and only one or maybe a handful of people from the engine room are represented. Sure, too many cooks spoil the broth, but it certainly points out one of the glaring issues of software architecture we are all aware of - whether those in the boardroom really know what it is they want the engine room to build for them. An age old problem most noticed in large organisations. When the board rooms only connection to the engine room is via a middleman - the architect - that's when problems arise. If the architect was _on_ the board as a permanent representative and didn't _need_ to get that elevator upward, perhaps things would run more smoothly. It's all down to who you hire for specific roles, especially at the higher level of company heir-achy - you really DO want a knowledgeable engineer in that boardroom at all times. Someone who has spent a lot of time in that engine room.

[@BryonLape]

Or the phone call that comes into the board room while the engineers are in the elevator.

[@Alpheamus]

Great comment, brother! Great perspective and thinking.

[@vk3fbab]

Great work DF. Going to post this one to my work colleagues. Hope they watch this and take all that I did from this.

[@petebrown6356]

imho 'good architecture' *primarily* means that you have designed for change, that things have enough abstractions from each other where a significant implementation of one part of the system can be reimplemented without the rest of the system being impacted. That said, with that in mind the other 'ility' items need to be addressed via a checklist and review.

[@rwri002]

Absolutely I deal with this on a daily basis I wish I could get my team to understand the principles you talk about here. A good design is an adaptable design! Maybe an idea for a video there😊

[@emmanuelaliji3497]

I really appreciate your efforts in putting out these videos. I must say you are a wise Software expert. Much respect from myself.

[@ContinuousDelivery]

Thanks 🙂

[@aldosilva6]

It reminds me Kent Beck: "Make the change easy, then make the easy change."

[@ContinuousDelivery]

Yes I think that this is very much a philosophy of design that Kent and I share.

[@ChavaDoboj]

Thank you for the content Dave!

[@MurrayNatkie-od5cv]

I love absorbing your wisdom through these videos but I need a way to buy every T-shirt you wear.

[@ContinuousDelivery]

Check the description!

[@antoniorocha9438]

Great content, but unfortunately, one may need some years of experience (or failure) to fully understand the truth meaning. It is common today to put a lot of technology names way too soon and forget the importance of working on the requirements.

[@ContinuousDelivery]

I think that's true, you can't really be a software architect without a fair amount of experience. It takes the synthesis of a lot of stuff that you probably won't think about until you have seen things got wrong a few times in interesting ways 😉

[@nufosmatic]

7:39 - I've had a few projects with lots of crocodiles and monkeys myself...

[@nobiggeridiot]

The cheeky jab at twitter made me giggle, cheers !

[@rickross-z3j]

Excellent.

[@chat-1978]

I noticed the relatively sudden introduction and usage of the word "software" with architecture for this video. It seems to me that the video discusses high level architecture topics and not what I understand software architecture is about (code related) which is normally addressed by the dev leads. Maybe I understand it wrong, maybe it's worth while doing a video for the different types or architecture. Unfortunately the industry is full of mixups, misuse of terminology not excluding me.

[@NicholasShanks]

I laughed for half of the remaining video when you introduced Bitter with its red bird logo. 😂 Try not to be too bitter.

[@mesopotamianmessenger5830]

This video came out too late for me, I had to discover the point the hard way. Absolutely worth listening though. PS. The angle of the tonearm on your shirt is wrong.

[@lerssilarsson6414]

SDLC - Waterfall Model, did they get the idea from Fallingwater, a house designed by the architect Frank Lloyd Wright. ;-?

[@valentyn.kostiuk]

Bitter sounds like a very viable project. You know you go there to be humiliated.

[@MaximilienDanton]

I'm in. I'm thinking things that are downvoted most get pushed to peoples' feeds. It could be the first anti-social network. Ok not the first because twitter and facebook exists. But still!

[@BryonLape]

The hardest thing to change and the thing that is constantly wrong.

[@nufosmatic]

17:27 - EMBRACE THE SUCK!

[@rkd80]

Every time Dave says 'commonest' I hear 'communist'. Not a useful comment but felt important to share.

[@cheetah100]

The Ideal Computing Architecture: kzbin.info/www/bejne/e6bcdqqiaNxomrs

[@thewiirocks]

Sooo... everything in your video is technically correct. The problem is that it's too abstract to be useful to most wannabe architects. Telling them to stay flexible + scalable isn't going to stop them from choosing React + Node. They're going to assume that these solutions are flexible and scalable because they're popular. They have what psychologists call "social proof" that they work. Even though they are the exact opposite of the architectural principals you laid out. I love what you're trying to share. But you're going to have to get more in the weeds if you want to win hearts and minds. The AI is pretty cool, though.

[@cheetah100]

@@thewiirocks I agree, each point really needs to become its own video. Staying flexible and adaptable can mean many things. For me it means avoiding binding to the domain. It may also mean making decisions that keep your options open, say by using standard SQL and not product specific extensions. kzbin.info/www/bejne/q6i9m2eOe5utn8U

[@thewiirocks]

@@cheetah100 I agree with limiting binding as much as possible (late binding being preferable when possible), but your video is a bit off base. Java absolutely has a schema. It's just encoded in classes rather than tables. One could argue that you can design your class files to be flexible. Yet the same is true of relational database schemas. Properly implementing OLTP vs OLAP schemas (depending on what you're doing) can make your database an incredibly effective service. In fact, I would argue that poor thinking about schema holds people back in both cases. Especially when people start crossing the streams and leaking relational concepts into the object graph and object concepts into the relational modelling.

[@kennethgee2004]

Architecture and engineering are not the same. Architecture is about how the systems will salve the issue. Engineering is about how to get systems to connect to achieve the architecture. Development is about implementing the details of the engineering. Programmers is about being a subject matter expert in a specific language. The programmer can optimize and shorten/flatten the implemented designs.

[@ContinuousDelivery]

I am afraid that I disagree with nearly all of that. I think that architecture, engineering and programming are all about organising our ideas in a way that allows us to effectively create products in software. Architecture are the general principles of the system, engineering is about the application of the general principles of software development and programming is about a lot more than being a subject matter expert in a programming language. Good programmers are good programmers in languages that they don't know very well. There are important principles in programming that matter a lot more than language specifics, and these are the deeper engineering principles of our discipline, so the line are blurry between each of these things, but I am sorry to disagree so strongly, but I think that the idea that the job of a programmer is to translate from one detailed description into the code of a programming language, is one of bigger problems in our industry, and that approach never ends up with great solutions. The people that write great systems, understand the problem, not just how to code!

[@kennethgee2004]

@@ContinuousDelivery Well you can disagree all you like, but that does not mean that you are correct. You even said at the beginning that different companies have different lexicons about positions. I am standardizing the classifications based on my experience as an in the trenches developer and engineer. I have even moved into architecture recently. These classifications are from practical experience and how I break down the classifications based on roles within software creation. Architecture is about the systems and technologies used to create a solution to a problem. Architecture is not about implementation details nor does it answer how moving parts interact. Architecture will only gives us things like flow diagrams and logical systems charts. There are no general principles that I have ever read about software architecture, which is why it is so hard to get right. There is nothing that tells you what systems must be in place for a solution. There is no way to tell people that they must use one language over another in order to create a solution. Additionally, there is the issue of do you use a library from a third party or do you create your own to help solve the problem, which is answered by architecture, but is not answered in a general principle. Engineering is about how we define systems and how they will interact. Here is where principles do come in. We should be using SOLID to help design those interactions. We need to think about the logic of how the systems interact so that we can make interfaces or whatever the equivalent is in a particular language. We do not worry so much about the implementation details yet though. We design the adapters for data and transports for communications. We look at structures for handling business logic. What you call "one detailed description into the code" is a unit of work that the developer implements. Developers are those that are responsible for actually implementing the details and actually making things work. What you are calling programmers are in my thinking developers. They know how to handle implementation details like for loops and other features. This is what we go to college for to learn. We do not leave engineering to our junior and regular developers. Programmers are language specific experts and could tell you more about a language than anyone else. They are there to help optimize code in ways that other people just do not grasp yet. They have great depth of knowledge on how to use tools to analyze performance and an insight as to where bottlenecks often happen. The idea that great people understand the problem and can write good code is true, but it is a team effort with roles being applied. No one individual writes good code without interaction from an outside source. Otherwise all solutions would have already been written. It takes users to prompt for a product. it takes business to see if there is reason to build it. it takes architects to see how as system might solve the problem. It takes engineers to define the moving parts. it takes developers to implement the ideas and concepts. It takes programmers do optimize the code for efficiency. You can define the actually names as you wish based on your career, but these are the principles to a software development team.

[@peterdz9573]

Well you can disagree all you like, but that does not mean that you are correct. Man, that is some cocky tone. Are you really an architect with such soft skills? I would not like to discuss system details with you

[@kennethgee2004]

@@peterdz9573 soft skills? i do not have the time for those. And yes you really would like to discuss system details with me as you will get an honest report of what the software can and cannot do at this time. You will get an honest report of what the team is capable of building. I wonder though if you missed the sarcasm in that i can disagree all i like, but that does not mean i am right either. What matters is what is right. We should be asking questions based on guiding principles that were not created out of thin air, but by years of industry mistakes and successes. I am defining my terms for the role as noted in the beginning that different places might call things differently. I am pointing out the definitions for the roles into a classification that is object oriented so we can use polymorphism to insert name for role and slight tweaks as required or wanted. It was an attempt to define these for the industry that all have egos as you have displayed and proved for us. So way to miss the point but make the obvious point of ego. Kudos keep up the good work.

[@ContinuousDelivery]

@@kennethgee2004Sorry, still disagree, but as you say that doesn't mean that I am right. I too have had job titles like "architect" "enterprise architect" and "principal architect", for more years than I care to recall, but none of that means that I am right either. However, I did think it earns me the right to hold an opinion. The division between "architect", "engineer" and "developer" that you mention at the end are NOT "principles", they are the kind of division that some types of companies tend to apply to job roles, and these are usually not the kinds of company that are building great software. For example, one of Elon Musk's sayings in the context of Tesla and SpaceX (let's not mention Twitter) is that "everyone is chief engineer", which means that EVERYONE is responsible for everything, and are encouraged to "take part" anywhere that their interest and experience takes them. I would say that if you separate the roles in the way that you describe, you will pretty much always get a sub-par result. What you describe is what I would call the "ivory tower model" of software architecture. Everyone, whatever their job, does a better job when they are close to the results of their decisions. I want to see where my dead fail and how, and where they succeed and how. If architects are NOT sometimes working alongside engineers and developers on a frequent basis, they will make mistakes, by skating over complexity that invalidates their ideas. This is probably the commonest form of "SW architecture" in our industry, in my experience.

[@youtischia]

The title isnt quite right. It should be "Tips I wish I had known sooner". Can you see that extra "had" in there ? Common error on youtube.

[@zoranProCode]

If I only lesten you and don’t watch it’s totaly unclear when the talk about one tip starts and another one begins! You don’t make a clear separation of them. Video context is totally blurred, it’s almost obviously that you read from somewhere and that you don’t care about how you transfer the knowledge to auditorium which is supposed to learn. You should learn from Uncle Bob who is one of the geniuses in transferring the knowledge!

[@sandves]

Great content as always, but please, stop using those animations in the background. They are so disturbing...

[@xbzq]

Those sound effects are so... unsubscribe. I've had enough of those sound effects. Call me petty. It's too tryhard. And it's also distracting. It's a show, and not a good one. I can't hear what you're saying because those effects are prominent. Whoosh. Swoosh. Word. More whoosh. Another swoosh. Maybe there was another word but all I hear is another wooooosh. It's so effects. So video editor. So sound effects looking for a place to be heard, found a home on your channel. I can't even.