How to "think" (and design) like a Software Architect at Silicon Valley Code Camp 2019
Vložit
- čas přidán 26. 07. 2024
- Check out Ron's latest video from Nov 2023. • How to Think Like an A...
Ron Kleinman Talks about 'How to "think" (and design) like a Software Architect' at SiliconValley-CodeCamp.com in San Jose
Software Architects design solutions for complex back office enterprise applications by identifying the basic abstractions. Attendees will use their techniques to interactively develop the high level design for such an application.
SiliconValley-CodeCamp.com/Se...
Silicon Valley Code Camp site:
SiliconValley-CodeCamp.com
Subscribe to the Silicon Valley Code Camp CZcams Channel
/ siliconvalleycodecampv...
Follow Silicon Valley Code Camp on Twitter: / sv_code_camp
Join the Silicon Valley Code Camp G+ community: plus.google.com/1106563518427...
How to "think" (and design) like a Software Architect at Silicon Valley Code Camp 2019
Follow Ron Kleinman
Speaker Biography for Ron Kleinman
Ron most recently served as CTO of the SIF Association, an XML standard organization in the K-12 area. A 20 year veteran of Sun Microsystems, he co-founded the JavaPOS initiative, and has taught an evening section of Object Oriented Analysis and Design at De Anza College for the last 10 years, is the somewhat sheepish holder of several software patents and has been keynote speaker at multiple partner conferences and selected industry events. His current technology focus is on design patterns and application (rather than module) integration.
Watching this man speak is so revealing. You can tell he's so experienced and knowledgeable he has to stop himself from going WAAYYYY off-topic many times. This guy could talk about these topics for days.
Loved this lecture. It's refreshing to find an informative and humorous lecture
Loved the classic jokes lmao. I'm stealing the one about the research scientist. Learning from someone who has such long-standing experience, rooted in the evolution of the industry, always feels like striking gold. I appreciate this talk very much, thank you
Don't go into these talks uncritically. Yes, the speakers may have loads of experience. The key factors, however, are applicability and accuracy. There's a lot to be said for sketching out the design of the application, but when the rubber hits the road (or the programmer fingers hit the keyboard, as it were 😉) you WILL run into unforeseen things. The greater the scope, the greater the rate.
But am I saying "don't plan anything" or "don't listen to this guy"? Not at all. Do plan things, do listen to this guy... on the proviso that it works better for you than starting with an ad hoc test application does. No matter your approach, you will have to tackle mostly the same issues. Issues unique to each approach will also arise, and you will have to tackle those too as you go.
The bottom line is that there is not a one size fits all approach, just like in any other aspect of our lives. So for (probably) younger devs coming in here looking to learn... do learn! But also evaluate what works for you, and keep learning!
Hah, how about that 48:00 "getCum()"... classic!
I learned more about architecting a solution from Ron's presentation than from all the other books I've read on the subject. Because Ron really taught the analysis process and "how to think" whereas the books just presented the solution. Thank you, Ron!
Design Patterns are reusing other's thinking - loved that ❤
Right? What a beautiful and concise description.
More like reusing defined solutions to defined problems
This is a great lecture! Glad I found this gem
Knowledge should be free for all. And this session serves that purpose. Mr. Ron Kleinman is my hero!
It can't ever be free. You need to at least spend your time acquiring it.
So the knowledge you have, you give for free? Do you not demand a salary for putting your knowledge to good use?
Perhaps you meant education should be free? Free for the student, but subsidized? Experts should give their time, voluntarily? Free in what way and how?
I do like the old means of training that companies were expected to do. A company that was setting itself up in a given town would create its own school. Making students pay to attend was nonsensical and counterproductive, and job availability was a given.
This mentality is why teachers in America are starving. Knowledge should be easily accessible but not free. Knowledge has a lot of value.
@@phyzix_phyzix That's just silly. Information is not some kind of limited good to be hoarded. Teachers are not "starving" because of information being under priced; libraries have been around for half an eternity... people on average simply don't seek out information. The problem in your society is that teaching is undervalued and... well, a great number of things just don't line up. Look at any other western society, see what their schools are like and ask yourself "do they have access to less information?"
I'll put it to you that higher education in America is more expensive than anywhere else. And I'll ask you... does this, on average, bear out in the results?
It is great knowledgeable lecture with wonderful connects with attendees. Thanks for great OOA topic coverage.
Thoroughly enjoyed every minute of this, great presentation and jokes as well!
Amazing. Thank you for this!
I'm a business analyst and this is kind of like exactly how we design software too
Thanks for sharing ! It's very useful.
This guy is soo funny, hahah what an insightful and entertaining seminar
Excellent , Thank you so much sir
Great presentation. Thanks.
wow. this speech was greatiful
Great talk
Wonderful!
so nice, thanks a lot
Fantastic presentation
10:20 I needed this
Nice!
I want part 2 of this, please... I am ready to pay for this also.
I like your sense of humour ♥
Amazing 🎉
This ways of architecting a system is unfortunately misleading, expensive and inefficient, we typically call this approach BDUF (Big Design Up Front). We tend to avoid working in this way nowadays, because building a software is not like building a house or a bridge, is not done in phases, instead is an iterative and incremental process, so we want to start with "just enough" analysis/research/design, after all understanding the domain is something that requires iterations and feedback. Obviously it makes sense to get a "rough" idea of what the problem domain entails at the very beginning, but you wouldn't go as far as define the attributes/properties and so on, you just need the big picture. Details would come up incrementally while working/implementing each iteration of the system, one use case at the time, better if the increments are defined as user need/problem that needs solving. Every release we would learn a bit more about the solution effectiveness and bit more about the domain, so the shorter is the release cycle the more opportunities for us to integrate the learnings into the software architecture and design.
I am totally agree, he is explaining this concepts in the old way to develop app, classic cascade approach. Nowadays, we are able to iterate and split the problem in small chunks and thanks to it, we can create better solutions. In addition, as an arquitect you need only to define the big picture and its stack.
Thank you for this lecture, i can finally become a comedian
It's baffling for me that in the US there are software architects who do not know how to code.
I got a friend with multiple certifications reaching the Solution Software Architecture one for AWS, he had a MBA in Digital Transformation he is 38 years old he has never worked or code for software development, he has been studying his whole life, he is not planning on ever working or doing anything with his knowledge, I love learning but I have to use my knowledge I must build stuff
It's people like you that start wars.
Pretty common in Germany too.
Not here in Silicon Valley
Great
nice tutorial
1:20 this joke killed me 😂😂😂
What killed me was the getCum () function 😂😂😂😂
Amazing talk! Can't believe it's available for free.
Decompose the system using OOP and OOD very basic principles: objects and interfaces. That's what I heard from glancing this one hour lecture.
I see tons of comments from fascinated people. Are they students who missed the very basics or I am missing something from this lecture?
I’m 15 Minutes in and it seem you’re right. If you had an OOD class this is nothing new. Design patterns, UML diagrams. This is like a flashback to the early 2000s. It’s a pre-agile view of the world. Today you would just bang out a prototype and iterate from there. People realized that programming is the only way to think about a software problem in detail.
@@fluffyunicorn7155 , even working in Agile frameworks I am pretty fine with UML, diagrams and high-level architecture documentation to share knowledge fast and discuss overall approach and ideas on large-scale projects (hundreds and thousands man-years, many groups, etc.). So, I wouldn't consider this totally outdated. I am just curious, what is the value of such a lection for mature people in the auditory and why people here are so excited. Maybe we still missing something they applaud for.
I expected to hear something practical and new from such experienced person.
I really love architect lectures from O'Relly much more.
so brief video for architecture.
How to "think" (and design) like a Software Architect - explaining how to solve many-to-many relationships. Who doesn't know that needs to go to a basic database class but it shouldn't be discussed in an architect class.
oh malloc - lols.. awesome
Malik
Thank you for your lecture, it is very useful!!! In what moment in time should I decide the architecture to use: layered, microservices, monolithic, micro kernel? and what diagram should I use to describe that? Also when should I start to design the visual pages, like in Figma, these diagrams are too abstract. Also in what diagrams can I put the borders between front-end and back-end, I’ve seen examples when this isn’t portrayed and will be confusing to developers, like in sequence diagrams, it starts with the actor clicking a button and doing something up till the database, but it doesn’t show the borders between UI, app layer, logic layer and database layer, how can a developer know how to organize their code? Still a sequence diagram doesn’t show what fields or tables will be affected, so where do I put all the details. I’m trying to use UML but is too abstract and not enough detailed for a developer, it’s too general, like the Use Case diagrams. Any help? Thanks.
You need to layer diagrams with next layer of diagrams showing the details of the previous layer. Look up C4 model, it does exactly that.
9:42 But, a few months of coding can save entire WEEKS of planning!
Takeaway is: words need to connect back to its context for relevant metadata
Components need context- how should it respond, and behavior in its state machine diagram
C++ are just hacks to overcome language design problems
Avoiding design patterns is now the goal, except for a few exceptions which are not tied to C++ implementations (or JavaScript)
took 41:17 to build a functional spec.
IMHO not all projects may need a traditional approach, code first is been in practice for sometime, it depends on who is writing the code
The guy sounds like the actor evil lawyer Chuck on Better Call Saul
44:15 bruh 💀
The more I listened, the more confident I became that the software architect is redundant, just like the president we have
Very interesting but please repeat the audiance questions, thanks.
At 16:00 is it a Section or a Session?
Holy crap this is a content gold mine! It's so nice to not have to straw-man people who still believe these things. Definitely bookmarking this. In case any new programmers are watching this, this is a complete joke, for entertainment purposes only. The only reason people can get away with this king of nonsense is by implementing systems that are trivial to begin with.
EDIT:
44:40: How did this make it past the slide review committee? That gave me a good laugh.
What way if breaking down the problem and designing a system architecture do you prefer instead? Was hoping your channel would have some examples but I did not see any there.
@@williamestey7294 Yeah sorry about that. Unfortunately, I'm not very industrious, so making videos is still a ways out. I have been working on some articles instead, but nothing finished. I do feel bad about not having anything put together for people. What I can point you to is content produced by Casey Muratori. He's a bit disagreeable and overstates things, but a lot of what he says about architecture is close to what I believe. Thanks for the motivation to actually finish some stuff though.
still dont understand what a SA does other than draw pictures for the interns who already had to know full stack system design
So sftware architecture is oop?
Enterprise Architecture using togaf is required for software architect?
At least the Soviets joked about themselves. You're not there yet.
Like your comment that if you are a software architect and have never programmed then you are like a priest at a wedding!
I would like to be a software architect, but I'm at intermediate level help me please
Good software architects should also know systems/OS level well. Most software developer do not care much about servers and systems administration and easily create huge mess (poor manageability, too much complexity, security risks and so on) in that area when they need to "design" something at that level.
You can't design good software system without good system architecture/administration skills/knowledge.
It is not an architecture - it is an engineering job. Architect works with non-functional requirements. Basically what is done here - he is doing coding without coding.
Are we writing the solution for a single user to operate. All this data is loaded into the system only one user can use it at a time. Is that what we are doing. The solution is in Relational database. It can be written in modern SQL language without any thought to the programming language, or the Written Language ( English or Chines).
so you design the Relational Database with the rules and Stored procedures which implement it. Then you can write any number of front ends
oh no, anything but not the stored procedures please
28:21
Actually, in reality we don't always need the relationship table, because at certain time, a student can't have very many courses, and a course won't have too many students, which means we can just put the information in both student and course, it is a duplicate of data, but might worth it.
so this video is from 99?
I feel this is a little over-engineered. It seems to me that the first step is to identify the scope of the problem. What parts of this problem have already been solved? Perhaps they already have a scheduling system and we just need to 'drive it' to find free times for classrooms, teachers, and students, then update it. Perhaps they already have a table that records what students are enrolled, etc.
It seems to me that in determining scope, we have to make note of what our assumptions are so we know what problems need to be solved and which don't. With the right interfaces this whole application could be a small set of queries and we can forget about using 'classes' to model things.
He's trying to teach you how to think when designing a system's archetecture, not literally design a college enrollment system.
Queries on some data can replace 99% of all software ever built. That doesn't mean they should-- he is teaching OO design here
@@unitydev457 But aren't people learning the wrong thing? This is how we end up with bloated, over-engineered "frameworks".
@@unitydev457 I agree with you - as long as we recognize that we are cleaning up messes. This is a legacy design and it's a bad habit to think like this when coming up with new solutions. I could say that this app described is mainly just making queries and updates - which is to say - sending well defined messages between well defined component boundaries. I believe this is what Alan Kay had in mind when he coined the phrase "object oriented programming". By focusing on the messages we think more as system architects should - how to make simple independent agents interact together to create custom behavior. Just imagine - most of the complex software in the future will include components whose developers never know each other and never communicate, except through an established protocol or schema.
Thank you for your comments through. We do have a lot of technical debt to dig through. I just don't want people to get the wrong model in their heads and make more of it.
45:00 ...
I see what you did there 😂
44:17 im sorry but what???????
How can i get the materials of this course ?
.
Would have been a better talk w/o the crowd interrupting.
🎯 Key Takeaways for quick navigation:
00:20 👨🏫 如果你是个没有编程经验的软件架构师,就像一个没有经历婚礼就主持婚礼的牧师一样。
01:18 🛡️ 设计模式可以让你重用其他人的思考,就像科学家站在前人的肩膀上一样。
03:37 💼 软件架构师需要为特定行业工作,比如零售业、教育行业等,行业之间有很大区别。
05:30 🏛️ 三层架构把前端用户界面、业务逻辑和数据存储分离开来,适合企业级应用。
06:54 🏭 零售业软件架构复杂,需要处理销售、库存、定价、优惠等多个子系统。
08:18 🎓 教育和医疗保健行业的用户更积极主动,会分享好的解决方案。
09:26 👩💻 成为软件架构师的路径是先学编程,了解设计模式,然后专攻一个行业。
10:52 🎯 选择一个行业,在该行业中积累经验,逐步成为软件架构师。
Made with HARPA AI
4 architects suck at programming
just no, this how you take years to come to market and by the time you ship your system is outdate junk
hrm. don't architects just namedrop tech without knowing how to use them? i'm guessing this is more than 60% of "architects" who hold that title.
He mixes up problem that software architects solve with problems that developers solve.
What the heck? A software architect who doesnt know how to program?
Similar to a Math professor who cant do Algebra 🤣
I watched 16 minutes and I not learned nothing. all bla bla and blaaaa
Wow is this outdated
If you were to do this today, how would you change it? (or what would you cover with this topic for a new presentation?)
seems boring, sorry. This is basically what i learned at university.
It was actually Pascal that did the STRUCT thing before C with "RECORD". Today DELPHI continues that!!!!!!!!!!!!!!!!
Glad I found this gem