Comment by caffeine | Hacker News Reader

Comment by caffeine | Hacker News Reader

Parent Full thread

> they are best served by code that represents their understanding of the business

Genuinely curious why you think this is? To me it seems a massive leap?

Trying to steel-man this, if:

1. The people who know best about the domain are not technical and don’t know algorithm thinking

2. The technical people are not capable of understanding the domain enough to separately discuss what the code does and how it does it

This is basically the consulting scenario, which is where DDD came from (?) Then it would make sense - when the team leaves and the next guy comes in with no clue how it works, he can read it out to the domain expert who will roughly understand what it’s doing.

On the good teams I’ve seen, the domain experts and the people coding are the usually same people, the “domain vocabulary” is CS, and the team is looking for maximum leverage (trying to do with 10 ppl what others do with 100 people).

So it’s quite a different scenario than 100 ThoughtWorkers getting dropped into some vertical they know nothing about and being expected to model a bunch of existing business processes.

Everybody within a business should be using the same language and concepts when thinking about the business, because it's important for effective communication: daylight between what people are thinking about is where problems creep in. The role of any people of any discipline within a business is to use their expertise to shape _how_ they think about the shared _what_.

Code is just one tool (of many) that a business will use to achieve its goals. There's a mythology in a lot of businesses around the genius of technologists because we understand the complex system that we built that everybody else in the business is too dumb to understand, but in reality it's because technologists are uniquely permitted to decide they're better than everyone else and diverge from the shared thinking because it's easier than reconciling business concepts with technology -- which is where the actual hard part of software engineering is!

If you walk into any business that has been around for a few years and has allowed their technology team to do whatever they want, you'll probably find a completely incomprehensible system that the business hates because it has diverged so far from how they think and what they want that they can't effectively do their jobs.

People come and go, the only constant in a business is the business.

An example that comes to mind is a business that has customers who pay for membership, and so they're called "members" within the business. However, the development team decided they knew better and implemented "user" accounts which can have a "subscription". Then, later, the business decided to introduce a subscriptions product... and so the problems began.

Reply on news.ycombinator.com