In a world where software development is all about choosing the right architecture, technologies, and whatnot it is getting a bit tough to understand if we’re solving a problem or finding a new way to satisfy that itch. Do you know which one, let me try this new shiny thingy. And that one can be whatever you’re learning at that point and think it is the perfect solution for that project.

I have these conversations almost every time. Before we even scratch the first layer of the problem statement and why we need software solutions for it, I am confronted with this architecture, this and that for programming language, etc. At the start I was thinking about how people are able, sometimes with extremely complex problems, to understand what to choose after just a basic problem statement. As you can imagine, I learned it was just a common problem in any meeting. Let me just blurb the first thing out, before listening to the entire thing. We all have been there, young and know it all. In my opinion, that is a problem if we stay like that in the later stages of our software development career.

Shiny object syndrome is a definition of this. Who would be surprised, while I do think it is nice to have a clear definition of this “issue”. As just later on in the project, those same people will start screaming about overengineering and how things turned out. Again, surprise. The experience is the differentiating factor. As said, we all start from our strong points and where we feel most comfortable to voice our opinions. Nothing wrong there and that is why we work in teams. A combination of these strong points will result in a solution in the end. As long as we keep in mind what is the main problem being solved.


There is nothing inherently wrong with thinking about implementation. In real-world projects, this is the second stage of the problem statement. We are working on our projects while learning something new and shiny, a different topic. There problem you’re solving is of a different kind. You’re developing a repository of knowledge and experience. For eventual real-world problems to solve and where to apply that acquired knowledge.

More of this experience and knowledge about different approaches to problem-solving will help out when coming into contact with a real-world scenario. What is the “best” fit for this problem in front of you? How about that DDD I read last week? Or maybe a bit of Hexagonal architecture as well? That knowledge you invested should help you, with a bit of critical thinking, analyze and ask valid questions to drive towards that “best” way. These questions will narrow you towards the later implementation. Do you need to prove a concept or refactor legacy code? Is the scale an issue or do we expect 10 users? Are we talking about a back-office application or something that will be used by all kinds of device clients?

Everything looks like a nail if you think you’re holding a hammer. More often than not, even for unknown projects, we turn these things around. Well, I see that this Hello World application could be improved by a bit of DDD. And then crying months later when “hello world” becomes “hello headaches”. This is why I love watching conference talks about companies that are selling some product in the form of talk.

Everything looks great in the tutorial example. You can see eyes widening in public. The breath is being taken away in a carefully orchestrated happy path scenario. You come back from it, inspired and questioning how you ever lived without this new way. You sell it to your management. Or usually the other way around. And then the first real-world scenario that doesn’t fit the paradigm, the questions start. Head scratching begins and we’re back to hacking things together. Feature of hours now requires the entire development team to figure out how a hammer can’t help with a screw. Maybe if I hit it harder, it will go straight.

Use that knowledge you developed to form the question that will identify things in the short and long term. So you don’t shoot yourself in the foot because you forgot to ask what happens after that PoC phase of the project? Combine that knowledge with a bit of critical thinking, so you can next to your clients/stakeholders contribute towards the project. In a way that all sides benefit from it and not just that itch we need to scratch to try something new and shiny. For no apparent reason.

Don’t get me wrong. I spend a lot of my “free” (read unpaid) time learning new things and challenging my experience with a new way of thinking. At the same time, it is not that the next thing on my to-do list, or backlog, is to have it run in the production of my project.


This is why, in most real-world scenarios that most developers work at, the Project thinking is for me a way to go at the start. When I understand the problem, to some level of clarity I can form, I will know what to build and deliver. Then I will form, based on the experience and to the best of my ability, an opinion on how to implement it. Most people that I worked with know one of the things I often say in cases of unclarity.

💡 If I can’t clarify to myself what is expected out of me, I am certain that the thing I will deliver will not be what is expected.

I prove this to myself, let alone witnessing it, every month. When a problem/feature is unclear or there is no “common” understanding. It will be in the ballpark, but maybe not just right. Clear communication is underappreciated in the software development until that fateful demo. Yeah, seems like something I had in mind, but…. There are numerous documented best practices on how to do problem statement exploration. And translate the abstract ideas with some mixed-in hand waiving into something that can be usable after implementation. And this is not just for the business side of the project. Developers are the ones that need clarification, and it is in my experience it is easier to change my way of expressing my opinions. Then the other way around. Nothing wrong there, let me make it clear.

It is not easy and sometimes I need to read several things I never imagined needing to understand. Then, on the other hand, it helped me to have more effective meetings when talking about features and what needs to be done. Instead of a business talking about something they understand and me talking about classes and bounded contexts. It is needless to say meetings take longer in these mismatches of communication. The question is just what is the exponent on that original time planned? Yes, sometimes problem domains are fun and you can dive deep into something that will tickle that curiosity. And sometimes, it is not. Still, it is worth it just because of stress and cognitive load reduction.

And the proponents of all kinds of implementations, like DDD should be the first ones to jump on this bandwagon. Domain Drive Design. Use cases. Whatnots. There are no semantics in those word definitions in my opinion. Clear and cut and not open to interpretation. But somehow it still turns into a fun discussion every time. Desclaimer; Sarcasm doesn’t translate clearly in the written word, or so I’m being told.

No matter what paradigm you have chosen to follow, I believe that thinking along and talking with your counterparts at the same level will make your understanding higher. And consequently your code cleaner. Whatever that meant.


I hope that till now it is clear that these are not mutually exclusive. I am arguing towards making Project thinking first and complimented with questions from the Implementation side to understand the scope. And what should be engineered from the get-go and just deleted and redone again, when an idea has been proven?

Understanding the problem statement you’re being involved in solving helps in the short and long run. Talking code is easy when you understand what you need to build. Where to invest time, what is expected to be done, and so on. Where it is very helpful is to have a productive and constructive conversation with your peers. They are not interested in talking about the latest and greatest programming language features. Keep that outside of the meetings and when you’re back behind that mechanical keyboard.

This is not the case for every project, naturally. Tailor your conversations towards the audience you’re talking with. While still even when talking about problem statements with fellow developers, it is still good for me to have discussions away from implementation details. At least for the portion of the discussion till the problem statement is clear. And why we need to do this or that. I had so many conversations about refactoring some piece of code, not because there was a problem in there to solve. It was just for the sake of it, while there were fires in other places. That, I can’t reason for, even with the best of intentions.

There is nothing better for me than being stuck in a meeting discussing why we’re even there. And then you mix in some tech speak for a good measure and you can already start booking a meeting for a follow-up session.

Until next time!