This was an intriguing watch, thank you very much. I ordered a couple of these books that were missing from my shelf while watching (I will have to put another one up now!) and interestingly your book on Just Enough Software Architecture is already on its way to me. I have many years of experience as a software developer and a handful as a software architect (ranging from technical to enterprise solutions) and I've read a LOT of books, so I am excited to read yours and I'll be sure to let you know what I think!
You've outined why you would write contracts and a lot of examples with guide rails etc. I would imagine that a big project in a language without contract support would need some kind of automated system to check coverage of contracts on the code. Any ideas or pointers on a standardized and parseable syntax for the comments to write the contracts in? What about stealing some of the syntax from a language with contracts like D, Ada, or even the C++ proposal for contracts?
In my experience, the big improvement for a team is going from treating methods/procedures/functions as a convenient named group of code to treating them as little bits of machinery that are expected to work in a certain way (ie according to the contract). A team that thinks this way can use the tools they have to manage the contracts -- things like their own brains and simple unit tests. It's not that tooling is a bad idea -- far from it -- it's that lack of tooling shouldn't discourage a team from trying contracts. And adding machine-checkable contracts is yet another hurdle to convince your co-workers about.
@@georgehfairbanks I just worry without some "contract" (haha) that's enforcing it to some degree I'll just get soft buy in no one will actually do them without constant work of the adopters going over everything. I.e. the same problems with code comments in general since they are out of date and with no real quality checks.
Try Keeling's essay on ADR adoption. www.agilealliance.org/resources/experience-reports/distribute-design-authority-with-architecture-decision-records/. The critical thing is to get the team thinking about design, thinking of themselves as designers. No static analysis can force them to write good contracts.
Hi George, Thanks for this highly informative session! What do you think of the following design focused iteration algorithm? This is an attempt at creating a variation on the TDD work flow: Red: design & specify the outsider view of an API (includes designing the domain model) Green: design & implement the insider view of the API (includes designing the static run time structure ie: the object role interactions in DCI parlance) Refactor: tinker & optimise the API
This really helped put into context why I have been feeling like so many things in my software architecture course seem like the same thing but with a different definition. I am quite a black-and-white thinker which has not served me well in learning these concepts, but your conversation managed to explain it in a way that made sense. Thank you for posting!
Oh boy, Representational State Transfer (REST) is something that everyone can disagree about. I can't think of a simple answer to your question. I would recommend reading Roy Fielding's thesis on REST to learn more. www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
Hi George, is theory know how or know that? I think Naur tries to say it's know how but some of his consequences seem to suggest that he thinks it's both.
He seems to say it's know-how. Perhaps know-how subsumes know-that, so anyone who has the theory also has know-that. In practice I don't think that's always true -- there are always pedants who seem to have memorized the dictionary or grammar rules but can't write a paragraph of decent text.
@@georgehfairbanks I agree that it's ultimately know how he's trying to get at. But I think it's probably a misnomer to refer to it as theory. Ryle doesn't mean know how by theory, he saves that for the phrase 'having a theory' in Concept of Mind.
@@georgehfairbanks A side-note. Aristotle described theorizing somewhat along the lines of the right knowledge at the right time. For example someone may know all the "theory"(as it is nowadays called) about military tactics, but not have a clue how to lead a fight. Or one could recite all the text of a math textbook but not be able to solve an equation. Such persons he described as possessing episteme. It is knowing without necessarily knowing when and what to apply. A person who has theoria is one who knows precisely that. It is someone who can recognize what is important to a situation and give the right solution.
Dear Friends, When I design a software system, I divide it into 3 categories: 1/ Conceptual: I will state the names of the software that will respond to the requirements of the business process from users, describe the names of the software to be processed and the behaviors. 2/ Logical: I can define software architecture by applying architectural pattern in this step and I will include constraints on availability, scalability, maintainability. I also describe in detail the function of each component. This step 3/ Physical: Define programming language, platform to realize the description in Logical step. Could you recommend?. Thank you.
I have read Peter Naur's paper now. This was a really good hint! Thank you! I wholeheartedly agree with that "Theory Building View" of programming. I wrote "BINGO!" besides the following paragraph: "In preference to program revival, the Theory Building View suggests, the existing program text should be discarded and the new-formed programmer team should be given the opportunity to solve the given problem afresh." (Peter Naur, Programming as Theory Building) I have seen more than once old dirty code with low level of abstraction (if - else if - else if - ... over hundreds of lines), global variables, code duplication (payed by number of lines?) and so on. And some years ago I saw one company that tried refactoring (realtime C-Code) for more than a year... and then decided to write this shit anew, and after roughly half a year, the basic functionality was recreated in a nicely structured, clean way. So: rewrite from scratch can be helpful, if the legacy mess is just too big. (Peter Naur would have proposed it from the beginning, as the above quote shows.) (I also experienced this by myself, rewriting code as a sinlge devloper in some months, what a team has written over some years. The problem is only: nobody believes you.) But the consultant industry earns more money when they do sell their refactoring (plus courses and books), which can go for a long time.... ...and maybe additionally they just had the luck that the mess they were confronted with was not that ugly as what my eyes have seen? Btw: since some weeks, my screen background shows the following quote: "Testing numbs us to our loss of reasoning" (George Fairbanks) I could write more about that testing issue, but it's a different topic, so I stop here.
It's a shame that the RU-vid algorithms keep recommending me all kinds of videos that teach programming for newcomers that end up having hundreds of thousands of views, yet it fails to push amazing content for more seasoned developers, like this video. Thank you for sharing your knowledge!
@@georgehfairbanks I watched one video only in the playlist, now I will watch it all. Only one video? I thought you can teach me more, :) thanks for the videos. I just followed you on Twitter. so you work in google that's cool.
@@therocketmanprince682 If you've got specific questions or topics you'd like to hear about, please let me know. It helps to hear what people are wondering about.
How do the skills behind making contracts scale? If I have system 1 mastery of contracts in small projects does that generalize well to big projects? I ask because as a student/early career intern most of my code is small self contained projects with little to no outside interaction. This makes me wonder if mastery of contracts on this smaller level translates well to larger scale projects. P.S thanks for these talks, its really cool that you spent this much time and effort on them and I appreciate it
There's a big mental shift when you go from being able to think only procedurally to being able to choose between logical and procedural thinking. That's a big leap. Once you are in the land of logical reasoning, yes, it scales up quite well. (I should note that in this lecture, the point I'm making is that, with experience, you can become really fast at logical reasoning. Scaling up to big software projects is covered in the Bridging Logical and Procedural Thinking lecture). When you master contracts on small projects, you will be able to apply that skill on larger projects. But: logical thinking is not the only skill that helps you with big projects. Abstraction is the primary way to deal with scale. Logical thinking is a kind of abstraction, but there's also abstract datatypes, patterns, architecture, and much more. Software design is a deep and fulfilling career because the intellectual challenges are so great. You can spend your whole lifetime learning and improving.
Thank you, very good show. It might be that we who has some years of work experience fascinates about about this talk, hope the students got the message. Try working as an architect in a rather large automotive company for the complete set of "embedded" software I quite often do similar internal presentations because architecting and architecture maturity is surprisingly low.
I am an architect as building construction. I would like to be a software architecture. How can ı do this. I dont know where ı should began this. Could you give me some advice?
I'm a software engineer, not a software architect. Maybe there are ways to go directly into software architect but I imagine you would first need to become a software engineer and work your way up. So assuming that's true, you have two spectrums to consider: time and money. You have to spend 1,000 - 2,000 hours of study to become a web developer. It's probably very similar for other platforms (desktop developer, mobile developer, etc), but I don't have experience with that so I can't say that I know that. The variance in hours depends on how quickly you learn and how densely you study, by which I mean 1,000 hours over 3 months is probably better than 1,000 hours over 3 years. So if you can't cram it all into 3 - 6 months, then you may need more total hours, but this is just my conjecture. If you are self-motivated and know how to study, you can do all of this for free. Or if you need the external motivation or the study help, you can pay. You can do anything from a coding "boot camp" on the complicated, expensive end to a self-directed study course where you occasionally pay mentors to help you out, and anything in between. As far as becoming employable, it doesn't matter to most companies whether you have a degree or not, whether you are self-taught or not. For an architect such as yourself, it may be difficult to believe that a company would hire you as a software engineer after 3-6 months of diligent self-study, but it's true. I suggest you start here booksoncode.com/articles/learning-code-for-free, and also check out www.cscareerhackers.org. These two resources contain everything you need to go from zero to employable.
This is excellent explanation of software architecture. I like you very much that the way you explained and your body languages is simply awesome. I love to copy your style. :)
This is not correct. Software Architecture is more than just high level risk mitigation. A software architect gathers requirements and analyzes a potential system to determine how it should be decomposed to minimize risk business, and software risk, maximize reuse and minimize dependencies between various components of a system. Good software architects will lay out the initial design and educate others on the design throughout the project lifespan, while letting others design within their system. Architects are the technical manager responsible for the quality of the code produced within their system.
That is a reasonable job description for a software architect. It's helpful to distinguish the role, the process, and the engineering artifact: architects architecting architectures. See chapter 1 section 5 of my book, which is available on rhinoresearch.com.
Relevant -- absolutely. The abstractions of software design evolve slowly. I'm not aware of any point where we decided old abstractions and ideas were bad, but instead we added nuance to them or added new ideas. For example, there's a lot of work now on getting DevOps right, and in particular writing code to automate deployment. That's fully consistent with there being three primary viewtypes (module, runtime, and allocation) and it actually makes the allocation viewtype (that is, what code is running on what hardware) much more visible to developers. In the old days, it was somebody's job to manually log into a server and update software or DB schemas. Now we automate that, so you don't have to go over to someone's desk to ask what version of the DB is running in production. But thank you for the suggestion. My pile of software architecture books has grown, so I'll try to get around to a video that puts them in context.
That's a great lecture George, lots of value. I'm trying to get a grip on things in coding. In that light, would you approach a platform like Salesforce as a software or website? TIA
This is sad, if implementors are so full of themselves that they make up their own rationale, perhaps you just have to let them wallow in their anti-patterns.
I run Linux,my life sucks, A+ failed my network+ 2 years of computer information systems wgole community hates me,becuase they think I'm talking down to them..got any advice, btw still can't type. oh I play TW2...help me!
