As startups evolve, their product changes frequently. Instead of focusing on the best possible product though, they should focus on awesome teams. A truly agile, passionate and intelligent IT team can quickly adapt to changed objectives and create different products over time. Through this lens, the software that is created can be considered as a mere byproduct of a well-functioning team. A team that has fun working and builds high-quality software on the side. Here’s how.
Category: IT Consulting
Software developers sink a tremendous amount of time into boilerplate code. Code that does not bring any business value and is just there to “make things work”. Over the years, in some areas our community managed to reduce boilerplate code significantly. Projects like Spring Data Rest for instance remove the hassle of writing boilerplate code to access data from a database and map it to entity objects. It even removes the need to write controller code. But is that enough? This article implores more radical steps to avoid or remove boilerplate code.
Teams use microservices and microfrontends to reduce mental load, decrease accidental coupling of unrelated code, to deploy independently, for fast feedback loops and CI runs, to isolate issues or to scale with team size. In a microservice architecture, you should avoid shared dependencies or a common core library. To be more precise, don’t share libraries that increase coupling.
As IT professionals, we know that. However, despite our best intentions, shared dependencies sometimes creep in and cause issues. From what I’ve seen, here are the most frequent occurrences in the backend:
For every problem, there is a multitude of solutions. Helping clients to find the ideal solution for their issues, is what a consultant does. In this article, I’ll tell the tale of a very German printing problem, that may or may not have really happened. I’ll present three possible solutions, one of them I consider worthy of the ‘perfect consultant’.
Printing…? Like most IT professionals I have a love-hate-relationship regarding printers. These machines seem expensive, loud, slow and often unnecessary, on the other hand, finding a solution to the arcane art of printing (article in German), is always fascinating.
While working on an IT project, thousands of decisions are made. One of the most important tools to handle the project, are decision logs. Most articles praising the benefits of decision logs focus on how they help to make, remember or fine-tune a decision. The biggest value I see however is, that decision logs can prevent repeating costly mistakes. Consider them as a safety net as powerful as 100% automated test coverage. In order for that to work though, you need to write proper decision logs. I’ll tell you how.
There’s an old saying in Tennessee — I know it’s in Texas, probably in Tennessee — that says, fool me once, shame on — shame on you. Fool me — you can’t get fooled again.Georg W. Bush
It seems to be a generally acknowledged truth (often bolstered by Reverse Conway’s Law) that decisions regarding the software systems you build should take your team size into consideration. That often leads to the belief that there is a fitting system architecture for small, medium-sized and big teams. That’s wrong.
As a software developer, I’m used to the concept of vertical slices. They allow to be able to deliver value earlier, to iterate faster, or to create a proof-of-concept for evaluation/presentation. In software vertical slices are superior to horizontal ones (feel free to prove me wrong in the comments).
In other industries, this is not necessarily the case. Imagine pouring the foundation for a living room first, then building its walls, electricity etc. After everything is done you’d do the same for the kitchen. This would not only be ridiculously expensive, but also dangerous during earthquakes.
Despite building foundations though, there must be cases where the vertical slices make sense for non-digital industries, right? And with “make sense”, I mean
- valuable for customers
- valuable enough so that they’d actually be willing to pay extra for it*
* because these small slices create overhead and therefore may be costly
Let’s look at some fun thought experiments. The following examples are from industries I have honestly no clue about, so feel free to correct me in the comments: