Looking for books & other references mentioned in this video? Check out the video description for all the links! Want early access to videos & exclusive perks? Join our channel membership today: th-cam.com/channels/s_tLP3AiwYKwdUHpltJPuA.htmljoin Question for you: What’s your biggest takeaway from this video? Let us know in the comments! ⬇
*Timecodes* 4:30 Your system has an architecture whether you want it or not 6:00 Scaling Dimensions 7:45 Non-extensible Extensibility 10:54 Perilously fine-grained 16:35 Your system WILL be dynamic 18:35 Change the meaning of the attributes 20:35 Free-style architecture 26:40 There's a fine line between diversity (that adds value) and chaos (that doesn't) 28:40 Cancerous Growth 33:40 Improve with less intelligence 34:50 If the tool brings its own IDE you should be worried 37:35 Strangler Pattern 39:00 Takeaways
One of the best talks I heard about the important balance between centralization and autonomy in the age of DevOps and microservices. Thank you very much!
Decided to write their own encryption ... Still laughing over that one ... the fact that it is written in Borland C++ and has to run in a VM makes it all more hilarious ... Makes my various experiences seem not so bad ... I've seen lots of this kind of stuff over the years :-)
i kind of getting why you saying this, but i personally disagree. everything evolves. and evolution has neccesary branches which are destined to fail and go extinct. but every evolutionary step has the chance to grow into something bigger perhaps even a new standard. if everyone would agree that we should only use ready made industry standard tools, we would still live in caves. that was the industry standard for humans. or just hunting and gathering... that was also the standard. and even if it is certain that it is a dead end: coding it, designing it is an invaluable experience and knowledge to peek into how the others work on a fundamental level. which in turn will make you a better developer. if they are keep forcing it / using it after it turned out to be a dead end and / or limiting the system (or risking secuirty/stability /etc) then we can start doing facepalms on JLP levels ... but not until that :)
@@mityaboy4639 The reason why you shouldn't roll your own crypto was stated in this same presentation: their crypto had errors and in the end was not secure at all. So they ended maintaining legacy unworking crypto. Not very great situation. They didn't write their own algorithm but instead implemented a known algorithm. Doing that does not take humanity any steps further but can take a company to a risk.
In my last job they used an Excel sheet with vb macros for all the components they were producing in the factory part of the company. But if were not bad enough, this Excel sheet's macros were used to generate a database which was then used to generate another Excel sheet with macros which was then used to create the files used by our systems. Then there was another command line executable written in .NET CLI which was the most unclean copy pasted pile of code I've ever seen. Adding a functionality, or worse a new field, to this "DB manager" was seen as a punishment. They still have this technical debt monster running to this day, with various attempts to put all that crap into a nice DB shutdown by management because "we need to go fast no time for refactor that produces no client value" even if shit like these are the reasons we are going slower and slower. I'm glad I quit, my mental health was going downhill each day.
I admit I fall into the same sort of anti-patterns that this discusses. But we do try to evolve to make sure that things will be able to adapt. The last two takeaways he discusses in 39:40 illustrate what I set up to do. The evolution is still pretty rapid. Hopefully as we scale in number of developers, a few of us can formalize the architecture, but for now it's pretty much quick discussions during the sprint and planning for it in next and future sprints. That being said having an end vision of what the architecture would sort of look like helps. I don't intend to copy Netflix, but having the idea of distributing the work/data into isolated instances for data capture and presentation but utilizing technologies such as Kafka to push into a federated store keeps back office analytics work separate from core applications.
Great talk. The issue with "everyone does architecture" while true in a sense, devs should be able to decide when it comes to implementation details, but if there is no dev looking at the big picture this also means that there is no consistent architecture, and your product looks like a design by committee. Yeah, better do those choices consciously. So I guess the thing is big A Architecture looking at the big picture should be more about application/services integration that anything else, and not as focused with intra-application, except when we do have real application layers (like front-end, back-end, db) specially when managed by different people, not just virtual ones (model, domain, application, etc), the latter which should be up to the devs maintaining them and freely refactor internally as needed as long as they keep talking to other applications, services and physically separate layers of the same application, as they were before. And I fully agree you need to be a good dev to be an architect (even if it is someone that temporarily takes on that role) and that experience is what makes you able to not just apply something as cargo cult, and some times even overdoing it so wrong and misunderstanding Clean Code (or whatever you think you're applying) so deeply that there is no practical benefit from the way your software is laid out, it just looks enterprisey, costly to maintain, and everything is everywhere, but it has tons of interfaces and you see they used those standard magical names for their packages.
Sharing responsibility over a single server between multiple teams does in deed sound like it breaks the idea of teamwork in general. The idea of distributing a single task across team boundaries is one of the anti-patterns for organizational efficiency even in management literature. I'm thinking of Fredmund Malik's books specifically here.
Many many thanks for this lecture, Stefan! All is so true... I think the main issue about not investing enough in Architecture is that people find it too abstract and/or boring.
He looks a bit like Computer scientist Dennis Ritchie, who drove the design of the C programming language and the UNIX operating system, who died in 2011
At 21:40, you share levels of abstraction (methods < modules < components < ...). Depending on the technology context, do you agree that modules and components can abstract one another (above and/or below in the diagram)?
This talk would have been extremely beneficial for some managers at IBM I worked with about 3 or 4 years, where we had to turn a multi-million project's architecture around because ..... wait for ittt...... it was the WRONG THING. The cherry on top is that they tried to hide it from us and at the same time sugar coat their fuck-up to the client. I left that company not long after, too much toxicity and politics.
I am not 100% sure but what I think he is suggesting is to split up (possibly even duplicate) the functionality from the orders module thus making each of the other modules independent.
@@sirAlexander_T The best sarcasm is like some rando walking past you on the street and slashing you with a scalpel, and you walk another 3 km before realising that you're bleeding. That bit might be good for 5 km. 😀
The title is kind of sarcastic and indirect. The whole video points to the idea that an architecture is 'alive' and never finished, the stakeholders should decide when it's enough. As Stefan said, if the system just works, nobody is interested in the architecture. If the system does not work over and over, the architecture is over-engineered and over-emphasized.
What were you hoping to see / hear @deasystems? Stefan starts with the definition of software architecture and then spends the entire video reviewing various architectures.
@@OutdoorsWithChad yeah I was waiting for tips on what cement to best use for support columns, but all this guy talked about was computer program coding or some such nerd thing /s
Looking for books & other references mentioned in this video?
Check out the video description for all the links!
Want early access to videos & exclusive perks?
Join our channel membership today: th-cam.com/channels/s_tLP3AiwYKwdUHpltJPuA.htmljoin
Question for you: What’s your biggest takeaway from this video? Let us know in the comments! ⬇
RIP Stefan. The day I found you was the day I realized we lost you, but your legacy will remain for a long time.
*Timecodes*
4:30 Your system has an architecture whether you want it or not
6:00 Scaling Dimensions
7:45 Non-extensible Extensibility
10:54 Perilously fine-grained
16:35 Your system WILL be dynamic
18:35 Change the meaning of the attributes
20:35 Free-style architecture
26:40 There's a fine line between diversity (that adds value) and chaos (that doesn't)
28:40 Cancerous Growth
33:40 Improve with less intelligence
34:50 If the tool brings its own IDE you should be worried
37:35 Strangler Pattern
39:00 Takeaways
"If your design attempts to satisfy everyone, you'll likely end up satisfying no one"- That line right there hit the nail on the head!
The philosophy of goverment.
One of the best talks I heard about the important balance between centralization and autonomy in the age of DevOps and microservices. Thank you very much!
💯 - agreed!
Wow that 3rd example was diabolical. Excellent talk!
OMG I love his voice.
OMG SAME I could listen to this butterman for ages lmao
Very interesting and practical talk! Thanks a lot to the speaker and the organizers!
Great talk by Stefan again!
what an incredible speaker!
This guy is full of nice horror stories, every minute of the video after 8" on is like "Yeah, we did that and it ended up horrible"
2:40 "whatever hurts if you get it wrong" .. nice :)
Not always, sometime we change very tiny but critical method of a one class in the system, and it hurts but it's not a part of the architecture.
RIP Stefan 😢
Really great talk! I really enjoyed the part where he took some small jabs at companies that see themselves as Netflix scale entities.
Decided to write their own encryption ... Still laughing over that one ... the fact that it is written in Borland C++ and has to run in a VM makes it all more hilarious ... Makes my various experiences seem not so bad ... I've seen lots of this kind of stuff over the years :-)
"So we decided to write our own crypto" should be words to strike terror in any software professional.
i kind of getting why you saying this, but i personally disagree. everything evolves. and evolution has neccesary branches which are destined to fail and go extinct. but every evolutionary step has the chance to grow into something bigger perhaps even a new standard.
if everyone would agree that we should only use ready made industry standard tools, we would still live in caves. that was the industry standard for humans. or just hunting and gathering... that was also the standard.
and even if it is certain that it is a dead end: coding it, designing it is an invaluable experience and knowledge to peek into how the others work on a fundamental level. which in turn will make you a better developer.
if they are keep forcing it / using it after it turned out to be a dead end and / or limiting the system (or risking secuirty/stability /etc) then we can start doing facepalms on JLP levels ... but not until that :)
@@mityaboy4639 The reason why you shouldn't roll your own crypto was stated in this same presentation: their crypto had errors and in the end was not secure at all.
So they ended maintaining legacy unworking crypto. Not very great situation.
They didn't write their own algorithm but instead implemented a known algorithm. Doing that does not take humanity any steps further but can take a company to a risk.
Well, AES extensions in CPU are built in for .... what, a decade? At least accelerators, and now perhaps even whole thing can be given to hardware....
In my last job they used an Excel sheet with vb macros for all the components they were producing in the factory part of the company. But if were not bad enough, this Excel sheet's macros were used to generate a database which was then used to generate another Excel sheet with macros which was then used to create the files used by our systems. Then there was another command line executable written in .NET CLI which was the most unclean copy pasted pile of code I've ever seen. Adding a functionality, or worse a new field, to this "DB manager" was seen as a punishment. They still have this technical debt monster running to this day, with various attempts to put all that crap into a nice DB shutdown by management because "we need to go fast no time for refactor that produces no client value" even if shit like these are the reasons we are going slower and slower.
I'm glad I quit, my mental health was going downhill each day.
I admit I fall into the same sort of anti-patterns that this discusses. But we do try to evolve to make sure that things will be able to adapt. The last two takeaways he discusses in 39:40 illustrate what I set up to do.
The evolution is still pretty rapid. Hopefully as we scale in number of developers, a few of us can formalize the architecture, but for now it's pretty much quick discussions during the sprint and planning for it in next and future sprints.
That being said having an end vision of what the architecture would sort of look like helps. I don't intend to copy Netflix, but having the idea of distributing the work/data into isolated instances for data capture and presentation but utilizing technologies such as Kafka to push into a federated store keeps back office analytics work separate from core applications.
Great talk. The issue with "everyone does architecture" while true in a sense, devs should be able to decide when it comes to implementation details, but if there is no dev looking at the big picture this also means that there is no consistent architecture, and your product looks like a design by committee. Yeah, better do those choices consciously. So I guess the thing is big A Architecture looking at the big picture should be more about application/services integration that anything else, and not as focused with intra-application, except when we do have real application layers (like front-end, back-end, db) specially when managed by different people, not just virtual ones (model, domain, application, etc), the latter which should be up to the devs maintaining them and freely refactor internally as needed as long as they keep talking to other applications, services and physically separate layers of the same application, as they were before.
And I fully agree you need to be a good dev to be an architect (even if it is someone that temporarily takes on that role) and that experience is what makes you able to not just apply something as cargo cult, and some times even overdoing it so wrong and misunderstanding Clean Code (or whatever you think you're applying) so deeply that there is no practical benefit from the way your software is laid out, it just looks enterprisey, costly to maintain, and everything is everywhere, but it has tons of interfaces and you see they used those standard magical names for their packages.
Fantastic talk, thanks!!!
Sharing responsibility over a single server between multiple teams does in deed sound like it breaks the idea of teamwork in general. The idea of distributing a single task across team boundaries is one of the anti-patterns for organizational efficiency even in management literature. I'm thinking of Fredmund Malik's books specifically here.
Many many thanks for this lecture, Stefan! All is so true... I think the main issue about not investing enough in Architecture is that people find it too abstract and/or boring.
Great presentation Stefan. These were very helpful insights.
He looks a bit like Computer scientist Dennis Ritchie, who drove the design of the C programming language and the UNIX operating system, who died in 2011
At 21:40, you share levels of abstraction (methods < modules < components < ...).
Depending on the technology context, do you agree that modules and components can abstract one another (above and/or below in the diagram)?
This talk would have been extremely beneficial for some managers at IBM I worked with about 3 or 4 years, where we had to turn a multi-million project's architecture around because ..... wait for ittt...... it was the WRONG THING. The cherry on top is that they tried to hide it from us and at the same time sugar coat their fuck-up to the client. I left that company not long after, too much toxicity and politics.
Great points made - many thanks :)
Wow!!! I love his voice!!!
thank you
Excellent session
34:09, is the vendor Deloitte?
What's the difference between a tech lead in a Scrum environment to an Architect?
it was a very valuable session
thanks!
Can anyone elaborate and help me on the 15:40?
I am not 100% sure but what I think he is suggesting is to split up (possibly even duplicate) the functionality from the orders module thus making each of the other modules independent.
Very nice talk and inspiration
One day this is going to be lennart, after years and years, he’ll come back as lennart the white and this is what he’ll be like!
All I am learning here is that architecture seems to be about making teams work, it doesn't seem to be about making software work, at all.
so... what are you suggesting is that the WordPress has the best possible architecture, huh?
Negan have come a long way
20:40 - Zalando
Architect 101
Me: "Can we X ?"
Architect: "No"
Me: "Why?"
Architect: "Because of security reasons"
Good speach!
For some reason, the speaker looks like Ryan Clarke (Hugh Laurie) from Avenue 5. Great talk.
You mean Hugh Laurie from "House", of course ;)
That's the click bait that brought me here
He's like the Donald Sutherland of software.
What you mean by 'like'? Isn't he Oddball himself ?! ;)
It's amazing how often architecture comes back to Conway's Law.
Trying to focus on the points and not his voice :d
35:00 MuleSoft? haahhaah
Mk.
This guy and Simon Brown… I can’t understand anything they say
"2 release a year, it's very modern, very agile", ....... what the f
its known as sarcasm
@@sirAlexander_T The best sarcasm is like some rando walking past you on the street and slashing you with a scalpel, and you walk another 3 km before realising that you're bleeding. That bit might be good for 5 km. 😀
oh yeah it's so sad there are more men architects than women. i'm literally crying.
Not a single word about architecture.
The title is kind of sarcastic and indirect. The whole video points to the idea that an architecture is 'alive' and never finished, the stakeholders should decide when it's enough. As Stefan said, if the system just works, nobody is interested in the architecture. If the system does not work over and over, the architecture is over-engineered and over-emphasized.
What were you hoping to see / hear @deasystems? Stefan starts with the definition of software architecture and then spends the entire video reviewing various architectures.
'Quibbles and tales of other companies trying out "code architecture"' is a bit clunky and not clickbait, but it fits...
huh? Did we watch the same video?
@@OutdoorsWithChad yeah I was waiting for tips on what cement to best use for support columns, but all this guy talked about was computer program coding or some such nerd thing
/s
The thoughtful friday concretely sniff because partridge adversely cause amongst a astonishing forehead. majestic, drab bottle
this talk was wayyy too abstract for me to have any meaningful take-aways. Don’t waste your time on this one.
It was quite informative. I'd suggest people give it a try.
Not for me and some commenters.
Much of what this gentleman says about architecture is demonstrably false.
When did software engineering started being a talk-only endeavor? Boring!