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.
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.
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!
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.
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.
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.
What a bad video this was... zero "practical" knowledge in it, just random platitudes and abstraction. Without concrete examples and cases, showing bad vs good, this is basically useless, I'm sorry.
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!
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.
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!
Great video! I'll share it with the teams!
Thanks for sharing
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.
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.
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.
1.) Not understanding the domain boundaries. 2.) Religiously adhering to software abstractions that may not provide actual benefits.
Agree on both
So basically it means to follow Single Responsibility Principle
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.
What a bad video this was... zero "practical" knowledge in it, just random platitudes and abstraction.
Without concrete examples and cases, showing bad vs good, this is basically useless, I'm sorry.