The biggest mistake I see for a few years now is the lack of prototyping and reaching a common understanding of what our system should do together with the business through trial and errors. Good software is not planned in advance. Good software is reached by iterating, but somewhere in the Abyss I call Scrumfall or Watergile there sits a manager who quite literally wants to mark the SW you are developing as done in their Excel sheet asap.
Love this video. Learning to accept the imperfection in modelling rather than going down the perfection rabbit hole. Wish I had understood this earlier in my career!
I think a big problem I ocassionally also fall into is trying to make things perfect in the first attempt. Looking back at a few projects, it's common to be thrown into a new problem space and trying to nail it the first time ahead of starting the work. Whenever I start to reevaluate the big picture after some time, I notice how much I (and the domain experts even!) learned about the domain and how many things might have changed, so constant reevaluation is a big one for me.
I think, as developers, we fall in develop quickly, I think we are very inpatients, we want to write lines of code without having good requirements we have to do, without talking with domain experts. I think we must be more patients, understand we have to do, have good requirements, good use cases descriptions, and then deliver as soon you can and learning about your domain.
Ubiquitous language (UL) lives inside a bounded context. That said, there is not "the" UL, but several of them. As you said, context and perspective matters, and the Bounded Context ist that context for your UL. That's why we should never strive after one unified Model.
Who’s responsibility is it to define these domains and bring the end users together? I can’t imagine that all falls on the developers. How do other roles fit into this process such as business analysts, team leads, IT managers…etc?
The issue with having perspective and being clear on the contexts is that developers as people might find it difficult to put themselves in other people's shoes. It's not just about realizing the context of the problem you are trying to solve, it's about being an empathetic person, being able to put on different glasses/pairs of shoes. It's a soft skill, not a hard technical one. In light of this developers should try to focus more on their self-development efforts into interpersonal skills.
In this video there was a tip about "perspective". Kind of amusing, as it may be obvious to you, but it isn't to everyone. As for "technical" mistakes, you're referring to when in actual code implementation?
It would be hard to point out because by definition it would highly depend on the problem domain. Biggest indicator I would imagine is excessive chatter between two "unrelated" services.
Learn more about Software Architecture & Design by subscribing to my newsletter.
🚀mailchi.mp/63c7a0b3ff38/codeopinion
The biggest mistake I see for a few years now is the lack of prototyping and reaching a common understanding of what our system should do together with the business through trial and errors. Good software is not planned in advance. Good software is reached by iterating, but somewhere in the Abyss I call Scrumfall or Watergile there sits a manager who quite literally wants to mark the SW you are developing as done in their Excel sheet asap.
These concepts are the first things that should be taught in programming courses.
Great content, thanks!
Glad you think so!
Love this video. Learning to accept the imperfection in modelling rather than going down the perfection rabbit hole. Wish I had understood this earlier in my career!
I think a big problem I ocassionally also fall into is trying to make things perfect in the first attempt. Looking back at a few projects, it's common to be thrown into a new problem space and trying to nail it the first time ahead of starting the work. Whenever I start to reevaluate the big picture after some time, I notice how much I (and the domain experts even!) learned about the domain and how many things might have changed, so constant reevaluation is a big one for me.
Great video! I'll share it with the teams!
Thanks for sharing
I think, as developers, we fall in develop quickly, I think we are very inpatients, we want to write lines of code without having good requirements we have to do, without talking with domain experts. I think we must be more patients, understand we have to do, have good requirements, good use cases descriptions, and then deliver as soon you can and learning about your domain.
Ubiquitous language (UL) lives inside a bounded context. That said, there is not "the" UL, but several of them. As you said, context and perspective matters, and the Bounded Context ist that context for your UL. That's why we should never strive after one unified Model.
Who’s responsibility is it to define these domains and bring the end users together? I can’t imagine that all falls on the developers. How do other roles fit into this process such as business analysts, team leads, IT managers…etc?
It is call a Domain Model for a reason. Focus on the problem your are solving in that domain.
So basically it means to follow Single Responsibility Principle
1.) Not understanding the domain boundaries. 2.) Religiously adhering to software abstractions that may not provide actual benefits.
Agree on both
The issue with having perspective and being clear on the contexts is that developers as people might find it difficult to put themselves in other people's shoes.
It's not just about realizing the context of the problem you are trying to solve, it's about being an empathetic person, being able to put on different glasses/pairs of shoes. It's a soft skill, not a hard technical one.
In light of this developers should try to focus more on their self-development efforts into interpersonal skills.
Biggest mistake is to start on the modell
This was disappointing, was hoping for actual concrete domain modeling mistakes from a technical perspective. The rest of it was obvious.
In this video there was a tip about "perspective". Kind of amusing, as it may be obvious to you, but it isn't to everyone. As for "technical" mistakes, you're referring to when in actual code implementation?
It would be hard to point out because by definition it would highly depend on the problem domain. Biggest indicator I would imagine is excessive chatter between two "unrelated" services.