Making Architecture Matter - Martin Fowler Keynote

well I suppose I should say good morning but I'm from the East Coast and so my body is craving lunch at the moment so good morning doesn't seem kind of appropriate but I'm talking about architecture and this is kind of an odd thing goose the the reason I'm up here talking is because the organizer said we'd like you to talk about software architecture in ten minutes okay but architect has always been an awkward slightly awkward thing for me I don't really like the term software architecture because it summons up these images of some senior person in an organization who is setting rules and standards for how software should be written but hasn't actually written any software for maybe ten or twenty years and these architects Joel Spolsky used the term architecture astronauts often cause a lot of problems for software projects and so the whole term architect and architecture has that kind of nasty taste to it and this is particularly something that that we need to change is industry because the way we write code is important when we have that opening little thing at the beginning of a show you see little bits of software code put in there because that's because the open-source community has always believed code is important but if you're going to be a technical person you have to be someone who's familiar and comfortable with the act of programming and of course there has been for quite a while in architecture particularly this notion that architecture is going to beyond programming and if you're an architect you shouldn't be programming anymore and that's something that I've always felt is very wrong but that then only raises the question well well what really is architecture what does the even the word mean in the software context because because we're borrowing the term from buildings and construction and where it actually means something completely different and I won't go into all of that if you want to come up with some kind of official definition of what architecture should be this is probably the the closest you might get I treble e software standard and that kind of definition has been around for a while but when I think of what architecture ought to mean undoes mean I actually think of a reaction to a statement like that and that was made by this guy I don't know how many of you recognize him this is Ralph Johnson and probably best known as one of the authors of the design patterns the Gang of Four book he's also and worked by people like him has been a major trigger for my career in the sense that it was his students that originally formalized the notion of refactoring that actually wrote the very first refactoring tool so I've nicked a lot of stuff from Ralph and his his folks over the time and he would sent an email once that was a reaction to that definition of architecture and I liked it so much but I ended up stealing it completely and this column on architecture that I wrote over ten years ago for our trevally software basically takes the entire email and pads it out a bit to be the column you can find it if you if you want to hunt around for it and he basically took this definition and said the problem with this stuff definition is that it relies on this notion of somehow what are the highest level most critical important components a lot of the earlier versions of this talked about the highest level concerns in something and you said but what does that mean how do you select which components what relationships are important is obviously a gazillion components and relationships in a product what matters that makes some of them architectural and some of them not and in his view he said that well what really matters here is that if you go to a reasonably healthy software project and you talk to the expert developers on that project the people who most capable who are most familiar with a codebase they will have some common understanding of how the thing works and it's that common understanding that is effectively the architecture and this is important because it is also a brings out the fact that architecture is very much a social thing it is that fuzzy embedded understanding that really matters and yeah there may be diagrams here and there there might be documents here and there and there may have architecture written on them but they're just a representation and usually imperfect representation of that shared understanding and what you're trying to do with a software project particularly a software projects grow is you want to make sure you have a good shared understanding between the people who are leading the project that's really what matters but that definition although it's very common there's another one that's also quite important which you also see which is saying that architecture should be the decisions you need to make early on and Ralph also was able to poke a hole in that one he said well really it's what you wish you could get right early on because the point is the decisions you might need to make early you don't have the information you only learn about what the software product should be structured like as you're building it and what it really boils down to is you concerned about the decisions are hard to change and that is actually a quite useful way of thinking about architecture what is hard to change and it does lead to some different and thoughts than what are the bank components and how do they fit together because programming language the choice of programming language is a decision that's hard to change but it isn't usually considered what are the top-level components so having kind of taken these two routes he then continues by saying well really we've got two things here shared understanding and hard to change but they actually boil down to really what in his view and and I'm echoing it because it's in my view to is the definition of architecture and I hear though of the laughter right because that sounds like an almost silly statement the important stuff right whatever that happens to be but actually it I think it's a very profound statement it says that if you're trying to think about your software system and what its architecture is what you the first thing you have to do is you have to figure out well what is important what do we as will lead the technical leadership of a project consider to be the most important things in there or even on a solo project what is the key things about this system what is the most important thing in the codebase that I have to keep at the top of my head when I'm working on it that decision about what is important is really the key thing that goes on and that is really the thing that trumps everything else so that if people ask me what my definition of architecture it is I follow Ralph in this and I say it's the important stuff so that talks about what architecture is the next thing I want to look at is another question which is well why should we care about software architecture why is it as important as you know to have me come along and do a 10 minute talk about it and really the thing that triggers that is something like this that you hear from time to time so how many people have heard something like this on the software project that they've been working on I've heard this kind of line you know we need to sort of don't worry so much about modularity in these design ideas we've got to crank out features and the reaction of a lot of people to this is they get frustrated and they try to argue in terms of well we we've got to do a decent job as software professionals we've got to stand up to our professional standards it's almost like taking a moral response to this and saying well software architecture is important for moral reasons we need to do a good job we need to be craftsmen unfortunately my view is that if you take that line you've lost as soon as you start pacing that argument you lose because what you're doing is you're making a battle between craftsmanship and economics and economics always wins and if you want to say well why is architecture important you have to instead cast ik in economic terms the problem with this argument this argument up here is it's got a notion of what is quality based on an idea that quality is something I can trade off the cost we do this all the time when we buy things when we buy cars when you buy clothes we do this trade-off in quality and cost but quality in software means a whole bunch of different things and the point is that some of these things are user a manager a customer they can see them but some of them they can't so whether your software has a good architecture or a good modular design or whatever that's not something that's visible and so I think of it as saying well we've got two forms of quality here that that's external are not internal an architecture is about internal quality and the thing about internal quality is it is not directly visible if somebody offers me a software product with great quality that costs $100 more than software that does exactly the same thing but has poor internal quality what's my motivation to pick the great quality one if I'm going to pay a hundred dollars more for something that does the same thing I'm going to go for the pure internal quality surely but what matters in terms of internal quality is more the long-term picture and I have this rather convoluted statement that tries to sum this up I call it the design stamina hypothesis horrible long term I know but it tries to capture this and I do it by plotting this pseudo graph of the functionality of the software over time as it grows if you both don't pay attention to design and architecture during the project you get a curve that looks something like this but as time goes on every time you want to add new features it seems to get harder and harder and harder because the existing code base kind of slows you down as you add more stuff how many people have been on a software project that feels like that pretty much everybody that's big reaction but he doesn't necessarily have to be that way if you've got a good architecture and you pay attention to keeping it healthy and refactoring regularly and making sure that the software code base stays clean you can get a different experience where not just as that slowdown attenuated you can even reverse it and feel that I can build new features faster and faster because the software is already nicely componentized I just need to make a change here and a change fair it's easy to find where to make the changes and I can accelerate because the software that's existing the existing code base is a platform that I can build up and go faster how many people have had that experience on the software project less hands but this Plitt there's still quite a few of them I asked this question you know every time I give this talk I always get that same result lots of hands are the first less but still enough for the second what we want is that second case and that is why software architecture is important because yes if I buy the product that's a hundred dollars cheaper and has low internal quality I win at the moment but what will happen is that the better internal quality software will be able to make new features more and more rapidly and soon the slower one can't keep up anymore and we can probably think of cases competitive cases where we've seen this happen where a product that look like it's dominating has bended up being eaten away over time and that's particularly relevant now as we push more and more towards continuous delivery continuous deployment features updated over the Internet all the time that degree of being able to respond to change becomes important and that's the economic reason why software architecture is important because if we don't keep good architecture if we don't put that effort on internal quality we are in the end deceiving our customers in fact steel from our customers because we're slowing down their ability to compete and that crossover line we're good design counts and even in a short term happens remarkably quickly it happened when I talk to people about how long it's weeks not months so that's the Wotton the wive architecture I would like to talk about how but I have 19 18 seconds left so unfortunately that's going to be tricky but fortunately the whole track at this conference talking about the house of software architecture so I'm going to delegate all of that to them and I hope you'll enjoy listening to them

