Recently I enjoyed working with some of my San Francisco colleagues on-site. During this visit we wanted to take time to do something a little different. So, we devoted two days to experimenting with Mob Programming on some exploratory work. Over those two days we discovered a number of things about Mob Programming as well as the work we were exploring. While we didn’t all walk away with the same insights, we all agreed that Mob Programming was a technique we were interested in trying out some more.

Exploring a Problem

The team I currently work on is responsible for our Master Planning solution for resource managers within professional service organizations. This system provides a way to identify what kinds of personnel are necessary for various projects, including the required skills, availability, and other factors. This tool also enables the assignment of specific personnel to these defined areas of need. In order to do their work effectively, resource managers need to be able to adequately filter and organize their view of projects and personnel. …


A scuba diving instructor leading a class in pool exercises.
A scuba diving instructor leading a class in pool exercises.

The work of software architecture belongs to every developer on a software team. So, what is the role of those given the title Software Architect? At its most basic, I believe it is to be a leader in mentorship of their teams. They should be excellent developers in their own right, promoting their team’s principles, refining their team’s practices, and guiding their fellow developers toward the same.

Other Responsibilities

Many understandings of the role of software architect incorporate a variety of seemingly non-technical responsibilities. And, I believe those other concerns are valuable; but I’m not sure of their primacy. I think Gregor Hohpe’s perspective is a helpful one, although it is connected to ideas tied up in traditional IT structures in many respects, as well as the particular concerns of certain larger organizations. …


The discipline of software architecture, and the role of the software architect, remains somewhat nebulous after nearly 30 years of prominence. Its origins go back even further, and it derives from an straightforward analogy. That analogy is to the field of civil architecture. But, the closer we examine this analogy, the less it seems to hold up.

Image for post
Image for post

Considering Civil Architecture

Civil architecture is often conceived as a planning and design endeavor. However, it is easy to miss that the planning and design is not merely abstract. Varying levels of detail tend to be included in a set of architectural drawings. It is also not unusual for the architect to collaborate closely with civil engineers and others involved in construction. This leads to the work of the civil architect being nearly equal parts prescriptive and descriptive. …


Image for post
Image for post
Photo by energepic.com from Pexels

At almost every company there is some level of pressure to work overtime. It gets couched in language about mission, impact, hustle, and other euphemisms. Positive employee recognition usually comes to people willing to work the extra hours.

“Joe really went that extra mile to help us meet our goal. Staying late, coming in on weekends. He really sacrificed for our mission.”

Thankfully, I’ve never worked anywhere where my aversion to overtime was denigrated. But, praising overtime is ridiculous. Overtime is a sign of problems that should never receive praise. Ever.

At its most basic the need for overtime reflects a breakdown in professionalism, priorities, and agility. I’m primarily concerned with overtime for software development organizations. But, the negative effects it has on productivity and quality can be observed in any context. …


Image for post
Image for post
“Freedom” by Sebastian FussSome Rights Reserved

Back in the early 2000’s I got into a discussion about the relative merits and problems with Free and Open Source software. One of the points of discussion was the first freedom identified by Free Software:

The freedom to run the program as you wish, for any purpose

This same freedom is identified in article five of the Open Source Definition. The point of that discussion was about the moral position of free and open source software as it related to proprietary software. My counterpart proposed that any software that was not free or open source was morally evil, while I defended the rights of creators to determine the bounds of their software’s use. I still stand by my position and will not retread it here. Any software developer has the right to define how and by whom their software can be used. But, I also believe that free and open source software is superior to proprietary software for many reasons and in many circumstances.


Norman Geisler recently wrote about why he thinks the firing of Paige Patterson was a mistake. From the title of this post it should be obvious I disagree. I want to address some of Geisler’s specific concerns, but first I want to lay out my biases.

I have never been a fan of Paige Patterson. I have never had any direct interactions with Patterson. But, my observations of him over the years has led me to not find much room for agreement with him. The notable exception is that we both love the Southern Baptist Convention and its mission. …


Image for post
Image for post

How should we decide what to work on? Answering that question is the key to all software development processes. In my experience a lot of programmers, developers, and engineers are bad at answering it.

Technical Debt

This is the elephant in every room; at least in every room containing software developers. If there is software running somewhere, there is technical debt somewhere. At least, something some developer would identify as technical debt. And, developers love to address technical debt. Or, rather, they love to talk about addressing technical debt.

I like talking about technical debt. I like addressing technical debt. But, I and many others enjoy discussing the problem most of all. It’s the easiest way to feel high minded and like we are experts at something. We all want to be pundits. And, nothing inspires punditry like the subject of technical debt among software developers. …


Image for post
Image for post

Every company I have ever worked for had some. Few seemed to want to deal with it, and even fewer were confident they could. Legacy Code is a fairly consistent, and strongly pejorative term within software development. But, is that a good thing? Over the last several years I have come to think that it is not. And, after hearing Chad Fowler present his keynote at RubyConf 2017 titled “Growing Old,” I have been reinforced in that opinion.

Defining a Legacy

One of the big themes that I took away from Chad Fowler’s talk was the reminder that in every other field of endeavor the idea of Legacy is a good thing. A legacy is typically thought of as a gift left by prior generations. Sometimes that gift is knowledge, or money — Yet, in the realm of software development the notion of what is left from one generation of programmers to another is very rarely viewed in a positive way. …


Image for post
Image for post

I am of the opinion that any code that does not have accompanying automated tests should be considered inherently defective. When we write code we have certain notions of suitableness in mind. Tests are a way to express those notions in a way that others can run, and examine, independent of having to delve into our actual implementation. Tests provide a way to communicate about the code we write in regards to what it does, not simply how it does some thing. …


Image for post
Image for post

When we build software it can sometimes feel like a precarious balancing act. Will this next bit of code do what we expect? Will something we did not change begin behaving strangely? Certainty and confidence are not always feelings close at hand for many software developers.

Being able to answer these concerns with greater confidence is why software tests are so important. For over a decade now I have been a consistent practitioner of Test-Driven Development. It has made me a better software craftsman and helped me move from programmer, to developer, and now to the point where I consider myself a software engineer. …

About

James Thompson

Hands-On Software Architect — Conference Speaker

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store