"Agile Architecture" - Molly Dishman & Martin Fowler Keynote
HTML-код
- Опубликовано: 4 сен 2024
- Watch more from the O'Reilly Software Architecture Conference: goo.gl/lXpXnG
There is a common misconception that architecture is thrown out the window when a team or organization is developing software in an agile fashion, but where does this myth stem from? Surely, there is some truth behind this thinking. We’ll talk about some of the underlying assumptions that support this belief in order to build a common understanding of what it really means to be developing in an agile fashion. During the second half of this talk, we’ll move from the conceptual thinking into some practical suggestions from our experiences - what we’ve seen that works and highlight some practices to avoid. In the end, the audience will know how to bring architectural thinking into teams to support the higher level goals of application architecture.
About Molly Dishman (ThoughtWorks):
Molly Dishman is a Senior Consultant at ThoughtWorks Inc. a global IT Software Consultancy. During her ThoughtWorks career she has developed top quality software solutions for clients all over the world. She has been a trainer, developer, technical lead and coach during her time at ThoughtWorks. Molly is passionate about solving technical problems and helping others grow and learn software development.
About Martin Fowler (ThoughtWorks):
Martin is an author, speaker, consultant and self-described general loud-mouth on software development. He concentrates on designing enterprise software - looking at what makes a good design and what practices are needed to come up with good design. Fowler has been a pioneer of various topics around object-oriented technology and agile methods, and written several books including “Refactoring”, “UML Distilled”, “Patterns of Enterprise Application Architecture”, and “NoSQL Distilled”. For the last decade he’s worked at ThoughtWorks, what he considers a “really rather good” system delivery and consulting firm, and writes at martinfowler.com.
For more information, visit: oreil.ly/1Cyt9nt
Software architecture is a massive multidisciplinary subject, covering many roles and responsibilities, which makes it challenging to teach because so much context is required for every subject. It's also a fast-moving discipline, where entire suites of best practices become obsolete overnight.
The O'Reilly Software Architecture Conference is a new event designed to provide the necessary professional training that software architects and aspiring software architects need to succeed. A unique event, it covers the full scope of a software architect's job, from IT to leadership and business skills. It also provides a forum for networking and hearing what other professionals have learned in real-world experiences.
Stay Connected to O'Reilly Media by Email - goo.gl/YZSWbO
Follow O'Reilly Media:
plus.google.com...
/ oreilly
/ oreillymedia
If you're interested in more of my talks, take a look at martinfowler.com/videos.html
Martin Fowler EXCELENTE
Molly did very well, people here who are critiquing her confidence never spoke on a stage lol
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.
Enjoyed this talk? Watch our interview with Molly Dishman, and browse other keynotes and interviews from the O'Reilly Software Architecture Conference: ruclips.net/video/cNIVPsL2PMs/видео.html
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.
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.
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.
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.
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.
Molly, if you are in danger, just blink twice!!
Funny. I had the same impression she was a bit stressed (stage fright?)... or maybe just recovering from a hangover after Paddy day :)
don't know why they going back and forth ... hard to follow ... they shoulda just split the presentation up. A very non-agile presentation!
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.
Agility without SOLID is a pure mess.
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.
My professor is making me watch this as part of an exam, anyone got a cliffnotes version?
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
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"
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!
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.
"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?
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
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.
Molly seems very, very nervous.
This sometimes happens when one is trying to talk about something one doesn't know anything about ...
This is just awkward.. I love how Martin slowly moved further away
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.
Is she in love with him, or what's going on?
feastures She looks seriously nervous
Chris Developer feminine attire looks good but does not enable breathing properly
+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.
+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.
+feastures The day after St. Patricks' Day in Boston? That is a GIGANTIC holiday in Boston. That's gotta be a hangover
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
.Interesting
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.
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.
@@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.
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.
Martin Fowler? RUUUN!
Does anyone else think Molly looks a bit like Ronda Rousey?
Similar voice too
wow, literally 30 minutes of buzzwords
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?.
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.
+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.
+Frank Krasicki "developers (bricklayers)" Yikes. Can't believe people upvoted this egotistical lump of rubbish.
Here, here!
Spoken like a true ivory tower architect. Thankfully this kind of attitude is dying out.
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.
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.
You say functional programming is more composable, but experienced OO programmers can reuse code 2x more often than experienced functional programmers.
This Molly is so bad talking in public in contrast with Martin
Wow your criticism is very constructive and it really helps me in improving. Thanks mate!