Community hub
0 subscribers8 pages, 0 posts
Recent from talks
All channels
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Welcome to the community hub built to collect knowledge and have discussions related to Martin Fowler (software engineer).
Nothing was collected or created yet.
Martin Fowler (software engineer)
View on Wikipediafrom Wikipedia
Martin Fowler (18 December 1963) is a British software developer,[2] author and international public speaker on software development, specialising in object-oriented analysis and design, UML, patterns, and agile software development methodologies, including extreme programming.
Key Information
His 1999 book Refactoring popularised the practice of code refactoring.[3] In 2004 he introduced a new architectural pattern, called Presentation Model (PM).[4]
Biography
[edit]Fowler was born and grew up in Walsall, England, where he went to Queen Mary's Grammar School for his secondary education. He graduated at University College London in 1986. In 1994, he moved to the United States, where he lives near Boston, Massachusetts in the suburb of Melrose.[1]
Fowler started working with software in the early 1980s. Out of university in 1986 he started working in software development for Coopers & Lybrand until 1991.[5] In 2000 he joined ThoughtWorks, a systems integration and consulting company,[1] where he was Chief Scientist.[6]
Fowler has written nine books on the topic of software development. He is a member of the Agile Alliance and helped create the Manifesto for Agile Software Development in 2001, along with 16 fellow signatories.[7] He maintains a bliki, a mix of blog and wiki. He popularised the term Dependency Injection as a form of Inversion of Control.[8][9]
Publications
[edit]- 1996. Analysis Patterns: Reusable Object Models. Addison-Wesley. ISBN 0-201-89542-0.
- 1997. UML Distilled: A Brief Guide to the Standard Object Modeling Language. Addison-Wesley. ISBN 978-0-201-32563-8.
- 1999. Refactoring: Improving the Design of Existing Code, With Kent Beck, John Brant, William Opdyke, and Don Roberts (June 1999). Addison-Wesley. ISBN 0-201-48567-2.
- 2000. Planning Extreme Programming. With Kent Beck. Addison-Wesley. ISBN 0-201-71091-9.
- 2002. Patterns of Enterprise Application Architecture. With David Rice, Matthew Foemmel, Edward Hieatt, Robert Mee, and Randy Stafford. Addison-Wesley. ISBN 0-321-12742-0.
- 2010. Domain-Specific Languages. With Rebecca Parsons. Addison-Wesley. ISBN 978-0-321-71294-3.
- 2012. NoSQL Distilled: A Brief Guide to the Emerging World of Polyglot Persistence. With Pramod Sadalage. Addison-Wesley. ISBN 978-0-321-82662-6.
- 2013. Refactoring: Ruby Edition. With Kent Beck, Shane Harvie, and Jay Fields. Addison-Wesley. ISBN 978-0-321-98413-5.
- 2018. Refactoring: Improving the Design of Existing Code, Second Edition. Kent Beck, and Martin Fowler. Addison-Wesley. ISBN 978-0-134-75759-9.
Domain-specific languages
[edit]In his book, Domain-specific languages, Fowler discusses Domain-specific languages, DSL. DSLs are said to be defined by being composable programming languages, with their focus on an individual domain and having limited expressiveness.[10]: 27 It is argued that DSLs can increase productivity by removing the requirement of the programmer to understand a full programming language, providing a means of communication with domain experts, and separate the manner of execution of a task from the definition of a task itself.[10]: 33 These benefits are set against the cost of learning a new language and building the tools for this language, siloing that results for different languages and the abstractions used in DSLs not being suitable for a task.[10]: 39
Fowler introduces the concept of internal (or embedded) and external DSL, an internal DSL being a DSL that is a subset of another language and can be executed by the tools for this outer language. Ruby and Lisp are given as an example of languages where internal DSLs are common. He also introduces the idea of Semantic Model which defines the execution of a DSL.[10]: 14 Various examples of DSLs are presented including graphviz, a language for specifying graphs to be rendered; JMock, a java mocking framework; CSS, a language to specify stylistic elements of a website; HQL, an object relational mapper in Java; XAML, a language used to specify and change graphical user interfaces; FIT, a language to express testing scenarios; and make, a tool to build software[10]: 147
The book discusses implementing an external DSL using tools like parsers, lexers, abstract syntax trees and code generation referred to as "syntax-driven translation"[10]: 219 This is contrasted with "delimiter-driven translation" which is said to be simpler but less powerful. Here the language is simple enough to be interpreted by splitting on delimiters and switching logic based on individual entries.[10]: 201
Ways of implementing internal DSLs is discussed, with attention paid to nested function calls,[10]: 357 sequences of function calls,[10]: 351 or method chaining[10]: 373 amongst other methods.[citation needed]
References
[edit]- ^ a b c Martin Fowler at martinfowler.com. Retrieved 2012-11-15.
- ^ "About Martin Fowler". martinfowler.com. Retrieved 1 May 2021.
- ^ Stephane Faroult; Pascal L'Hermite (2008). Refactoring SQL Applications. O'Reilly Media. p. 8. ISBN 978-0-596-55177-3.
- ^ Stephen Chin; Dean Iverson; Oswald Campesato; Paul Trani (2011). Pro Android Flash. Apress. p. 300. ISBN 978-1-4302-3232-2.
- ^ James A. Highsmith (2002). Agile Software Development Ecosystems. Addison-Wesley Professional. p. 133. ISBN 978-0-201-76043-9.
- ^ Martin Fowler | ThoughtWorks. Retrieved 2015-03-30.
- ^ Manifesto for Agile Software Development. Retrieved 2012-12-10.
- ^ Kamil Piętak; Marek Kisiel-Dorohinicki (2013). "Agent-Based Framework Facilitating Component-Based Implementation of Distributed Computational Intelligence Systems". In Ngoc-Thanh Nguyen; Joanna Kołodziej; Tadeusz Burczyński et al. Transactions on Computational Collective Intelligence X. Springer. p. 38. ISBN 978-3-642-38496-7.
- ^ Martin Fowler (2004) "Inversion of Control Containers and the Dependency Injection pattern". Retrieved 2012-11-15.
- ^ a b c d e f g h i j Fowler, Martin (2011). Domain-specific languages. Upper Saddle River, N.J.: Addison-Wesley. ISBN 978-0-13-210754-9. OCLC 686709295.
External links
[edit]
Wikimedia Commons has media related to Martin Fowler.
Wikiquote has quotations related to Martin Fowler.
- Official website
- Venners, Bill (9 December 2002). "A Conversation with Martin Fowler". Artima. In six parts.
Martin Fowler (software engineer)
View on Grokipediafrom Grokipedia
Early Life and Education
Childhood and Family Background
Martin Fowler was born on December 18, 1963, in Walsall, England.[8][9] He grew up in Walsall, a town in the West Midlands known for its industrial heritage in the post-World War II era.[10][11] He attended Queen Mary's Grammar School in Walsall from 1975 to 1982.[1] Details about his family background and parental professions are not publicly documented in available sources. Limited information exists regarding specific early experiences or hobbies that may have influenced his later interest in computing, though his upbringing in an area with emerging technological opportunities coincided with the rise of personal computing in the 1970s and 1980s.[10] This early environment preceded his transition to higher education at University College London.[11]Academic Background
Martin Fowler enrolled at University College London (UCL) in 1983, where he pursued a Bachelor of Science in Engineering (BSc Eng) degree in Electronic Engineering and Computer Science.[1] This program provided him with foundational knowledge in computing principles, electronics, and systems design, blending theoretical and practical aspects of technology during the mid-1980s era of emerging personal computing and programming paradigms.[1] Fowler completed his degree in 1986, marking the culmination of his formal academic training in a field that directly informed his subsequent career in software development.[1] While specific details on individual coursework, projects, theses, or honors are not publicly documented, his studies at UCL exposed him to core computer science concepts that would later influence his work on software architecture and engineering practices.[1]Professional Career
Early Professional Roles
Fowler commenced his professional career in software development immediately after graduating with a BSc in Electronic Engineering and Computer Science from University College London in 1986, joining Coopers & Lybrand (now part of PwC), a prominent consulting firm, where he remained until around 1991.[1][12] In this role, he engaged in software development and systems analysis, primarily supporting enterprise applications for clients.[13] His work involved collaborative team efforts on early object-oriented modeling, including foundational contributions to analysis patterns—reusable object models for complex domains—that would later influence his seminal publications.[13] During his tenure at Coopers & Lybrand, Fowler gained practical exposure to team-based development in a consulting environment, tackling real-world challenges in building maintainable software systems for business processes.[1] The firm's London team played a key role in supporting his initial explorations of object-oriented techniques, fostering skills in designing models that captured enterprise requirements effectively.[13] This period marked his transition from academic foundations to professional practice, emphasizing the integration of software solutions within large-scale organizational contexts. Subsequently, Fowler moved to Ptech, a small technology company specializing in process technology and object-oriented modeling tools, where he continued honing his expertise in software analysis before becoming an independent consultant in 1991.[1] At Ptech, he contributed to projects applying object-oriented techniques to model intricate business domains, further solidifying his understanding of domain-specific modeling and collaborative development practices.[14] These early roles provided critical groundwork in object-oriented programming and enterprise software, shaping his approach to software engineering challenges.[1]Role at ThoughtWorks and Beyond
In 2000, Martin Fowler formally joined ThoughtWorks, an IT consulting firm, as Chief Scientist after beginning to work with the company in spring 1999; in this role, he focuses on researching emerging software development techniques used in client projects and disseminating these insights to both internal teams and the broader industry.[2][6] Prior to this position, Fowler had built experience as an independent consultant following his early roles, including time at Coopers & Lybrand.[1] His relocation to Melrose, a suburb near Boston, Massachusetts, in 1994 positioned him to collaborate effectively with ThoughtWorks' North American operations while contributing to the company's international initiatives, enabling a blend of hands-on advisory work and global knowledge sharing.[1] As of 2025, Fowler remains active in his Chief Scientist role at ThoughtWorks, engaging in discussions on evolving topics in software engineering. He has participated in podcasts reflecting on his career journey at the firm, such as the Thoughtworks Technology Podcast episode detailing his experiences over more than two decades.[15] Additionally, he has contributed to conversations on the integration of artificial intelligence in software development, including episodes exploring AI's effects on agile methodologies and the value of "expert generalists" in tech teams.[16][17]Key Contributions to Software Engineering
Development of Agile Practices
Martin Fowler played a pivotal role as one of the 17 co-authors of the Manifesto for Agile Software Development, which was drafted during a gathering of software practitioners in Snowbird, Utah, from February 11 to 13, 2001.[18] This document articulated four core values—individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan—to guide a more adaptive approach to software development.[19] Fowler specifically contributed to selecting the term "agile" to encapsulate the movement's emphasis on flexibility and responsiveness to evolving requirements, drawing from discussions at an earlier Extreme Programming (XP) retreat in 2000.[18] Following the meeting, he collaborated via email and a shared wiki to refine the manifesto's 12 supporting principles, which underscore practices like delivering working software frequently, welcoming changing requirements, and fostering close daily cooperation with business stakeholders.[18] In the wake of the manifesto, Fowler supported the formation of the Agile Alliance in late 2001, serving on its inaugural board in an unelected capacity to help establish the organization as a nonprofit dedicated to advancing agile principles and practices worldwide.[18] Through his involvement, he promoted methodologies such as Extreme Programming (XP) and Scrum, recognizing XP's focus on engineering discipline—including pair programming, test-driven development, and short iterations—as complementary to Scrum's framework for managing complex projects via time-boxed sprints and roles like product owner and Scrum master.[20][21] Fowler advocated blending these approaches, arguing that Scrum provides scalable process structure while XP ensures technical rigor, thereby enhancing overall team effectiveness in delivering value.[21] Fowler's early writings and talks further popularized agile concepts, particularly iterative development and feedback loops, which enable teams to build incrementally, test assumptions early, and adapt based on real-world input rather than rigid upfront planning.[21] In essays like "The New Methodology" (2003), he described iterative cycles—typically 1-4 weeks—as essential for creating tight feedback mechanisms that reveal issues quickly and support continuous improvement, influencing widespread adoption of agile in software teams.[21] During his career at ThoughtWorks, Fowler leveraged the firm's projects as a platform for agile advocacy, demonstrating these ideas in enterprise contexts through consulting and internal practices.[18]Advancements in Refactoring and Code Quality
Martin Fowler significantly advanced the field of software engineering by formalizing refactoring as a systematic discipline. Refactoring is defined as a controlled technique for improving the design of an existing code base through a series of small transformations that preserve the observable behavior of the software.[22] This approach emphasizes restructuring internal code structure to enhance understandability and maintainability without altering external functionality.[23] Fowler popularized this concept through his seminal 1999 book Refactoring: Improving the Design of Existing Code, which provided a comprehensive catalog of techniques and established refactoring as an essential practice in iterative development processes like Agile.[4] One of Fowler's key contributions was identifying and documenting specific refactoring patterns, which offer step-by-step methods to address common code issues. For instance, the Extract Method pattern involves isolating a fragment of code within a larger method into a separate method to improve readability and reduce complexity.[24] The process typically begins by selecting a cohesive code segment that performs a single, well-defined task; ensuring it has no side effects on external state; naming the new method descriptively to reveal its intent; and finally replacing the original code with a call to the new method.[24] This pattern is particularly useful for breaking down long or convoluted methods, promoting modular design.[4] Another influential pattern introduced by Fowler is Replace Conditional with Polymorphism, which eliminates complex conditional logic by leveraging object-oriented inheritance.[25] The steps include identifying a switch or if-else statement that dispatches behavior based on type or value; creating subclasses for each case, each overriding a common method to encapsulate the specific logic; and replacing the conditional with a polymorphic method call on the appropriate subclass instance.[25] For example, in a system calculating bird flight speeds, separate subclasses like EuropeanSwallow and AfricanSwallow would implement a getSpeed method, allowing the client code to invoke it directly without conditionals.[25] This refactoring enhances extensibility, as adding new types requires only a new subclass rather than modifying existing conditionals.[4] Fowler also pioneered the concept of "code smells," which are superficial indicators of deeper structural problems in code that signal the need for refactoring.[26] Coined in collaboration with Kent Beck, the term highlights symptoms like poor design choices that accumulate over time and hinder maintenance.[26] Notable examples include Long Method, where a single method handles too many responsibilities, violating the single-responsibility principle and making it difficult to test or reuse; and Duplicate Code, where identical or similar code appears in multiple places, increasing the risk of inconsistencies during changes.[27] Addressing these smells through targeted refactorings, such as Extract Method for long methods or Extract Class for duplicates, fosters cleaner, more robust codebases.[4]Innovations in Design Patterns and Architecture
Martin Fowler significantly advanced software architecture by formalizing the concept of Dependency Injection (DI) as a specific realization of Inversion of Control (IoC). In a 2004 article, he described IoC as a principle where frameworks manage object creation and dependency resolution, inverting traditional control flow from application code to the framework. Fowler coined the term "Dependency Injection" to highlight how dependencies are provided to objects externally rather than created internally, promoting loose coupling and easier testing. He outlined three primary types: constructor injection, where dependencies are passed via constructors for mandatory wiring; setter injection, using setter methods for optional or reconfigurable dependencies; and interface injection, requiring objects to implement interfaces for injection points. This approach contrasted with the Service Locator pattern, which Fowler critiqued for increasing coupling through explicit lookups, whereas DI assembles components declaratively without such requests.[28] In 2004, Fowler introduced the Presentation Model pattern to address challenges in user interface design, particularly the entanglement of presentation logic with UI elements. The pattern extracts the state and behavior of a view into a separate model class, isolating UI-specific details like rendering while retaining logic for enabling/disabling controls or validating inputs. This separation facilitates unit testing of presentation logic without invoking the GUI framework and supports data binding for synchronization between the model and view. Fowler emphasized its independence from specific UI technologies, making it applicable across platforms, and noted its relation to concepts like Model-View-ViewModel (MVVM). For instance, in a sample application managing album data, the Presentation Model handles dynamic view states, such as highlighting selected items, while the view observes changes for updates.[29] Fowler's 2002 book, Patterns of Enterprise Application Architecture, systematically cataloged patterns for building robust enterprise systems, drawing from real-world implementations in languages like Java and C#. One foundational pattern is Layered Architecture, which organizes applications into horizontal layers—typically presentation, domain, data access (or mapper), and database—to enforce separation of concerns and unidirectional dependencies. This structure insulates higher layers from lower ones, allowing changes in data storage without affecting business logic; implementation guidelines include using interfaces in the domain layer for data access contracts and avoiding cross-layer dependency cycles via package-level scoping. The Domain Model pattern complements this by modeling complex business domains as interconnected objects encapsulating both data and behavior, suitable for intricate rules where a rich object network reflects entities like customers or orders. Fowler recommended implementing it with classes that integrate validation and calculations directly, avoiding anemic models that separate data from logic. Finally, the Repository pattern acts as a mediator between the domain and persistence layers, providing a collection-like interface for querying and storing domain objects as if they were in memory, thus hiding data mapping complexities. Practical guidelines involve defining repository interfaces in the domain layer, implementing them with query methods (e.g., findByCriteria), and using it to support transactional consistency without exposing SQL details. These patterns, supported by code examples, guide developers in constructing maintainable architectures. Refactoring techniques can aid in evolving code toward these patterns by incrementally restructuring dependencies.[5][30][31][32] In 2014, co-authoring with James Lewis, Fowler introduced the microservices architectural style in a influential article, defining it as an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often HTTP/REST or messaging. This style emphasizes decentralized governance, domain-driven design for service boundaries, and infrastructure automation to enable independent deployment and scaling. Benefits include improved fault isolation, technology diversity, and agility in large-scale systems, though it introduces trade-offs such as distributed system complexities like network latency, data consistency challenges, and higher operational overhead for deployment and monitoring. Fowler's work has guided the adoption of microservices in enterprise environments, influencing practices like strangler fig pattern for monolith migration.[33]Exploration of Domain-Specific Languages
Martin Fowler has extensively explored domain-specific languages (DSLs) as targeted programming tools that enhance developer productivity by aligning code more closely with domain concepts, reducing complexity in specialized tasks. In his work, he classifies DSLs into two primary categories: internal DSLs, which are embedded within a host general-purpose language like Ruby or Java, and external DSLs, which operate as standalone languages with their own custom syntax and parsers. Internal DSLs leverage the host language's infrastructure, allowing developers to create domain-like expressions through stylized usage, while external DSLs require building a separate parser, offering greater syntactic freedom but at higher implementation cost.[34][35] The advantages and disadvantages of each approach revolve around factors such as composability and learning curve. Internal DSLs promote composability by integrating seamlessly with the host language's ecosystem, enabling reuse of existing tools, libraries, and debugging capabilities, which lowers the entry barrier for teams already familiar with the host. However, they are constrained by the host's syntax, potentially introducing noise that obscures domain intent and limiting expressiveness to what the host allows. External DSLs, conversely, allow for a tailored syntax that precisely mirrors domain terminology, minimizing learning curves for non-programmers like domain experts, but they demand more upfront effort for parsing and tooling, often resulting in isolated environments with poorer composability and steeper adoption hurdles for developers. Fowler emphasizes that the choice depends on the domain's needs, with internal DSLs suiting incremental enhancements and external ones fitting deeply specialized requirements.[34][36] For implementation, Fowler outlines techniques tailored to each type. Internal DSLs commonly employ method chaining—also known as fluent interfaces—where methods return the object itself to enable readable, chainable expressions that mimic natural language, as seen in Ruby's block-based constructs or Java's builder patterns. External DSLs typically rely on parser generators like ANTLR, which process grammar-defined syntax to produce abstract syntax trees, facilitating code generation or interpretation without embedding in a host. These methods allow DSLs to abstract away low-level details, streamlining development in complex systems.[35][37] Fowler illustrates these concepts with real-world examples that highlight DSLs' practical benefits, particularly in enterprise contexts where boilerplate code proliferates. Graphviz's DOT language serves as an external DSL for generating diagrams, using simple declarative syntax to define graph structures—such as nodes and edges—without manual drawing, which accelerates visualization tasks in software architecture and data modeling. Similarly, CSS functions as an external DSL for web styling, allowing declarative rules likediv { color: blue; } to separate presentation from content, drastically reducing repetitive markup in large-scale applications. In enterprise settings, these approaches minimize boilerplate by enabling concise domain expressions; for instance, Fowler describes state machine DSLs that configure behaviors declaratively, avoiding verbose imperative code and improving maintainability in systems like workflow engines. Such applications not only boost productivity but also bridge communication gaps between developers and stakeholders by using familiar domain vocabulary.[34][35]