From OSCON 2015 in Portland: In the software world, architecture often gets a bad reputation. I’ll talk about why it matters, and how we can pay attention to it without falling into traps. About Martin Fowler: Martin Fowler is an author, speaker, consultant, and self-described general loudmouth on software development. He concentrates on designing enterprise software – looking at what makes a good design and which 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, which he considers a “really rather good” system delivery and consulting firm. He writes at martinfowler.com. Watch more from OSCON 2015: https://goo.gl/vD6vda Find out more about OSCON: http://oscon.com/open-source-2015 Don't miss an upload! Subscribe! http://goo.gl/szEauh Stay Connected to O'Reilly Media by Email - http://goo.gl/YZSWbO Follow O'Reilly Media: http://plus.google.com/+oreillymedia https://www.facebook.com/OReilly https://twitter.com/OReillyMedia

Comments

1. One can appreciate the point of this presentation when one's sense of code smell is trained, functional and utilized. Those controlling the budget as well as developer leads should understand the design stamina hypothesis, so that the appropriate focus and priority is given to internal quality - otherwise pay a high price soon.
2. I don't think this talk ended well for Martin. He used weak arguments. A lot of fallacies, maybe on purpose as a tool for rhetoric, but too much.
   
   Maybe those few 10 minutes played against him.
   
   We all know his trajectory. I would love to see this same subject developed by him in a talk of a lot more than 10 minutes.
3. Unfortunately, Linux cannot keep up with Windows.
4. Brilliant .....
5. I really like Martin Fowler, I love reading the stuff he writes, however I do believe that architecture is very much important and that architects are very important not just for the reasons he says, I know that agile says that architecture must emerge in development teams but this will cause entropy if you are dealing with a large product or a kind of business that changes constantly, at some point it will all be chaotic, so I think that if a baseline is established (Architecture Description, Architecture Guidelines and standards) for a project, you'll be able to react to change but have it managed and you'll be able to continue to grow your software product, that's my personal opinion.
6. Starts out with a painful straw man argument, "I picture an architect like.." Ugh, get out and meet a few instead of making these statements
7. Brutally bad in more ways than not. This guy and his associates have been disparaging Software Architects for years with the same glib generalizations and nonsensical arguments he makes in presentations such as this. This floundering narrative resembles an alcoholic whose had too much to drink attempting to walk a straight line.
   
   There is no single worthwhile definition of a Software Architect, the role is relative to the organization and the product. when the primary duty of a Software Architect is to code then the title is little more than an obfuscation for a lead developer and has very little to do with Software Architecture and more to do with code design. Why the obfuscation? Developers critical to the enterprise demand richer sounding titles - ego flattery. The developer can be a Software Architect or a Cyber Genius Butterfly for that matter
   
   Nor is Fowler correct that Software Architecture plans are wrong because Software Architects are divorced from changes during the coding process. The coding process is the translation of a process specification into executable software application. A well-defined process will not have coding surprises and the desired outcome must be the desired outcome or its defective. A Software Architect is not responsible for coding and issues with coding the process to spec though code can expose an architectural issue of substance that requires re-examining the specifications.
   
   It should also be noted that Software Architects who were developers ten years ago and could ride a bike can still perform both things assuming no extenuating circumstances, not that riding the bike or coding read, write, loop in a given language is paramount to Software Architecture.
   
   And when Fowler waves his hands and says, "Sure there's a document here or a diagram there" he makes it sound like these are delivered by the Tooth Fairy from above as opposed to the flatulent pearls of wisdom that bubble up from poor coding practice. Fowler profits from the rhetoric associating poor quality to the Software Architects while the noble agile developers are keepers of the secret wisdom - forever more knowledgeable than the author of the book they are entrusted to accurately translate because like a bad word correction application only they know that the sentences are being indiscriminately reconstructed. Herein lies why Fowler and cohorts believe coding is necessary For Software Architects. They think the magic Pixie Dust of coding will either alert the Architects that the development process is flawed or make the Architects complicit in those defects. He can't imagine that a well-constructed postmortem could examine the quality of the code produced during the sprint or development cycle.
   
   Fowler should spend less time coding (just kidding - he hasn't coded in ten years (my guess)) and more time working with Software Architects. Just follow the Yellow Brick Road to the Ivory Tower.
8. To focus on internal quality is to break (refactor) the paradigm usurped from architecture as the lay person knows it.
   
   One might design a vertical slum low-income housing project that can shrug off a Richter 9.0 earthquake and can be maintained for the lowest cost of its class BUT is an eyesore to passers by and a depressing environment for the tenants.
   
   Architecture in terms of software must fulfil many criteria, first and foremost being that it meets the needs of its consumers, i.e., the end users; these needs include ease of use and the ability to be productive.
   
   Example:  web based forms of any degree of complexity when compared to desktop based equivalents tend to be limited with regards to using the keyboard to enter data quickly.
   
   FWIW, the badness of software architecture is likely to be inversely proportional to the extent to which the end users were involved in the creation of the end product.
9. of course code is important, that's why you want to stay away from architects as much as possible. What software is Martin actually known for?
10. Brilliant....Key takeaway is the pay less now for poor architecture and then end up paying more over long run for a poorly architected product