Over the past two years, I analyzed with a couple of colleagues how we judge how much quality is “good enough”. Such a statement is usually an outcome of a discussion and a consent that needs to be found on every different project and every different company.
It is also quite different, depending on your product life cycle. This talk starts with this “balance” of how-much-quality you need and investigates how this knowledge can be taken into the interactions of you and other people in the team.
For the entertainment part, it’s wrapped into an cheesy story about ancient gods and titans – arguably a bit too cheesy 😉
Yes, I am a Trekkie. And while I usually do not share such stuff it is the little bit of context setting I need for this blog post.
Since everyone moved to their home offices in the wake of corona, our team put some deliberate effort into their ceremonies, to make them something “special”, to compensate for not meeting IRL any more. Thus, I had the honor to design our first online retro. I received fantastic feedback, thus I thought it may be quite interesting for others to try something like this, too.
I chose a format that I call 2 : 4 : 8 (I believe I found this label somewhere else, but unfortunately, I wasn’t able to dig it up and link to it again).
The idea of the format is the following: In normal Retros there are up to 10 devs and 2 – 3 other roles. Due to the nature of the roles, also a lot of tech problems are usually shared. In the democratic dot-voting afterwards, the developers often promote the tech topics. I am not saying that this is bad intention, it’s just a natural outcome based on the interests of the different groups in a retro.
To avoid this effect, we went for a format which supports “minorities” and focuses on how important a topic to a certain person is. In this format usually topics come up that are super important to some people but can in the other format never be shared other than in a side note. It’s a very inclusive retro edition.
Here is how it works:
each person writes down what the two most important things are to them. There is no categorization: could be things to start or stop or change or …, there is just limitation that it could only be 2 things in total for each person. (Most retros allow unlimited amounts of contributions but restrict the categories, this was the other way around: unlimited/no categories but restricted to 2 contributions).
after each person found two issues that were most important to them, the participants were paired up. Then, 2 paired-up people need to agree on the most 2 important thing inside their pair. (So 2 people each bring 2 topics = 4 issues in the pair. Then the pair needs to pick the top 2 of them)
after the pairs found two issues they go into group discussion (2 pairs = 4 people now). Again, they should discuss the two most important issues.
finally, all get together with a total of 4 issues left. They are discussed, action items are derived and assigned. Finally, the retro is closed.
So I wrapped the retro into a Star Trek Story. I used the video conferencing system Zoom which allowed me to share video and audio from my computer. And it allowed me to design “breakout rooms” which I could then assign to the people. This was particularly helpful to have all the different discussions with different amounts of people. I also used google slides as the collaborative tool.
I think one can make it work with any tool and there are tools out there which work even better. This combination was just handy for me and I will use this as the example tool going forward.
Setting the Mood
Before the first people joined, I started my screen sharing with the presentation. The first slide had a video and background music. In this way, the people who joined early had a bit of space themed ambience music while waiting. That was already a positive and freshly surprising start.
After officially starting the retro, we watched a tiny teaser to get into the Star Trek mood:
We followed with a “Weather Check” to see how everyone felt and continued with a “Safety Check” to understand if the level of trust in the Retro was high enough. I used an anonymous google form to collect that data, that was a bit cumbersome to set up but an easy, quick and secure way to collect this information.
After that, we went into the 2 : 4 : 8 exercise: The Google Presentation Deck was shared with all and each person randomly picked a Star Trek movie character and wrote (5 min timebox) 2 things to change or stop or improve.
Then the people were asked to team up. There were prepared zoom breakout rooms in the call with names fitting the theme (“Bridge”, “Captain’s Ready Room”, …). On one slide there was a pre-selection which characters would meet in which room. In this way it was a random meet & mix of people who would share their thoughts.
After the pair discussions, we came back once more and divided into two groups with 4 or 5 people, each. Then both smaller groups reported the two main issues back to the whole group and we discussed actions for them.
This gave us quite some action items for 4 issues we found. It also turned out that no-one in the team (but me) watched Star Trek. However, everyone enjoyed the retro and some said it was “the best they ever had in their live”.
The full slide deck is here as a PDF. This is for inspiration, I don’t think that one could just copy & paste the whole thing.
This is a template for the retro. We were 9 people + me facilitating, thus, this is how it’s structured. The format itself also works for 30 people.
When great thinkers think about problems, they start to see patterns. They look at the problem of people sending each other word-processor files, and then they look at the problem of people sending each other spreadsheets, and they realize that there’s a general pattern: sending files. That’s one level of abstraction already. Then they go up one more level: people send files, but web browsers also “send” requests for web pages. And when you think about it, calling a method on an object is like sending a message to an object! It’s the same thing again! Those are all sending operations, so our clever thinker invents a new, higher, broader abstraction called messaging, but now it’s getting really vague and nobody really knows what they’re talking about any more. Blah.
When you go too far up, abstraction-wise, you run out of oxygen. Sometimes smart thinkers just don’t know when to stop, and they create these absurd, all-encompassing, high-level pictures of the universe that are all good and fine, but don’t actually mean anything at all.
These are the people I call Architecture Astronauts. It’s very hard to get them to write code or design programs, because they won’t stop thinking about Architecture. They’re astronauts because they are above the oxygen level, I don’t know how they’re breathing. They tend to work for really big companies that can afford to have lots of unproductive people with really advanced degrees that don’t contribute to the bottom line.
A recent example illustrates this. Your typical architecture astronaut will take a fact like “Bitcoins are a blockchain service to exchange money anonymiously” and ignore everything but the architecture, thinking it’s interesting because it’s blockchain, completely missing the point that it’s interesting because it allows to exchange money anonymously.
All they’ll talk about is blockchain this, that, and the other thing. Suddenly you have blockchain conferences, blockchain venture capital funds, and even blockchain backlash with the imbecile business journalists dripping with glee as they copy each other’s stories: “Blockchain: Dead!”
The Architecture Astronauts will say things like: “Can you imagine a concept like Bitcoin where you can exchange anything, not just money?” Then they’ll build applications for supply chains that they think are more general than Bitcoin, but which seem to have neglected that wee little feature that lets you send and receive money without giving away your name — the feature we wanted in the first place. Talk about missing the point. If Bitcoins weren’t blockchain but they did let you swap money anonymously, it would have been just as popular.
Another common thing Architecture Astronauts like to do is invent some new architecture and claim it solves something. Kotlin, ProtoBuffer, REST, RabbitMQ, GraphQL, IOT, Micro Services, oh lord I can’t keep up.
I’m not saying there’s anything wrong with these architectures… by no means. They are quite good architectures. What bugs me is the stupendous amount of millennial hype that surrounds them. Remember the Microsoft .NET white paper?
The next generation of the Windows desktop platform supports productivity, creativity, management, entertainment and much more, and is designed to put users in control of their digital lives.
Currently, the Apple MacBook Pro whitepaper claims:
Processor and Memory working at the speed of thought
Oh, good, so now I can finally stop thinking on my own since apple found a way to cut years of advance research in quantum computing and artificial intelligence.
Microsoft and Apple are not alone. Here’s a quote from a Sun Jini:
These three facts (you are the new sys admin, computers are nowhere, the one computer is everywhere) should combine to improve the world of using computers as computers — by making the boundaries of computers disappear, by making the computer be everywhere, and by making the details of working with the computer as simple as putting a DVD into your home theater system.
And don’t even remind me of the fertilizer George Gilder spread about Java:
A fundamental break in the history of technology…
That’s one sure tip-off to the fact that you’re being assaulted by an Architecture Astronaut: the incredible amount of bombast; the heroic, utopian grandiloquence; the boastfulness; the complete lack of reality. And people buy it! The business press goes wild!
Why the hell are people so impressed by boring architectures that often amount to nothing more than a new format on the wire for RPC, or a new virtual machine? These things might be good architectures, they will certainly benefit the developers that use them, but they are not, I repeat, not, a good substitute for the messiah riding his white ass into Jerusalem, or world peace. No, Apple, MacBooks are not suddenly going to start reading our minds and doing what we want automatically just because they got a new processor. No, Sun, we’re not going to be able to analyze our corporate sales data “as simply as putting a DVD into your home theater system.”
Remember that the architecture people are solving problems that they think they can solve, not problems which are useful to solve. gRPC may be the Hot New Thing, but it doesn’t really let you do anything you couldn’t do before using other technologies — if you had a reason to. All that Distributed Services Nirvana the architecture astronauts are blathering about was promised to us in the past, if we used DCOM, or JavaBeans, or OSF DCE, or CORBA.
It’s nice that we can use GraphQL now for the format on the wire. Whoopee. But that’s about as interesting to me as learning that my supermarket uses trucks to get things from the warehouse. Yawn. Mangos, that’s interesting. Tell me something new that I can do that I couldn’t do before, O Astronauts, or stay up there in space and don’t waste any more of my time.
All I did was to replace the mentioned technologies in this 19 year old text with recent examples, as my friend and former colleague Herman Vöcke suggested on Twitter.
The result is an up-to-date blog post. And what does that actually mean?
It means that while we developers like to concentrate on solving technical problems we still have to – also after 19 years – solve problems in the real world. And it is a good example of how everything old is new again in our industry.