No doubt many people will have read the story about how an error in a piece of software has prevented a number of women being invited to a standard screening. The current estimate is that this could have led to as many as 270 lives being lost or curtailed, although it will be difficult to say for some time. As a ex-CTO in a healthcare business, this is the type of problem that used to keep me awake at nights – a small mistake leading to tragic results. How did this happen?
My estimable Twitter-pal Paul Johnson has put together a very reasonable thread about his thinking on serverless costs (ie. AWS Lambda, in this case). He makes a great case for the design of functions being done in such a way as to allow cost efficiency improvements, and I think the point on architecture is generally well-made. However, there are a few aspects of this which I think are generally not well understood, and Twitter is much too short a form to get them in. Hence this post.
Steven Sinofsky of a16z (previously Microsoft) probably first coined the phrase, “Don’t ship the org chart”. I think there’s a new variant of this worth discussing: shipping the microservices. I’ve been reviewing a few products in depth recently for different reaasons, and once you see it, it actually becomes really obvious.
This evening’s RedMonk article on linguistic prescriptivism is, as usual, excellent reading. Does it matter what people call things? Is the intent behind the name something significant, which should be respected?
In computer science we “have form” on this subject. The names or symbols we assign to things are very clearly different from the values involved. We might write
1.999..., and these symbols are distinctively different from the concept of two-ness, and indeed in another language we might write a two using very different symbols, like
(() ()). Often this logic gets carried forward into other areas – somewhere else on Twitter, a discussion about Serverless was happening.
I doubt there has ever been a time when software architecture was seen as a raging success. The “three-tier architecture” of the web has held up extremely well and is an excellent place for many people to start. The “12 Factor App” approach has encouraged developers to adopt practices that make deployment and scaling much simpler. Over the last couple of years, though, I’ve noticed developers advocating for architectures I consider to be extreme and limited in utility, foisting highly complex systems into startup environments at great cost. It appears to me to be getting worse.
RedMonk published a great article today on the incompleteness of technical debt as a metaphor. This touches on a number of points, the best one I think is that for many people in business, debt just isn’t a “bad per se” thing. Technical debt, more often than not, is.
I completely agree with the analysis. Presenting technical debt as risk is a more accurate picture a lot of the time. While it’s potentially even more accurate to relate them to other financial instruments (my favourite is the “uncollateralized technical debt obligation”), it’s much more difficult to relate to.
I’d like to share the simile I use.
Millions of words are expended on software architecture. Fashions come and go; some patterns last a long time, others are a flash in the pan. One day, Model-View-Controller is all the rage. The next, it’s Model-View-ViewModel. So on and so forth – the next new architecture is the One True Way or a genuine silver bullet, until it’s not, at which point it’s legacy, technical debt or code smell.
Developers talk too much about architecture. In the future tense, it’s always what the next architecture is going to enable them to do, what problems it will solve. In the past tense, it’s usually about what the architecture prevents them doing, why the architect was bad, why it’s the wrong pattern, etc. Static architecture design is the wrong thing to think about, and here’s why.
People sometimes ask me about the structure of our internal development team, and to what extent we’re truly “agile”. My response is that we’re actually more “lean”. I happily give examples of some of the key working practices we have. I generally don’t explain the difference between “lean” and “agile”, though.
Sometimes, people use these terms interchangeably. I think this is wrong, but understandable. As a JIRA user, I’m used to it offering a Kanban board to run a scrum sprint. This can be a great choice, but it muddies the waters. Let me take this opportunity to explain my thinking then!