Reflections on Software Engineering

Software design requires a depth and breadth of experience that takes years to develop.  While better training in software design might shorten the time required to master design by better codifying knowledge and experience for others to follow, attaining knowledge is easier said than done. Jonathan Mugan in his book The Curiosity Cycle explains : Knowledge is more complicated than simply putting available pieces of information together because much of the world is hidden from view. [...] What we know determines what we see, therefore learning new things changes how we experience the world. If it were a matter of obtaining some bit of information, then anyone could be a great designer after reading a book.  Knowledge is an important part of design since it changes how you see the world, but perhaps even more important are the mental models we create to explain the world.  These models are born through experience and seen through the lens of our current knowledge.  Thinking about the

The year is nearly over and it seems safe to conclude that 2015 is the year software architecture went mainstream.  Conferences that have been traditionally very technology heavy are including more and more software architecture design topics. O’Reilly Media and InfoQ added software architecture conferences to their line-ups this year and even Gartner named software architecture as a main theme for it’s 2015 Catalyst Conference. As George Fairbanks and I were preparing our SATURN 2015 opening address it seemed fitting to reflect on SATURN’s 11 year journey and figure out where it fits in the evolving software architecture landscape that SATURN very much helped to create. During the SATURN 2015 opening address we shared what we see as SATURN’s main strengths.  Three ideas that together we think have given SATURN it’s staying power and helped it remain relevant for over a decade. Strong Foundation - Literacy is perhaps the most important factor to building a strong community. SATUR

I was invited to speak at the IBM dev@Insight conference last October.  I just realized last week that the event was recorded and that the video is available online!  My talk was about how my team overcame our "innovator's block" and created a set of integration patterns for using the IBM Watson Developer Cloud services within Watson Explorer applications.  We see these patterns as a small start of something much bigger and more important.  I hope that history sees our contributions as extremely minor and rather silly compared to the enormously awesome and amazing ideas that follow us in the coming months and years. The talk is an Ignite talk  so the slides auto-advance every 15 seconds.  It makes for a fast, intense, information packed talk.  I've also written a rough transcript of the talk for those who prefer to read (though the video is only five minutes long).

My undergraduate software engineering professor was awesome . Here's one bit of advice he shared during his course that really stuck with me over the years. Pick a scripting language.  Any Scripting Language.  Learn to use it really, really well. Compiled programming languages obviously have a purpose, but lightweight, interpreted scripting languages are an important tool as well. An interpreted scripting language is the perfect choice for one off tests, tedious text manipulation, automated tasks, and simple tools. Scripts are easy to write, easy to share, and good enough to get the job done. My prof used Perl and was a whiz at it. I eventually settled on Ruby as my scripting language of choice. While the core language works really well across different platforms, as a predominantly Windows user,  I find that Ruby sometimes runs into problems in odd situations. One thing that is particularly annoying is the lack of a Ruby version manager. Version managers are a great idea

I recently returned from the O'Reilly Software Architecture conference where I presented/facilitated a workshop on Rapid Software Architecture Exploration . My workshop went great. According to the reviews it was among the better presentations at the conference -- which is awesome! But that's not what this blog post is about. Microservices architecture was a significant part of the conference with well over 50% of the sessions dedicated to the topic. And I'm being really nice in saying it was only 50% - I think it was closer to 90% and perhaps could have been called the O'Reilly Microservices Conference. Anyway, so there's a ton of hype on this topic.  And since we're looking closely at the (loosely defined) microservices architectural style for an upcoming project at work, this was a great learning opportunity. I am currently reading the book Building Microservices by Sam Newman but I thought it would be useful to share some of the insights I gleaned f

If you're even remotely a movie buff then you'll probably really enjoy Tony Zhou's " Every Frame a Painting " series.  His analytical, accessible, and entertaining film studies mini-documentaries are wonderful. Each video in the series focuses on one main idea, often something overlooked or perhaps under appreciated by other films studies enthusiasts (analysts? critics?).   This bit of analysis on what makes Jackie Chan's physical comedy so brilliant is... well, itself brilliantly done. In this episode of Every Frame a Painting , Tony discusses the idea of showing character choice rather than just talking about it, using Snowpiercer as an example: In nearly every blockbuster you've watched or tell-tale game that you've played, you've seen moments like this: the protagonist has to make a choice and there's no way to reverse it. Just to be clear, I think moments like these are great and a foundation of good storytelling but I do wish in m

George Fairbanks and I chatted via Google+ Hangout in February 2014 about agile software architecture. I think we found a groove pretty quickly and the conversation overall went great. I've created bookmarks of some of the main topic areas that we covered to make it easier to jump to bits of the discussion you might find more interesting. During this Hangout we meandered through several topics starting with walking skeletons and leading to...

The most effective way to transfer complex, abstract ideas from one person’s brain to another person’s brain is by writing the ideas down. This premise permeates our whole approach to software design.  Entire books are dedicated to creating better documentation!  Following traditional documentation advice inevitably leads to comprehensive, albeit verbose, documents filled with important details that, sadly, too few stakeholders read.  There must be a better way. Introducing the Architecture Haiku George Fairbanks  originally came up with the idea of the Architecture Haiku as "a one-page, quick-to-build, uber-terse design description."  With only one page of paper (assumed standard, A4) to work with there is no space to be indecisive or indirect.  There might not even be room for diagrams - which at first sounds crazy, but perhaps is crazy brilliant!  We tried this idea on my team and it turned out to be a great, lightweight method for writing down and sharing architectur

[I recently gave a talk for the monthly SEI Agile Collaboration Meeting. The Agile Collaboration Meeting brings together upwards of 50 or so agile practitioners from throughout the federal and DoD space including civilian contractors. This post is a summary of the talk I gave at the September meeting.] When you do a search for pictures of "unrequited love" one of the first images that comes up is this 1884 painting by Henry Holiday titled "Dante and Beatrice."  As Beatrice and Dante were Italians it is extremely important that you pronounce her name in your mind correctly – Bee-a-tree-che – using the Italian pronunciation.  In this painting you see Dante, the poet of the Divine Comedy among many other works, chilling on a bridge as he is snubbed by a posse of three women.  Beatrice is the one in yellow completely ignoring Dante, who probably went out of his way to be in the right place at the right time so he could see her. In real life, Dante was obsessed with

"Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away." -  Antoine de Saint-Exupery I was first introduced to the idea of minimalist software architecture in an article by Ruth Malan and Dana Bredemeyer , " Less is More with Minimalist Architecture " (PDF).  The basic premise is devilishly simple: the software architect's job is to " only do with architecture what is absolutely necessary to achieve key, broadly scoped qualities of your system ."  Any design decisions that do not support this goal are left to the discretion of downstream designers.