Love the emphasis on software design as iterative. It's impossible to abstract everything from the start. Instead, we must look at concrete instances, abstract, then look at abstractions and generate concrete instances and so on. "One concrete problem is worth a thousand unapplied abstractions."
great talk on architecture and design fpr software development. My take aways: - keep in mind that it is an evolutionary process - engage every developer - have a rough design as early as possible - make first guess based on your understanding and use this as basis of your further experience - check whether your architecture fits the need of the system - approach: incremental design - don't try to have too precised architecture.
I had to double take the T-shirt (which is one of my favorite part of this series) , I read it first as "rebel scrum". I think that is also an interesting T-shirt idea.
Dave, i greatly appreciate your content. Your calm, grounded pragmatism and the experience it shows are genuinely helpful to my day to day work. Thank you for sharing!
As a Junior software engineer who's just starting his career, I appreciate your contents. This will help shape my career and the e way I see software development
11:40, I use to think the general flow of data as a simple thing. But in practice, some ugly measures have to be done. Splitting classes to keep data security, more layers of data access to become clear, and so on. All things that I rather not do, but technically I feel compeling to. People discuss how much inheritance can mess things up, but I don't use to have such issues: I start with a simple thing, focused on what I need now, and throughout time I come back to make little upgrades. It's a kind of "become forced by practice" motto. 13:15, there's a problem in multithread, called "false sharing": each time a process read a cache line (32 or 64 bytes), it blocks to all other threads the access to that line (those bytes). To solve this: put data from each thread in different cache lines. 17:20, someone said, in a recent presentation: _"Classes work as black boxes: we put things there and forget about it"_ . I appreciate this in design: the less 1 needs to keep in mind, the easier it will be to upgrade the architecture.
Iterative software design. You are right. You can start doing a monolith design for a simple application and as business requirements evolve, so it does the architecuture the application Is built upon. Software architecture design Will heavily rely on business requirements as it evolves.
Love the video! It was very timely for me. I'm in the process of working on the architecture of a new app and I'm grappling with some of the things you discussed. The farther I've gotten in my career, the more I see that the incremental approach with a few constraints or rules seems to be the general approach to follow. It started for me with TDD and Agile, but now I'm starting to see that iterative pattern everywhere in the process of making great apps. Thanks again for the great content.
I love this take. It boils down to don't over think it. Often all we have to go on are informative guesses of what our stakeholders truly want, in time we learn more as we start peeling away the layers. Use the tools we have to try and make good decisions. It's very easy to feel overwhelmed in the fledgling stages of designing a system. Very often 1st 2nd and even 3rd iterations aren't 100% right. It's good to be aware of the entire system but try and keep scope lean it'll help to keep yourself and the team focussed. I've worked on pieces of software that have gone through multiple stages of redesign and or rework because we had put ourselves in a corner or just made it so complex in the early stages of design that it became almost unmaintainable.
Dave, great video: thank you! What do you think of architectures such as the Hexagonal Architecture, Onion Architecture, or Clean Architecture? Do you think they help approaching architecture in a more disciplined way? Do you think these architectures are more broadly applicable?
I don’t think there is ever a “one size fits all” but I do like the defensive nature of hex and onion architecture. I tend to think of hex more in terms of ports and adapters and apply that style often.
Very interesting topic, too often I hear 'I'm the architect so you have to do it like this...' not giving any ability or safety to the development team to try things. What I like is when and architecture team are acting as guides, having visibility into the wider strategy or roadmap to ensure that the individual parts that the teams are working on will fit into the wider long term application and avoid wasted work or create more work later on
Another great video. Binge watching your videos today. "It is a snap shot of the shared understanding...." best definition of architecture I've heard. Agreed...good design often requires an iterative approach enabled by good architecture. Progressive refinement vs no design. Design change requires roadmaps and change management planning.
‘Distributed Monolith’ - never heard of that description of wrongly implemented Microservice Architecture. When would you suggest and app development team adopts modularity into building their key features into separate components such that they function in a microservice-esque fashion & downtime on one feature doesn’t bring down the entire app? Could you also give reasons when a relational database like MySQL which handles live transaction data on an app should be used instead of a NoSql one line - PostGres or a document DB like Mongo?
I think s/w architecture is a useful set of components that has be put together in a very explicit way, to solve a particular non trivial software problem.
There are more formal definitions of what software architecture is, e.g. IEEE std 1471 and its successor ISO 42010: "The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution." One can always disagree with such efforts to define our craft, but it is always good to know what they say.
That we can still have the discussion about what software architecture means, without their being a well recognised answer, says a lot about the software industry.
Hey Dave! What do you think about the concepts of „ETL process“ and „API-Gateway“. Maybe you can make one or two videos about those. IMHO both are some kind of anti-pattern.
Some good concepts in this video Dave but the one thing missing for me is "Requirements". Software Architecture isn't guess work, it is always based on the client requirements, which obviously can change and hence why architecture should be an agile process.
For me being Agile in software development is a myth, you need to slow down, specially on early stages, to be fast. Common sense, simplicity and maintainability are not typical discussion in planning. Most projects now are designed to be cv/resume centric. Methodology and tools becomes the primary focus, and not what needs to be solved or delivered. If you will check the Agile Manifesto, its a fail early and fail frequently in early stages. Most we could do ar the start is to assume things. But it's a different story if we don't verify our assumption or make corrections on wrong assumptions. Management will not allow you to throw away some sprints because you made some wrong assumptions. The tendency is to sweep things under the rug. But to old dogs like me, mistakes are normal and actually welcomed early on. In summary, as always a good architecture is the one that properly solves the customer's problem.
Yet another truly informative video! Thanx, Dave :^) I equate software architecture to writing novels. There are plotters and there are pantsers. Pantsers start the story at the beginning and write forward. The story goes wherever is most interesting, ideally; i.e. the story is "discovered." Sounds wrong-headed and can lead to disaster but can be useful on small projects _(I wouldn't take that approach, tho)._ Plotters can be thought of as software architects/designers, combining elements (characters, places, objects, relationships, etc.) to define the flow of the story from a bird's eye view. However, in my experience, this can also get people into trouble if the writer views the plot as a "bible" from which never to deviate. *_In this sense, plot is design, but the various elements (e.g. libraries, formats, protocols, etc.) used in the plot define architecture_* In writing and development, I am what I call a *jumper.* I start with a rough plan with the objectives/outputs in mind, defining the necessary components to the best of my understanding at the time. Then I move forward from the core AND backward from the outputs making modifications to the design and architecture as needed. This may sound insane, but it's necessary to never lose sight of the objectives AND the constraints.
For me its not about writing a story... It is about how to separate functionality from infrastructure (logging, storage, networking etc), and creating interfaces that describe WHAT a piece of software should do as independently from HOW the software does that. An architecture should be able to grow in complexity over time without ANY impact on existing functional code :) Like planning a city the actual infrastructure should be independent from the facilities but they should be linked through well defined connections.
Great content. I want to agree with your views on flexibility in the system architecture solution. My group is working on migrating hundreds of applications from legacy on-premises to the cloud. So we are not dealing with much uncertainty as to the feature set. And we still find ourselves rethinking and tweaking the architecture on many occasions.
Lots of times. I recommend that this is a good way to start nearly every distributed project, certainly Microservice projects. It allows you to iterate quickly, and figure out good, loosely-coupled interfaces to your services, without slowing you down. It is the best approach for complex systems, that are coupled, or very high performance. It allows you to better tolerate higher levels of coupling, because you evaluate everything together. I was involved in the development of one of the highest performance financial exchanges, which was very modular, and very distributed 115 services in production, but it was stored together in the same repo, built, tested and released together into production. We could make any change and know if it was releasable in 56 minutes. It can be a very good approach.
@@ContinuousDelivery to give some background.... I design financial systems - payment processing software, not stock exchanges - and I'm struggling to find a good "microservice" design - I find I need bigger processes to do things right and people who tried hard to get microservices all ended up with a sad distributed monolith story, What makes much more sense in my context is to extract some components into micro services (bank integrations etc) but some components need to be bigger than what a classic micro service would be because their domain is very sharply defined yet fat - and any attempt to split it up would end up with pushing around an internal context/state object as payload, The solution there is to take these fatter processes, take the same source code basically and shard it into customer groups - deploying them in an SLA-dependent way, ...so this way you get to independent deployability and piloting the software on low-SLA clients before pushing it to high-SLA clients provides extra safety - it also allows easier infrastructure upgrades, more manageable DBs etc etc. You also get to practice CD on the low-SLA hosts, while still being able to honor the high-SLA requirements of other clients - notifying deployments a week in advance and stuff like that. It's just not classic microservices - but a sharding strategy with "mid-services" (reasonably lean modular monoliths - testable independently in < 5 min) and some micro-services mixed in.
☝️and that's why I decided to learn software development - for that seam part! Creating within and without constraints until this begots that. Thank you for confirming my decision to become a software developer at 49 years old was my best move yet - Much love from New Orleans ❤️
The biggest issue right now with Software Architecture is the internet. Its too easy for someone to read something and say "this is the right way to go" without even thinking about consequences. I've been in teams that right from the gecko the software already had tons of concepts, different technologies, different patterns, etc... And the complexity to even start messing around with the system was gigantic and the only thing the system was doing was presenting a couple of simple CRUD meaning a complete overkill. Also most developers / software architecture do not think about costs. For them having 10 different technologies and dozens of patterns is ok because it makes sense for them, but the consequence is that it limits the amount of recruitment / experience of the potential recruitments.
@Dave: can we get an affiliate link to the US Amazon store for the book? I looked it up myself but without the affiliation, that doesn't do you much good!
How start with Software Architecture, here is my guide. - I need to write a class as a Message Machinery. Not those Objects, design patterns, inheritance and abstractions. 1. Think about the informant. An informant side holds or allows access to consumable info. 2. Think about the Peer1. Peer1 is an inter-actor for local base communication. 3. Optionally think about Peer2. Peer2 is an inter-actor for remote communication. Example class Timer(History, Future, Space) implements Time History is Informant. You ask consumable info as input. Future is Peer1. Info need to be digested. Space is Peer2. Data exchange with others makes the application smart. From now on, you need sheer discipline to build every Message Machinery as explained above. It is you'r brick stone to keep reusing as same concept. No abstractions, unless data or math. No inheritance, no solid principles. No callbacks, no code duplication, no generators, no attributes, no dynamic or magic things, no global vars.
Dude, I call this "distributed monolith" a "microlith". you should help me spread the new term... it's awesome. you said it was good in some cases? I would be interested in hearing your thoughts on it as I found that these microliths usually are worse then monoliths or microservices.... I had not tried to come up with how they might be good!
Since architecture is so vague term that most people considered it as a hype, and just simply start and develop a system in a continuous delivery manner. They are right too. BTW database and transactional matter of it isn't a part of architecture. Surprise?
In some Projects, you are architectually extremely limited, by an „architecture“ that was intended by nobody in the team. It comes from some ridiculously badly implemented classes that are used everywhere and nobody feels responsible to get it out of the way. And there are guys in the team who have lost years of their life to maintain this. They protect this bad structure.
Name the Quality Attribute requirements as "non-functional" requirements is not proper and doesn't do a good service to teach the importance of those requirements. All requirements are functional and you can be certain a system won't function without Quality attributes in place. Just image you open your streaming service, all looks good, but because of poor performance and poor availability design it lasts forever to start playing the video. That's not functional.
I think it is important to define what is functional and what is non-functional, otherwise you may end up with an amazing piece of technology and architecture, that poorly executes what is needed by the business ... A simple unit test would identify the video problem, as you stated, it is and IT problem and not a business problem ...
Software is black magic. Too powerful, if you are careless with it, it will drive you insane. Also, if you are disrespectful to it, it will come back to haunt you. Hahahaha
Theory/Architecture of software is CRAP without solid definition and proof of these terms: Module, Program, Source-code, Intermediate-code, Runnable-code.
I like your books, but I don't agree with your definition of architecture when you just say evolutionary. Let us make a system that runs on the cloud and we start with EJB3 and evolve from there? You still gave a developer-centric or confined approach. This has caused mayhem in the software world. A developer can't ever work with business people, and he is just happy with the system working on his desktop. Architecture to be evolutionary is a thought, and before that many design decision has to be made, including Event-driven, ETL, and pipeline. Much has to be there as a process for, computing, network, database, security and right provider has to be understood and documented. Your definition is pretty dangerous as it tells us to run blindfolded just like a headless chicken.
I think you misunderstand what I mean. You always start with what you think is a good idea. Then you learn and adapt it. In my view, however good you are, you are extremely unlikely, ever, to get architecture right first time. Which means taking a defensive approach to architecture and design is essential. You need to keep your options open, not everywhere. But the people that I have met who are really good at this, are good at knowing how to avoid committing too early in important aspects of the architecture. The clever part is that what are the important parts depends on the problem.
@@ContinuousDelivery Dave I must say outright that I have learned from your book, CD, the path-breaking book with Jez Humble. You people had raised the BAR. I fully agree with what you say here. You are quite good. But Most of the software I have seen going down is due to the software developers who learn architecture by doing, scrambling a system that looks working but has no ability to scale, perform, reliable and the vast no of "itis" and the project ends. These are the developers who just protect the position like mercenaries. They all use similar logic and downplay the need to think beforehand. Thanks to the realities of the time, with the advent of the cloud and multiple clients, have exposed this GANG and architecture getting attention to what it needs. I have no desire to demean you as you are at least better than me and have more experience.
@@vimalneha I have no objection to people disagreeing with me, it is how we all learn. My thinking, particularly when it comes to "architecture" is that it is very complex. There are no simple rules that work, even taking an "off the peg" architecture can be a big problem if you choose the wrong one. I guess my intention is to point out that software is a complicated thing, and you need to be smart, creative, knowledgable and understand some of these complexities to do a great job. I think that too often we try to "dumb things down" too far. Your point is valid, the advice you give a beginner is not always the same advice that you need to give to an expert.
You say "What do they mean" and "to be fair to Wikipedia" as if 'they' are somebody else. Wikipedia is ours, created by us. Dave, Nicholas, some other people too. You should be saying "what do we mean" and "to be fair to us".
Forgive me, but I will take your pedantry, and raise it! 🤣 Fair point, I am a big fan, and I contribute financially to Wikipedia. I think that it is a genuine positive for humanity. But, I don't contribute in terms of content. So I think "they" from my perspective is fair. I certainly don't mean it in any derogatory sense.
Love the emphasis on software design as iterative. It's impossible to abstract everything from the start. Instead, we must look at concrete instances, abstract, then look at abstractions and generate concrete instances and so on.
"One concrete problem is worth a thousand unapplied abstractions."
That's how I handle development
great talk on architecture and design fpr software development. My take aways:
- keep in mind that it is an evolutionary process
- engage every developer
- have a rough design as early as possible
- make first guess based on your understanding and use this as basis of your further experience
- check whether your architecture fits the need of the system
- approach: incremental design
- don't try to have too precised architecture.
I had to double take the T-shirt (which is one of my favorite part of this series) , I read it first as "rebel scrum". I think that is also an interesting T-shirt idea.
ditto! and then i was kicking myself for having so much influenced :)
you and me brother!
I once wrote "Scum Master" on my resume. Only discovered it way later, when someone else pointed it out to me 😊
@@mikkolukas Well that at least is more honest than being a Scrum master
Dave, i greatly appreciate your content. Your calm, grounded pragmatism and the experience it shows are genuinely helpful to my day to day work. Thank you for sharing!
Thank you 😊
As a Junior software engineer who's just starting his career, I appreciate your contents. This will help shape my career and the e way I see software development
Thanks! Enjoy your journey.
This is why I always recommend this channel...
Thank you very much!
11:40, I use to think the general flow of data as a simple thing. But in practice, some ugly measures have to be done. Splitting classes to keep data security, more layers of data access to become clear, and so on. All things that I rather not do, but technically I feel compeling to.
People discuss how much inheritance can mess things up, but I don't use to have such issues: I start with a simple thing, focused on what I need now, and throughout time I come back to make little upgrades. It's a kind of "become forced by practice" motto.
13:15, there's a problem in multithread, called "false sharing": each time a process read a cache line (32 or 64 bytes), it blocks to all other threads the access to that line (those bytes). To solve this: put data from each thread in different cache lines.
17:20, someone said, in a recent presentation: _"Classes work as black boxes: we put things there and forget about it"_ . I appreciate this in design: the less 1 needs to keep in mind, the easier it will be to upgrade the architecture.
Iterative software design. You are right. You can start doing a monolith design for a simple application and as business requirements evolve, so it does the architecuture the application Is built upon. Software architecture design Will heavily rely on business requirements as it evolves.
Love the video! It was very timely for me. I'm in the process of working on the architecture of a new app and I'm grappling with some of the things you discussed.
The farther I've gotten in my career, the more I see that the incremental approach with a few constraints or rules seems to be the general approach to follow. It started for me with TDD and Agile, but now I'm starting to see that iterative pattern everywhere in the process of making great apps.
Thanks again for the great content.
I love this take. It boils down to don't
over think it. Often all we have to go on are informative guesses of what our stakeholders truly want, in time we learn more as we start peeling away the layers. Use the tools we have to try and make good decisions. It's very easy to feel overwhelmed in the fledgling stages of designing a system. Very often 1st 2nd and even 3rd iterations aren't 100% right. It's good to be aware of the entire system but try and keep scope lean it'll help to keep yourself and the team focussed. I've worked on pieces of software that have gone through multiple stages of redesign and or rework because we had put ourselves in a corner or just made it so complex in the early stages of design that it became almost unmaintainable.
Dave, great video: thank you! What do you think of architectures such as the Hexagonal Architecture, Onion Architecture, or Clean Architecture? Do you think they help approaching architecture in a more disciplined way? Do you think these architectures are more broadly applicable?
I don’t think there is ever a “one size fits all” but I do like the defensive nature of hex and onion architecture. I tend to think of hex more in terms of ports and adapters and apply that style often.
@@ContinuousDelivery great! Thanks for the answer.
Very interesting topic, too often I hear 'I'm the architect so you have to do it like this...' not giving any ability or safety to the development team to try things. What I like is when and architecture team are acting as guides, having visibility into the wider strategy or roadmap to ensure that the individual parts that the teams are working on will fit into the wider long term application and avoid wasted work or create more work later on
The more I learn the more I feel that there are so many things I don't know.
Me too, that's the fun part 😎
Another great video. Binge watching your videos today. "It is a snap shot of the shared understanding...." best definition of architecture I've heard. Agreed...good design often requires an iterative approach enabled by good architecture. Progressive refinement vs no design. Design change requires roadmaps and change management planning.
Dave! You did it again… this content is pure gold. I will be chipping pieces off out of the video to include in my presentations. 🤓😜
Another awesome video. Recently finshed the book Modern Software Engineering it should be a staple on every devs book shelf.
Thanks, may I ask a favour? Would you mind leaving a book review on Amazon please?
@@ContinuousDelivery done and left one on Goodreads
‘Distributed Monolith’ - never heard of that description of wrongly implemented Microservice Architecture.
When would you suggest and app development team adopts modularity into building their key features into separate components such that they function in a microservice-esque fashion & downtime on one feature doesn’t bring down the entire app?
Could you also give reasons when a relational database like MySQL which handles live transaction data on an app should be used instead of a NoSql one line - PostGres or a document DB like Mongo?
@5:32 beautiful. Getting it wrong means we learn and get it right … paraphrase but you get the gist…
I think s/w architecture is a useful set of components that has be put together in a very explicit way, to solve a particular non trivial software problem.
There are more formal definitions of what software architecture is, e.g. IEEE std 1471 and its successor ISO 42010: "The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution."
One can always disagree with such efforts to define our craft, but it is always good to know what they say.
last 5 minutes in your video was so impactful to me
That we can still have the discussion about what software architecture means, without their being a well recognised answer, says a lot about the software industry.
Hey Dave! What do you think about the concepts of „ETL process“ and „API-Gateway“. Maybe you can make one or two videos about those. IMHO both are some kind of anti-pattern.
Some good concepts in this video Dave but the one thing missing for me is "Requirements". Software Architecture isn't guess work, it is always based on the client requirements, which obviously can change and hence why architecture should be an agile process.
For me being Agile in software development is a myth, you need to slow down, specially on early stages, to be fast. Common sense, simplicity and maintainability are not typical discussion in planning. Most projects now are designed to be cv/resume centric. Methodology and tools becomes the primary focus, and not what needs to be solved or delivered.
If you will check the Agile Manifesto, its a fail early and fail frequently in early stages. Most we could do ar the start is to assume things. But it's a different story if we don't verify our assumption or make corrections on wrong assumptions. Management will not allow you to throw away some sprints because you made some wrong assumptions. The tendency is to sweep things under the rug. But to old dogs like me, mistakes are normal and actually welcomed early on.
In summary, as always a good architecture is the one that properly solves the customer's problem.
Yet another truly informative video! Thanx, Dave :^)
I equate software architecture to writing novels. There are plotters and there are pantsers. Pantsers start the story at the beginning and write forward. The story goes wherever is most interesting, ideally; i.e. the story is "discovered." Sounds wrong-headed and can lead to disaster but can be useful on small projects _(I wouldn't take that approach, tho)._ Plotters can be thought of as software architects/designers, combining elements (characters, places, objects, relationships, etc.) to define the flow of the story from a bird's eye view. However, in my experience, this can also get people into trouble if the writer views the plot as a "bible" from which never to deviate.
*_In this sense, plot is design, but the various elements (e.g. libraries, formats, protocols, etc.) used in the plot define architecture_*
In writing and development, I am what I call a *jumper.* I start with a rough plan with the objectives/outputs in mind, defining the necessary components to the best of my understanding at the time. Then I move forward from the core AND backward from the outputs making modifications to the design and architecture as needed. This may sound insane, but it's necessary to never lose sight of the objectives AND the constraints.
For me its not about writing a story... It is about how to separate functionality from infrastructure (logging, storage, networking etc), and creating interfaces that describe WHAT a piece of software should do as independently from HOW the software does that. An architecture should be able to grow in complexity over time without ANY impact on existing functional code :) Like planning a city the actual infrastructure should be independent from the facilities but they should be linked through well defined connections.
This one was really special Dave
Great content. I want to agree with your views on flexibility in the system architecture solution.
My group is working on migrating hundreds of applications from legacy on-premises to the cloud. So we are not dealing with much uncertainty as to the feature set.
And we still find ourselves rethinking and tweaking the architecture on many occasions.
Certainly a topic I'd like to learn more about.
When is a distributed monolith a good choice?
Lots of times. I recommend that this is a good way to start nearly every distributed project, certainly Microservice projects. It allows you to iterate quickly, and figure out good, loosely-coupled interfaces to your services, without slowing you down.
It is the best approach for complex systems, that are coupled, or very high performance. It allows you to better tolerate higher levels of coupling, because you evaluate everything together.
I was involved in the development of one of the highest performance financial exchanges, which was very modular, and very distributed 115 services in production, but it was stored together in the same repo, built, tested and released together into production. We could make any change and know if it was releasable in 56 minutes.
It can be a very good approach.
@@ContinuousDelivery Thanks
@@ContinuousDelivery to give some background....
I design financial systems - payment processing software, not stock exchanges - and I'm struggling to find a good "microservice" design - I find I need bigger processes to do things right and people who tried hard to get microservices all ended up with a sad distributed monolith story,
What makes much more sense in my context is to extract some components into micro services (bank integrations etc) but some components need to be bigger than what a classic micro service would be because their domain is very sharply defined yet fat - and any attempt to split it up would end up with pushing around an internal context/state object as payload,
The solution there is to take these fatter processes, take the same source code basically and shard it into customer groups - deploying them in an SLA-dependent way,
...so this way you get to independent deployability and piloting the software on low-SLA clients before pushing it to high-SLA clients provides extra safety - it also allows easier infrastructure upgrades, more manageable DBs etc etc.
You also get to practice CD on the low-SLA hosts, while still being able to honor the high-SLA requirements of other clients - notifying deployments a week in advance and stuff like that.
It's just not classic microservices - but a sharding strategy with "mid-services" (reasonably lean modular monoliths - testable independently in < 5 min) and some micro-services mixed in.
☝️and that's why I decided to learn software development - for that seam part! Creating within and without constraints until this begots that. Thank you for confirming my decision to become a software developer at 49 years old was my best move yet - Much love from New Orleans ❤️
I agree with you to enhance security of the web app at the end of the development.
The biggest issue right now with Software Architecture is the internet. Its too easy for someone to read something and say "this is the right way to go" without even thinking about consequences. I've been in teams that right from the gecko the software already had tons of concepts, different technologies, different patterns, etc... And the complexity to even start messing around with the system was gigantic and the only thing the system was doing was presenting a couple of simple CRUD meaning a complete overkill. Also most developers / software architecture do not think about costs. For them having 10 different technologies and dozens of patterns is ok because it makes sense for them, but the consequence is that it limits the amount of recruitment / experience of the potential recruitments.
Nicely done. Thank you.
Loving your book, very inspiring and educative. Thanks for the hard work.
Such a great well condenced talk. Thank you.
is the the book "Modern Software Engineering" good for beginner programmers?
I am biased, but other people agree with me, and say "yes" this is the kind of book that can help you whatever stage of your career you are at.
@Dave: can we get an affiliate link to the US Amazon store for the book? I looked it up myself but without the affiliation, that doesn't do you much good!
Thanks for the suggestion. I'll look into it!
How start with Software Architecture, here is my guide.
- I need to write a class as a Message Machinery. Not those Objects, design patterns, inheritance and abstractions.
1. Think about the informant. An informant side holds or allows access to consumable info.
2. Think about the Peer1. Peer1 is an inter-actor for local base communication.
3. Optionally think about Peer2. Peer2 is an inter-actor for remote communication.
Example
class Timer(History, Future, Space) implements Time
History is Informant. You ask consumable info as input.
Future is Peer1. Info need to be digested.
Space is Peer2. Data exchange with others makes the application smart.
From now on, you need sheer discipline to build every Message Machinery as explained above.
It is you'r brick stone to keep reusing as same concept.
No abstractions, unless data or math. No inheritance, no solid principles.
No callbacks, no code duplication, no generators, no attributes, no dynamic or magic things, no global vars.
I didn’t understand the example you supplied, could you add some more context and explain it even further at a simpler level?
learn about event storming because it fits pretty much our description :)
Can you talk about conventions for commits, issues, pull request, branch naming, etc
ua-cam.com/video/_w6TwnLCFwA/v-deo.html
ua-cam.com/video/v4Ijkq6Myfc/v-deo.html
Dude, I call this "distributed monolith" a "microlith". you should help me spread the new term... it's awesome. you said it was good in some cases? I would be interested in hearing your thoughts on it as I found that these microliths usually are worse then monoliths or microservices.... I had not tried to come up with how they might be good!
"grizzled veteran" :D - its the best nuts and bolts terminology ever!!
Very good stuff Dave
Can you talk about game development?
ua-cam.com/video/E-jGEtqB4wU/v-deo.html
Since architecture is so vague term that most people considered it as a hype, and just simply start and develop a system in a continuous delivery manner. They are right too. BTW database and transactional matter of it isn't a part of architecture. Surprise?
Brilliant!
In some Projects, you are architectually extremely limited, by an „architecture“ that was intended by nobody in the team. It comes from some ridiculously badly implemented classes that are used everywhere and nobody feels responsible to get it out of the way. And there are guys in the team who have lost years of their life to maintain this. They protect this bad structure.
Name the Quality Attribute requirements as "non-functional" requirements is not proper and doesn't do a good service to teach the importance of those requirements. All requirements are functional and you can be certain a system won't function without Quality attributes in place.
Just image you open your streaming service, all looks good, but because of poor performance and poor availability design it lasts forever to start playing the video. That's not functional.
I think it is important to define what is functional and what is non-functional, otherwise you may end up with an amazing piece of technology and architecture, that poorly executes what is needed by the business ...
A simple unit test would identify the video problem, as you stated, it is and IT problem and not a business problem ...
💻🚀✨
Software is black magic. Too powerful, if you are careless with it, it will drive you insane. Also, if you are disrespectful to it, it will come back to haunt you. Hahahaha
Theory/Architecture of software is CRAP without solid definition and proof of these terms: Module, Program, Source-code, Intermediate-code, Runnable-code.
I like your books, but I don't agree with your definition of architecture when you just say evolutionary.
Let us make a system that runs on the cloud and we start with EJB3 and evolve from there?
You still gave a developer-centric or confined approach.
This has caused mayhem in the software world.
A developer can't ever work with business people, and he is just happy with the system working on his desktop.
Architecture to be evolutionary is a thought, and before that many design decision has to be made, including Event-driven, ETL, and pipeline.
Much has to be there as a process for, computing, network, database, security and right provider has to be understood and documented.
Your definition is pretty dangerous as it tells us to run blindfolded just like a headless chicken.
I think you misunderstand what I mean. You always start with what you think is a good idea. Then you learn and adapt it. In my view, however good you are, you are extremely unlikely, ever, to get architecture right first time. Which means taking a defensive approach to architecture and design is essential. You need to keep your options open, not everywhere. But the people that I have met who are really good at this, are good at knowing how to avoid committing too early in important aspects of the architecture. The clever part is that what are the important parts depends on the problem.
@@ContinuousDelivery Dave I must say outright that I have learned from your book, CD, the path-breaking book with Jez Humble. You people had raised the BAR.
I fully agree with what you say here. You are quite good.
But
Most of the software I have seen going down is due to the software developers who learn architecture by doing, scrambling a system that looks working but has no ability to scale, perform, reliable and the vast no of "itis" and the project ends. These are the developers who just protect the position like mercenaries. They all use similar logic and downplay the need to think beforehand.
Thanks to the realities of the time, with the advent of the cloud and multiple clients, have exposed this GANG and architecture getting attention to what it needs.
I have no desire to demean you as you are at least better than me and have more experience.
@@vimalneha I have no objection to people disagreeing with me, it is how we all learn. My thinking, particularly when it comes to "architecture" is that it is very complex. There are no simple rules that work, even taking an "off the peg" architecture can be a big problem if you choose the wrong one. I guess my intention is to point out that software is a complicated thing, and you need to be smart, creative, knowledgable and understand some of these complexities to do a great job. I think that too often we try to "dumb things down" too far. Your point is valid, the advice you give a beginner is not always the same advice that you need to give to an expert.
You say "What do they mean" and "to be fair to Wikipedia" as if 'they' are somebody else.
Wikipedia is ours, created by us. Dave, Nicholas, some other people too.
You should be saying "what do we mean" and "to be fair to us".
Forgive me, but I will take your pedantry, and raise it! 🤣
Fair point, I am a big fan, and I contribute financially to Wikipedia. I think that it is a genuine positive for humanity. But, I don't contribute in terms of content. So I think "they" from my perspective is fair. I certainly don't mean it in any derogatory sense.
nothing interesting