Channel: O'Reilly

Views: 264,323

Rating: 4.9413128 out of 5

Keywords: O'Reilly Media (Publisher), OReilly Media, Martin Fowler (Computer Scientist), ThoughtWorks (Business Operation), software architecture, architecture programming, oscon portland, O'Reilly Open Source Convention (Conference Series), oscon 2015

Id: DngAZyWMGR0

Length: 14min 4sec (844 seconds)

Published: Thu Jul 23 2015

Reddit Comments

[u/ChadBan]

The reaction of a lot of people is they get frustrated and they try to argue in terms of "Well, we've got to do a decent job as software professionals. Software architecture is important for moral reasons. We need to do a good job. We need to be craftsmen." Unfortunately, my view is that if you take that line, you've lost. because what you're doing is making a battle between craftsmanship and economics, and economics always wins, you have to instead cast it in economic terms. ...

Yes, if I buy the product that is $100 cheaper and has lower internal quality, I win at the moment, but what will happen is that the better internal quality software will be able to make newer features more and more rapidly, and soon the slower one can't keep up any more. And we can probably think of competitive cases where we've seen this happen--where a product that looks like it's dominated has ended up being eaten away over time. ...

That's the economic reason why software architecture is important, because if we don't keep good architecture, if we don't put that effort on internal quality, we are in the end deceiving our customers, in fact stealing from our customers, because we're slowing down their ability to compete.

[u/ErstwhileRockstar]

Good presentation by Martin Fowler. As long as he isn't talking about Microservices, NoSql and Agile he is quite enjoyable.

[u/tsimionescu]

He references this article/hypothesis of his: Design Stamina Hypothesis.

Who actually believes something like that? That there can be a system where it gets easier to add features as more features exist?

The biggest problem with adding features to a system is interaction between features, not simply interaction between their implementations. Whenever you add a new feature, you need to design it's interaction with all of the existing ones.

A nice example is the x86 rootkit article that was recently on the front page: we have a feature where someone in ring 0 can map a set of registers on any area in memory. We have another feature where certain areas of memory can only be read or written by someone in ring -2. To add one of these features to a processor that already has the other, you not only need to implement it, but you need to go and change the implementation of the other feature to make room for this one.