On software development metaphors, programmers and engineers

Jorge Manrubia — Sun, 29 Sep 2019 15:43:49 +0000

A tweet about how engineers should not write code (Spanish) made me revisit a subject I used to enjoy: metaphors of what software development is about. There are only one million articles about this, so let's add a new one.

The software is like engineering metaphor did more harm than good years ago. My favorite take on its problems is this article by Martin Fowler. Another great one is the gardening metaphor by the pragmatic programmers. Aiming for designs that make software construction predictable doesn't fly, and that is precisely what the term software engineering evoked back in the day.

I don't think this misconception is prevalent today, but there are still many believers in the old engineering metaphor. I saw a large government agency organize its whole development process based on this metaphor in 2013, which, not surprisingly, turned out being a very costly horror story.

A related discussion is about titles: programmers, developers, engineers, architects, etc. As it often happens with fuzzy terms, different people assign different meanings to each, so they become useless. For example, Github has engineers, Basecamp has programmers and Shopify has developers. Do they employ disjoint groups of people? Or are they just using different terms for the same role?

If we all agreed on precise meaning for each term, they might be useful, but the thing is that we don't. I think a much saner approach is to consider them all synonyms and focus on skills, background, and experience as much more relevant indicators. This way, we also prevent people from using titles like badges of honor that magically separate ones from others. E.g., an architect makes high level technical decisions, mere programmers can't.

On a more constructive note, David Heinemeier Hansson differentiated between creating information systems (writing metaphor) and building the infrastructure that supports them (engineering/hard science). I loved the writing software metaphor, as writing things down has many similarities with coding. Also, I bet many I-am-an-engineer-not-a-programmer developers would find it shocking to hear Rails creator rather identify with a software writer 😂.

Finally, while I like metaphors and the insight they provide, I have come to appreciate considering software development like... software development. It highlights the unique aspect of what we do as a discipline, and it helps to avoid digging ourselves into holes for taking metaphors too far.

Given the staggering quantity of data we have on software projects of all sizes and varieties, we can state categorically that software development is like software development. Period.

Programming quotes that blew my mind

Jorge Manrubia — Thu, 19 Sep 2019 14:42:31 +0000

I love ideas that turn my world around. They typically come via books, articles, and talks but, in some rare occasions, it is just a simple quote that produces that effect.

The impact of such quotes highly depends on your background and context. Here are three examples that, in hindsight, had a huge impact on me.

Programming habits

I’m not a great programmer; I’m just a good programmer with great habits.

By Kent Beck, quoted by Martin Fowler in Refactoring (1st ed), June 1999

When I read the Refactoring book in the early 2000s, this quote strongly caught my attention. In a time where you could often hear that programming was a second-class activity for a real engineer™ (foolishness that some still perpetuate today), books like this one, XP Explained, or The Pragmatic Programmer, placed the focus on practices for writing better and more robust code. And this quote made me want to learn about those: automated testing, the importance of readable code, implementation patterns, refactoring, continuous integration, etc.

Above all, this quote made me respect the craft of writing code. In those days, I had professors who told us that our job should be drawing comprehensive diagrams and writing long documents that others would code. Imagine having paid attention to those! I still carry a subtle and unjustified aversion to the term engineer from those times.

Feedback loop

As an engineer, you should constantly work to make your feedback loops shorter in time and/or wider in scope

By Kent Beck, November 2014

This sentence put a name to a concept that wasn't even on my radar: feedback loop. Today, I believe it is a key factor in developer happiness. It refers to the cycle of writing some code and validating its effects. You are going through that cycle countless times while coding anything, so you better pay attention to how it unfolds.

The feedback loop is often associated with automated testing. You want your tests to be fast (shorter in time) and test the real thing as much as possible (wider in scope), which are usually opposite attributes. Indeed, having an effective feedback loop is an excellent reason for writing a test, although that is not always possible or suitable.

I think testing is just one side of the problem. Here are some assorted thoughts:

Improving the feedback loop is worth investing time. For example, I created this to avoid having to use JRuby because of its slow startup time. And also this command-line tool for another system for the same reason.
A fast load time is a crucial feature for users, but it is also essential for programming happiness. Apps that are slow to load can quickly drain your happiness at development time.
REPL shells are a terrific tool for experimenting and troubleshooting in many scenarios. Immediate responses make for a great feedback loop.
When doing performance work, automate as much as possible whatever mechanism you are using. In some recent profiling work I did, just running the profiler and opening the generated report in the browser automatically with a keystroke improved my experience significantly.
When it comes to user interfaces. Modern browsers dev tools offer wonderful mechanisms for manipulating HTML and CSS directly. Hot reload in React and Vue is fantastic, as much as I don't love the SPA scene. And SwiftUI looks amazing. An immediate feedback loop is so convenient for UI work!

Scope and deadlines

“Fixed deadline, negotiable scope” has to be the most underrated pattern in product management. It’s the secret to shipping.

By Ryan Singer, October 2015

This idea just blew my mind when I first read it. Until then, I had come to consider deadlines in software as something negative. I had never thought of them as a mechanism for narrowing down scope. And it clicked because this solved two problems I was very familiar with:

Missing deadlines because finger-in-the-air estimations at the beginning of the cycle were always wrong, no matter how much you shortened the iteration.
Not knowing when a project was done since there were always pending refinements that looked so important.

Programming is a wicked problem: you don't understand the problem until after having solved it. If you are allowed to modify the scope, you can adapt the amount of pending work as you progress through the project and, that way, honor the deadline. And you also have a mechanism to decide when the project is good enough and ship.

I think this is one of those ideas that, while simple, is hard to put in practice successfully. If you are interested, the book Shape Up explains how they do it at Basecamp, and it is one of the best reads I have had in a long time.

I would love to hear about similar quotes that impacted others.

DEV Community: Jorge Manrubia

On software development metaphors, programmers and engineers

Programming quotes that blew my mind

Programming habits

Feedback loop

Scope and deadlines