3 ms·
> business requirements change and suddenly your code organization is wrong Agreed, and another important case is when you just learn something. The beginning
by wpietri 4y ago
> business requirements change and suddenly your code organization is wrong
Agreed, and another important case is when you just learn something. The beginning of a project is when we know the least about the domain. Some early assumptions will be wrong! And that's great as long as we've optimized our team's process for learning. Indeed, that can become a strength, where we release new things specifically to learn. Learn about our users, about our domain, about our technical notions.
- tylerchurch 4y agoYeah, it seems to be a rule that once something is in the hands of users, things that sounded great in theory turn out to be bad in practice. Or things work so well that new (previously unimagined) improvements become obvious.
- guskel 4y agoIf you get organized about building the domain, such as using an ontology, this can be mitigated.
- wpietri 4y agoMaybe? It depends a lot on the domain. If it's stable and well-understood, pre-development research can help, both the academic kind and the anthropological. But otherwise, the fastest way to understand the domain may be to ship early and often, while doing lots of user and use observation. And that latter approach teaches you things no amount of pre-development research can, like the right intermediate concepts as you turn human concepts into things that work well for the computers, the users, and the developers. As an example, consider the social media domain when Facebook launched. No amount of ivory-tower ontology-building would have given them the right conceptual model up front, because the domain co-evolved through interactions between users and platforms.
- ajmurmann 4y agoAs Sandi Metz put it: You will never know less than you know now.
- eru 4y agoThat seems overly optimistic. Knowledge can get lost. Both on an individual level and on an organisational level.
- drewcoo 4y agoAnd you'd think someone with three decades of experience would have seen the cycle of software "novelty", ignorance, and rediscovery turn a few times. https://sandimetz.com/about/ https://sandimetz.com/about/
- ajmurmann 4y agoGiven the context this came from, I think it was about how to model a particular problem in the context of a current project, not an absolute statement.
- ajmurmann 4y agoHaving worked a lot on a 20+ year old code base I definitely appreciate your point. I think the time frame in the context the quote came from is more limited though with the point being that if you can delay an important design decision/lock-in till next sprint or month, do it.
- eru 4y agoOh, definitely. And I appreciate the sentiment. Also you might want to fight against forgetting by writing things down. Both individually and as an organisation.
- rapnie 4y ago> when we know the least about the domain Strategic domain modeling (DDD) is a method to avoid much of the trouble before coding starts and steer timely on an ongoing basis as knowledge of the domain matures. Not suitable for all types of systems, of course, but is anyone using this methodically?
- wpietri 4y agoI'm a big fan of Domain-Driven Design. But I think "before the coding starts" is a bad way to look at it. To be ready for a week's worth of coding, all we need is either a small amount of stuff we're sure about or something that we can learn about via shipping something. Delaying for perfect knowledge is a very dangerous habit to get into, so I'd rather avoid it entirely.
- rapnie 4y agoYes, that's bad formulation on my end. Know the domain when coding is what I meant.