If you're interested in more of my talks, take a look at martinfowler.com/videos.html
@cejodrake9 жыл бұрын
Martin Fowler EXCELENTE
@renounhinged3 жыл бұрын
Molly did very well, people here who are critiquing her confidence never spoke on a stage lol
@TobiasTheInvincible3 жыл бұрын
Views on the architecture definition to consider, where Martin relates the definition of architecture from construction translates to UI rather than the more complete software use of architecture. A construction architect defines what the house looks like, what the function is of each area, how you join up functional space in a house, to give an idea of what the house will look like, what you get in each room, what each room is designed to do. They need to consider plumbing, wiring and where it makes sense to within the functional space. The translation in software architecture is quite easy to relate to this definition. I may have a set of applications that represent rooms with functional behaviour. As an architect we look at how do I connect those applications (rooms), how do we ensure that I provide enough space for an application (size of the room) etc, how do I ensure that electricity can propagate through the house, or heat, which could be synonymous with integration for example.
@v01d117 жыл бұрын
Molly, if you are in danger, just blink twice!!
@HolographicKode5 жыл бұрын
Funny. I had the same impression she was a bit stressed (stage fright?)... or maybe just recovering from a hangover after Paddy day :)
@alfreddorkalam59546 жыл бұрын
What if over time the people of the team completely change? The average tenure of a CIO is 4.6 years and a team member close to 2.5 to 2.8 years. This means the shared understanding is constantly changing as do the people. Perhaps there is some value to have some documentation even if it is close to the code.
@stuziocycling8 жыл бұрын
I think of software architecture as that which is common across the whole solution and stand the test of time. Everyone desires everything to be easy to change but in some cases especially in a large enterprise, the "architecture" design/decision is not easy to change. For example, if an "architecture" decision was made to go with a particular vendor or platform and people/team who made that decision didn't think through all the important use cases, it could really suck later. What is the "agile" approach to such projects? In my experience, these type of "architecture" decision requires a lot of forward thinking and is not practical to say just "remove" the architecture (i.e. things that are hard to change). Thanks and enjoyed the video.
@karthikrangaraju94216 жыл бұрын
Disagree with the DB schema is no more a "hard to change" problem. The real pain is in the application code, the ORM mappings that gets you into a rabbit hole trying to fix all compilation errors, fix functionality etc. Could apply for minor schema changes like adding a column, otherwise, schema has to be thought through before anything else. Which doesn't really fit in agile model. Could see the argument for schemaless DBs though. But even there, you'd have to worry about backward and forward compatibility.
@saa4428 жыл бұрын
Can we have good design with zero documentation ? I'm very curious to know to how to do that. And what dos it mean by that. And how to keep a communication medium in team.
@BenjaminCronce5 жыл бұрын
The only thing better than changing code is proper factoring in your design that separates intrinsic requirements from arbitrary requirements, allowing you to extend instead of change. I guess I'm used to writing code that's used 10 years later, but has been extended to handle many new requirements, fundamentally handling the same abstract concept. Sometimes needs an uplift, but nothing major.
@MohammadRauf17 жыл бұрын
don't know why they going back and forth ... hard to follow ... they shoulda just split the presentation up. A very non-agile presentation!
@BryonLape8 жыл бұрын
Agility without SOLID is a pure mess.
@tannerjarrell1792 жыл бұрын
My professor is making me watch this as part of an exam, anyone got a cliffnotes version?
@mvargasmoran7 жыл бұрын
I think I got nothing from this talk. just a lot of buzzword, maybe the term is already devoid of meaning. Guess I rewatch later.
@BryonLape8 жыл бұрын
Molly seems very, very nervous.
@mystictm39657 жыл бұрын
This sometimes happens when one is trying to talk about something one doesn't know anything about ...
@oreilly9 жыл бұрын
Enjoyed this talk? Watch our interview with Molly Dishman, and browse other keynotes and interviews from the O'Reilly Software Architecture Conference: kzbin.info/www/bejne/mX-sh4OpgZeDg9U
@markcollinscope7 жыл бұрын
IMHO Martin appears somewhat arrogant, and Molly appears somewhat in awe. Molly was great, to be honest and she did a good job. Martin needs to learn some humility and how to not try to grab the limelight all the time, and to promote his co-speaker. It is not all about 'self'-egrandisment, we can help other talented people too! And we should.
@BlackShampoo755 жыл бұрын
This is just awkward.. I love how Martin slowly moved further away
@rahulparakkat9293 Жыл бұрын
Martin Fowler - "In bigger companies, Architects seems to be more divorced from the reality of software development on a day to day basis". No better way to put it.
@oneomself2 жыл бұрын
why is drawing an architecture diagram not considered real work but writing code??? Having done programming for 20 years and having grown into an architect, that sounds absurd!
@SemiMono6 жыл бұрын
"One of the core drivers of complexity is irreversibility" Bingo. What is a work around, after all? Why do all of the big companies avoid using ANY closed source software?
@alfreddorkalam59546 жыл бұрын
In the physical world the architect deals with design and flow, the plans for the build, the regulators to Get permits and the customer to get requirements They do document their plans and designs they sign all the permit applications and they consider the flow of people in the space vs the intended requirements. Why would this be different in software? Software architecture which is just a title and not profession (any one can call themselves an architect and there is no regulatory body or pre qualification) needs to grow up. Where I work we stick developers that are older and mature in enterprise architecture cause they lacked the social skills and people skills to manage large teams (through choice or force) and the smart developers that can influence others to be solution architects or principle engineers. Martin seems like the first type to me except he has the incredible talent to know how to captivate a crowd
@gordonfreemanq6 жыл бұрын
because software is fluid and is meant to easily be changed, whereas a concrete superstructure cannot. Ivory tower architects will dream up the perfectly modeled system how they think it should exist, but will undoubtedly fail to account for new requirements that will appear later in the process. When these requirements inevitably appear, the teams as a cohesive unit needs to be able to rapidly respond to them. This often involves deviating from the predefined architecture, and ivory tower architects will often times not appreciate the real challenges faced by the developers and resist necessary changes.
@Irshu9 жыл бұрын
very good talk. gave me a foundation on where to start. I've been a developer in my company for 3 years, now my boss pushing me to become an architect, do less coding and manage the group of developers. i didnt even know what actually an architect do until i watch this,haha
@ManjunathBhatManjunathBhat7 жыл бұрын
Be wary of boss-speak. An architect doesnt need to manage anybody. Just be careful in another 3 years, they dont say "Well, it was nice knowing you. We assess our business regularly and re-prioritize the need for resources"
@badhombre49425 жыл бұрын
The problem with Software Architecture is that it is the domain of the most incompetent in the industry. Architecture is about form and function and is indeed cast in stone. Therefore, there can be no such thing as Agile Architecture.
@feastures9 жыл бұрын
Is she in love with him, or what's going on?
@trollhelps9 жыл бұрын
feastures She looks seriously nervous
@meiogordo9 жыл бұрын
Chris Developer feminine attire looks good but does not enable breathing properly
@FrankKrasicki9 жыл бұрын
+feastures I personally think she's tap dancing around the fact that she thinks he's wrong but he's the boss. She makes more sense than he does.
@lxathu9 жыл бұрын
+Rui Aguiar Darth Vader breathes more easily but he's not this attractive... although as a commander, he at least follows some of the agile principles.
@pmarreck8 жыл бұрын
+feastures The day after St. Patricks' Day in Boston? That is a GIGANTIC holiday in Boston. That's gotta be a hangover
@rockerirwin5 жыл бұрын
really hard to follow because of the back and forth. molly is under extreme stress. dont make her do this again guys, let her breath
@BryonLape8 жыл бұрын
Does anyone else think Molly looks a bit like Ronda Rousey?
@jaapbadlands7 жыл бұрын
Similar voice too
@MrBiggcat8 жыл бұрын
incoherent gobbledygook. This reason for architecture is to get out in front of coding so you can discover and correct design problems when you can do so quickly and cheaply. The goal is to fix architectural issues before they become hard and costly to change so you don't need to have 20 $100.00 an hr developers in a "mob refactoring" session to fix a blistering mess.
@MrBiggcat8 жыл бұрын
The whole reason for architecture is not documentation. It's to build a model so that you ensure the code will not require constant refactoring. We should strive to get software right the first time.
@gordonfreemanq6 жыл бұрын
@@MrBiggcat sure, but how often have you worked on a project where the end result matched all the fancy diagrams at the beginning? A basic system level view can be useful, bit anything more specific than that becomes an exercise in futility unless there's actual code backing it up. The truth is that it is extraordinarily difficult to anticipate all the software use cases ahead of time, and the most well put together uml diagram might crumble like a house of cards once the rubber hits the road.
@lindalauer14342 жыл бұрын
.Interesting
@Jimtheprogrammer4 жыл бұрын
This is the most confusing speech I have ever heard from Fowler of whom I am a big fan. I have been talking agile architecture so I was hoping this video was in support of the same concept. To me, I would have thought it was architecture that support agility such as Domain Driven Programming or proper Micro-services. This means that we can write every thing encapsulated but not only that. It allows for reversing the decisions and complete rewrites of areas with 0% impact on the system as a whole. In my last application I designed as the architect, I did watch the code and cared about the the methods the developers accomplished their tasks but on the other hand, they would not break the system and it priorities could switch and it would cause no slowdown at all. I am disappointed that agile architecture was describe as so process driven when it should be a highly technical way to enable extremely agile development by eliminating the drawbacks associated with Agile development. I wanted to use that term in the future but now it has been defined by Martin Fowler is yet another process thing.
@bryanedds89227 жыл бұрын
Object-orientation is a failed paradigm, and agile is the scabbed-over bandage that keeps the patient from bleeding out entirely. Don't get me wrong, objects / interfaces can be great, such as when you need to build pluggable systems. But as your first choice for modeling a program, OOP carries in so much unnecessary complexity (mostly via mutation) that you'll never hope to get anything right the first time. Or the second. Or the third. Instead of admitting the failure of their programming paradigm, the OO 'sages' invented a methodology that punts on all of the problems that come out of it. Is your team bogged down because your system has become so complex that no one can figure out a coherent way forward? Get rid of code ownership so that any system invariant can be bulldozed in the name of short-term progress. Can't figure out how to design an OO system without falling into analysis paralysis? Skip the whole fucking design phase entirely and make it all up as you go along. We now know that around 90% of our systems can be built with significantly simpler and more lego-like (composable) pieces using functional programming. In the fewer cases where performance is top priority, we know that we can get the best performance by skipping the OO middleman entirely and going straight to data-orientation. Performant and well engineered systems tends to use both approaches in tandem. This whole agile methodology is the result of OO taken to its incoherent and pathological extreme. Throw that shit out of a moving bus, and learn to use mathematics like basic data abstraction and abstract algebra to solves your design problems.
@randomthoughts287 жыл бұрын
You have no idea of what you are talking about. And you are definitely too young to. Come back in 20 years, after you have implemented a few 10M LOC or larger enterprise systems. Newcomers to development these days toy around with toy projects and rubbish little startups with their "apps" and trinkets, and have never seen what a real software development project looks like. Yet, of course, all Dunning-Kruger-ed as they are, they fanatically espouse the first fad they encounter, which has probably existed since before they were born, like functional programming, and they think they are now messiahs. You confuse the very large subject of OOD&P with objects/interfaces. Cute, but this betrays the fact that you have a lot of soup to eat, and a lot of work to do and books to read, before you can talk about software engineering. Trying to implement any complex enough system without first pausing for some larger thinking of how its components interplay and fit together is guaranteed to fail. Notice I didn't even say software. This is true for all systems: building construction, mechanical engineering, etc.. You don't substantiate the claim that OO is a failed programming paradigm in any way. All the while probably writing on a browser built with OO, on an operating system written with OO. All the while the TIOBE sees no functional languages before the 25/30th position. At usages of a fractions of a percent. Functional programming has its uses, but they are niche uses. Smallish systems with little or no i/o and external components. Outside of mathematical applications and programming courses, there are very few systems like that. Fanatics of all sorts are very vocal, and very sure they are anointed. They are also usually very wrong.
@BenjaminCronce5 жыл бұрын
You say functional programming is more composable, but experienced OO programmers can reuse code 2x more often than experienced functional programmers.
@SaudBako Жыл бұрын
Martin Fowler? RUUUN!
@ivanzaytsev49245 жыл бұрын
wow, literally 30 minutes of buzzwords
@FrankKrasicki9 жыл бұрын
Thoughtworks has been slandering Software Architects and misrepresenting Architecture for years and the get-out-of-accountability card that they have successfully cashed in on has been the Agile gobbledygook. Like the child who finds a hammer, everything looks like a nail and so Agile has become a hammer for far too many of these zealots to perpetuate their false propositions. This talk is as bizarre as it gets. Software developers are doing "architecture" but not really, it's "design", it's "planning", it's not a meeting its a collaboration, it's not a kickoff planning, it's this synonym or another. It's Archi-tardation is what it really is. To disparage architecture and then pretend all the notes, whiteboard artifacts, cue cards, index cards, stickies, pen to palm of hand notations are not a self-inflicted, dysfunctional (sad) attempt at backfilling the absence of rational architecture is tragic. To imply that developers (bricklayers), spreadsheet gurus, or are knowledgeable architects is delusional. Yes, you can get away with calling the worst-case development huts, lean-tos, and spider holes architecture but I'm pretty sure that's not what the customer had in mind - YNRG2ATRU - You're not really going to argue that are you?.
@pmarreck8 жыл бұрын
EDIT: Oh jesus. I edited this and ALL the escaped characters are now visible. I refuse to fix it, as a testament to the fact that TDD IS NECESSARY. lol. Continuing on... +Frank Krasicki I think that you're missing something here. The word "architecture" and "software architect" have been quite diluted since you perhaps first took them on, which is exactly why they are trying to avoid (NOT disparage) the term, as anyone who encounters a confusing word is wont to do. Not sure if you're still in touch with the 20-30something startup-employed programming-team set, but that's the space where it's been diluted and that is where your wrath should be aimed. Secondly, there is a criticism (with evidence) coming around that "conventional" software architects do less-valuable architecture work if they don't also code www.reddit.com/r/programming/comments/47c174/why_should_software_architects_write_code_an/... Which implies that there is less of a distinction between "programmers" and "software architects" than previously thought, further diluting the title. Do you still "git push origin" these days? If not, you might not be the target audience. Thirdly, and most stridently, I unfortunately need to attack your assertion that Agile is "gobbledygook". There is plenty of evidence emerging that TDD, one of the key elements of Agile, is an excellent tradeoff (something like 90% bug reduction with a 15-35% increase in development time). Google Nagappan's Microsoft Research paper from a number of years ago; much more evidence has emerged since. You might have a lot of wisdom (and acronyms nobody's ever heard of) to give... But at least base your assertions on actual evidence, instead of NIH syndrome.
@FrankKrasicki8 жыл бұрын
+Peter Marreck I've worked in this industry for 40 years or so and I'm familiar with the terminology and the responsibilities involved. It is true that the role of Software Architect in its many implementations has been diluted and not in a good way. As often as not, Thoughtworks sells its services at the expense of independent Software Architects or corporate staff trying to resolve problems. These are cheap and low shots. There are always more developers than Architects in any enterprise and the bottom-up meme has a built-in self-interest. The corporation needs to keep feeding the development staff with empty badges, promotions, and anything-but-money distractions. Thus EVERYBODY is an architect. When EVERYBODY is an Architect then no one is and that's a door opener for the agile consulting firms. Presumably you get the picture - this rant is an old one. Knowing how to program and understanding programming is a valuable skillset. I think all developers should have it. But that has nothing to do with architecting ecosystems and so on. An analogy; the person who makes bricks isn't the same as a bricklayer, and neither of them are architects just because an architect might design a building out of brick. TDD was appropriated by the Extreme Programming gang years ago and then claimed as an "agile" feature. BFD. I am a life-long independent contractor and I know from experience (I won't name names here) that there are oceans of hypocrisy in the agile rhetoric. I've worked at Six Sigma organizations that weren't even in pedestrian ways. Same with ITIL. Just recently left an agile organization that trained their staff who wholly ignored the practice and wear the badges. Please. I'd ask for giving me a break but this nonsense is relentless.
@DavidTimovski8 жыл бұрын
+Frank Krasicki "developers (bricklayers)" Yikes. Can't believe people upvoted this egotistical lump of rubbish.
@bryanedds89227 жыл бұрын
Here, here!
@auberginebundy6 жыл бұрын
Spoken like a true ivory tower architect. Thankfully this kind of attitude is dying out.
@CarlosZaragozaOne4 жыл бұрын
This Molly is so bad talking in public in contrast with Martin
@RahulSharma-re8jg4 жыл бұрын
Wow your criticism is very constructive and it really helps me in improving. Thanks mate!