Model Minded Development

I gave a talk to the Princeton chapter of the ACM on Model Minded Development.

Many slides have no text, so you'll want to go to the Full slide deck with speaker notes.

  • Domain-Driven Design says that we should be mindful of domain models and embed them in our code.
  • Design Patterns say that we should know a catalog of patterns so we can solve recurring problems that arise in OO code.
  • Software Architecture says that unless we are mindful of large-scale patterns and models then our systems will not achieve the qualities we seek.
  • Test-Driven Design imposes a structure on our code so that it can be more easily tested.
  • Programming styles (functional, object-oriented, procedural, etc.) impose structure on our code.

The common denominator here is that software developers are expected to keep in mind many abstract yet complex models that constrain the code they write. In some ways these constraints are a burden and in other ways they are light that illuminates a path forward.

I will discuss an idea called Model Minded Development that generalizes across DDD, Design Patterns, architecture, TDD, and coding styles. The defining characteristic of senior software developers is their facility with Model Minded Development and it enables them to operate at an advanced level.

What Agilists Should Know About Software Architecture

Michael Keeling and I had a video Hangout on Air today, chatting about the intersection of software architecture and agile.

Some of the topics discussed include: 3-tier architecture, YAGNI, quality attributes, big design up front, little design up front, design patterns, architecture patterns, walking skeletons, thin vertical slices, spiral model, system metaphor, extreme programming (XP), application frameworks, MVC, publish-subscribe, refactoring, architectural refactoring, refactoring vs rework, refactoring-to-patterns, lean thinking, last responsible moment, keeping options open as long as possible, Michael Waterman (NZ), cost-value-curve, “I’d love to have that problem”, architecture mismatch, conscious design decisions.

Video: Lecture on Intro to Software Architecture

This lecture, recorded at the University of Colorado Boulder in September 2012, is an introduction to the major concepts of software architecture. The audience consisted of 70 seniors majoring in computer science. It is based on material taken from the book Just Enough Software Architecture.

Most developers have no formal eduction in software architecture, yet a system’s architecture has a big influence on its success. Software architecture has been intensively researched for more than twenty years now and studying it will help you do a better job of designing systems, give you names for the concepts and patterns, and help you choose between competing designs.

Updated Drupal site

Upgrading Drupal is always a bit stressful. It’s easy to get a site up and running and then customize it — but it’s exactly those customizations that can get lost in the upgrade. It appears to be all back to normal but let me know if you find anything that seems broken.

Conceptual Models of Software Architecture

Earlier this year, I gave talks at the GOTO Copenhagen and GOTO Amsterdam conferences. A few folks at the conferences called it "the dandelion talk" because there is an example in the middle of my conceptual model of how to get rid of dandelions in your yard. Of course the real idea is that conceptual models of architecture can help you become a better software engineer -- the difference between the 20-year-old version of yourself and the older, master-builder version of yourself. This is perhaps my favorite of all the talks I've given, so I hope that you enjoy it too.

GOTO Copenhagen talk on conceptual models of software architecture

(Opens on InfoQ website; no easily embeddable video -- but going to their site gives you both the video and the slides)

Architecture Hoisting - video of Atlanta talk

I presented my work on Architecture Hoisting last week in Atlanta. The big idea is that software often relies on global design constraints (guiderails) to achieve its qualities (e.g., reliability, security).

But you've really only got two options for ensuring those guiderails: (1) developer vigilance and (2) architecture hoisting. In the small (say inside of a data structure), using vigilance to keep an invariant is possible. In the large, architectural guiderails (self-imposed constraints that simplify the software) are much harder to ensure, as the recent remote exploit in Google Chrome (a use-after-free bug) illustrates.

The other option, architecture hoisting, has not been widely recognized so this talk gives it a clear definition, shows examples of it in use, and discusses its applicability and trade-offs.

Abstract: Software architecture focuses on quality attribute requirements, such as scalability or performance, that are overall properties of a system. This talk describes Architecture Hoisting, a a design technique where the architecture ensures an intensional design constraint (i.e., a guiderail) to achieve a global property. Discussed examples include the NASA JPL Mission Data System, Enterprise Java Beans, and the Apache Portable Runtime.

Speaking at Atlanta IASA, Weds 14th, 2012

I will be in Atlanta giving a talk on Architecture Hoisting next week at the local IASA chapter. The topic of architecture hoisting is in my book but I’ve had several requests to dig into it further and this talk is the result. Here’s the talk abstract:

“Solve Problems by Hoisting Them into your Architecture”

Architecture hoisting is an established technique that has only recently been identified and named. It is suitable when you have a challenging design problem that requires consistency in the implementation.

Book on sale: Now just $19.50 with free shipping (limited time)

A little while ago, several cases of my books were being shipped to Amazon by the US postal service but those cases went missing. The USPS claims to have never found them despite being well labeled and indeed having an Amazon packing list inside the box.

Fast forward to now and those books are showing up on Amazon and eBay. But all is not well! It seems they were sold by the USPS to scavengers who have put them up for sale.

More book citations: Muddy architecture

Franco Martinig has another blog post about my book, this time on Muddy architecture.

New review of my book

Franco Martinig of Methods and Tools has reviewed my book. Review of Just Enough Software Architecture.

Syndicate content