Software Architecture Tips I WISH I Knew Sooner 

I absolutely agree on that

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

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

Thanks 🙂

Check the description!

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 😉

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.

@@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. ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-uwZj4XF6zic.html

@@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.

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!

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!

@@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.

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

@@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.

@@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.