PROMOTE INNOVATIONS: YES, YOUTH RESEARCH: NO
When I was still a "pure" coder, I didn't like it at all when my urge to test ride every new pig that came through the village was stopped by these stingy IT controllers. Felt like Daniel Jet Gear was being put under the reins by Scrooge McDuck.
But like bull riding in the Western, it wasn't uncommon for the beast to throw me off. In other words: The technology wasn't ready yet, or I wasn't.
Even today I am still skeptical when it comes to not stifling innovation by rejecting ideas without any reason.
However, today as a senior software architect I would add a clear BUT. I am still in favor of the fact that there should be reasons for slowing down innovation. There should also be reasons to test innovations. And they shouldn't just consist of the youth research urge.
Because in the projects I work on, it's not the university that pays for our work, but the customer. And he doesn't always want Ado Goldkante, but simply a functioning curtain in front of the window. And it should work even when the sun doesn't shine on the new fancy IoT solar AI button.
Take microservices as an example. From my experience, these are the measure of all things in many projects, without caring about the consequences, also known as the microservices tax: shifting the complexity from the individual services to the interaction and deployment of the services. There are still old VMs running that have to be ordered from a third-party provider two weeks in advance, but the wet dreams are in the direction of highly scalable Kubernetes clusters. The fact that this requires highly specialized DevOps engineers was initially ignored. Likewise, the fact that the end customer who has previously received an exe will certainly not cry tears of joy if 50 cluster tubes are suddenly placed in front of his door. Happy Holidays!
As is the steep learning curve for everyone on the team when it comes to Event Driven Architecture and Domain Driven Design. Because how do you want to cut microservices if not domain-driven?
Would you like another example? If you use GraphQL when REST is sufficient, you often end up with a coupling of frontend and backend that makes changing UI technology impossible, and a codebase that is unnecessarily bloated by type generation. < /p>
The result of such willingness to experiment:
Accidental complexity is introduced.
The worst evil. Actually can only be eliminated by (senior) exorcists.
The first symptom of complexity is that a seemingly simple change requires code modifications in many different places. Change Amplitude called.
The second symptom of complexity is the cognitive load, which is expressed in how much developers have to know to solve a task. A higher cognitive load means more time has to be spent learning the required information and therefore there is a greater risk of errors creeping in.
The third symptom of complexity is that it is not obvious which pieces of code need to be modified to complete a task or what information a developer needs to have to complete the task. Of the three manifestations of complexity, the unknown unknowns are the worst.
In the end, projects can fail because of this.
And then no one will pay for the Youth Research projects anymore.
How can you counteract this?
Don't be too junior, because old hands often recognize the latest pig that is being driven through the village as old wine in new bottles and/or as a ticking time bomb. Just use the micro-frontend framework Mosaic. Years ago hotter than hot. Now deader than dead.
The manager must create awareness that whoever pays for the music also has to decide what is played. Keyword: Set clear goals and expectations.
SCRUM: SOMETIMES TOO SOFT => OCCASIONALLY TABLETOP ERUPTIONS ARE NEEDED
What do I mean by that?
When I was a developer myself, I would never have said that, but today I see it a little differently. A growth mindset is characterized by the fact that it learns. Ok, neuroplasticity sounds even hotter...
I once had a team on a project that was extremely enthusiastic about discussions. And when I say extreme, I mean extreme. It could happen that hours of discussions were held without results, which is one reason why I now use the Lean Coffee concept for many meetings, especially since I like to chat around a bit, which is only human.
Lean Coffee also has another big advantage: by limiting the amount of speech, even the quiet ones can be heard. And they often have much more to contribute than they are given credit for. Unfortunately. Not “unfortunately” because they have more to contribute, but “unfortunately” because we often equate being silent with knowing less. And says an extrovert like me. But I know how that feels. For me, it's my martial arts visage and figure that makes some people doubt my intelligence. We humans still have enough of the Stone Age left in us. You're not in my fur clan, you're a doodie.
But back to the discussions. If you don't put an end to this, then the following happens:
"Excessive complexity is nature’s punishment for organizations that are unable to make decisions."
(c) https://architectelevator.com/gregors-law / (last visit @: 2023-12-20 - 16:59)
So we would have the problem of purchased complexity again.
And now comes the bow to Scrum. If you have a team like this where these discussions lead to delayed or even prevented decisions, then the complexity increases. Do you remember the (senior) exorcist who needed to be called? What now with autonomous teams?
Yes, I'll give you time to think. I also needed you when I faced such a situation.
My answer: hit the table or let it hit. As an architect and also as a freelancer, I am not the disciplinary superior of the team members. But then he or she has to intervene, because if that doesn't happen, then there will soon be no team anymore. After all, there will be no more projects.
At least that's my opinion.
And a little anecdote: When I was doing my law clerkship at the public prosecutor's office (it felt like a hundred years ago), an intensive offender (juvenile criminal law) thanked me for being the first public prosecutor ( in training) who finally demanded a youth sentence for him, otherwise he would probably never have gotten away from his crimes. I was completely amazed at the time. When I had this banging on the table done in the project mentioned earlier, the reaction was almost the same. People expressed their gratitude that a solution had finally been found and that the constant discussion would come to an end.
I was just as amazed as I was back then.
But in a positive sense.
SOUL COOKIES AND NO CLASS WEDGES FOR CRITICISM
For me, the appreciation for good work (or at least the effort to do it) is one
of the most important elements, because every person needs recognition, even the quiet ones who don't always crow for it.
A culture of criticism must also be created in which introverts also dare to get rid of their worries. Otherwise, there will be a silent termination.
That's why I consider the retrospective to be one of the most important meetings in the Scrum Framework.
That was my 2 cents on the subject. I would be very happy to hear your opinion in the comments.