from Hacker News

Domain knowledge or a lack thereof (2013)

by ggr2342 on 6/10/23, 6:57 AM with 30 comments

by PeterStuer on 6/12/23, 5:46 AM
The worst in my days were the very large projects. Besides many other problems. The system's funcional design was written up by analysts talking to the client's middle managers. Neither of those groups had a grasp on how things realy got done on the workfloor beyond the most basic sunny day scenarios. Actual developers and actual users were not allowed to talk to each other as many times the new system would obviously involve some redundancy/displacements in the workforce which needed to be kept under covers and some completely made up at salrs pre-existing system capabilities of the supplier such conversations would 'leak'.
Needless to say these projects typically crashed and burned irrecoverably at first contact with production.
by samwillis on 6/11/23, 9:42 PM
Ask "dumb" questions.
The best lesson I have learnt working in product development (both software and physical) is to ask "dumb" questions. The vast majority of the time they aren't dumb. What seems to you, on fist pass, to be a dumb question is almost certainly an insightful one. The person, your customer/client, will be pleased to hear you asking it.
Every answer to a question is a jigsaw piece, ask a question that fills in the next gap until you have the full picture. Each answer gives you a new edge in the picture to ask a question about.
Sometimes the "expert", your customer, who you are asking won't know, and that's just as valuable as it gives you insight into them and the new field you are working in.
Don't stop asking questions, start with them, then Google and read anything and everything you can.
An enormous part of new product development is learning about the field, then applying your learnt knowledge from elsewhere to it.
by oaiey on 6/12/23, 5:58 AM
Domain knowledge is also the thing upper management conveniently ignores when it comes to fire and hire (I intentionally changed the order ;)), off-shoring or we-do-projects-but-are-not-a-software-shop ignorance practices. The little percentage in money you gain, you dramatically loose when delivering on this fresh people.
If you have a domain competent group, your requirements/stories/tasks are faster written, better developed, better tested and quicker delivered. In addition to hitting the market need. If not, you will see money burning.
by BlargMcLarg on 6/11/23, 9:36 PM
Unless the market is big, most employers give zero incentive to accumulate domain knowledge. Between learning the new hot framework and accruing domain knowledge, one is clearly better for the average dev's career.
The advice is great in a world where people remotely cared about good software and are willing to pay for it. Not such great advice for reality.
by marcod on 6/12/23, 1:35 AM
Any employer can increase the amount of domain knowledge in their software development teams at any time. All it takes it giving them the time of the employees who use the product. Ergo, the actual problem is that is too expensive for most profit driven organizations.
by pphysch on 6/12/23, 5:19 AM
This is a reason why I like to use Python for more things than is strictly necessary. There's a ton of domain experts writing Python for their non-SWE jobs. Contrast with e.g. JS and Ruby which are more SWE/webdev-only languages.
I like to think it makes knowledge transfer at least a little bit easier across the user-developer membrane.
by erehweb on 6/11/23, 9:28 PM
Seems like it should be completely obvious, but when I worked at $SOCIAL_MEDIA_CO there were several Engineers who refused to use the product but claimed this had no effect on their work.
by Jtsummers on 6/11/23, 9:17 PM
(2013) with a discussion at the time: https://news.ycombinator.com/item?id=5263486 (110 comments)
by verbify on 6/11/23, 10:48 PM
This person appeared to make hardware manufacturing applications (like CNC machines). In my experience with software like CRM there's a nuance to which domain knowledge is important (but I presume also financial software, and to a lesser extent ERP).
My experience is more with CRM. In these cases, domain knowledge is still important, but it's more about the curiosities around how a specific sales/marketing/customer support team is structured - how do they divide up leads? Do they compete with each other within the team or are bonuses given to teams? Usually these decisions are informed by domain knowledge. E.g. the customer support of a boutique expensive watch brand would be more of a concierge service (with tickets requiring immediate attention - a delay in response could represent a big loss in sales), while for a mass manufacture cheaper line it would have more of a volume of tickets and human response times might differ. Escalations would therefore need to be programmed differently. To give another example, I can imagine seasonality having a huge impact on how a financial team want their software programmed, and that is informed by domain knowledge.
But knowing how watches are made wouldn't help me with understanding 'domain knowledge'. I need to understand how they are sold. The domain that I need to understand is 'how does this sales team work' not 'how does this product work'.
I guess what I'm saying is the right kind of domain knowledge to match the task.
by charlie0 on 6/11/23, 11:13 PM
I'd argue domain knowledge becomes less and less important as the size of the organization grows. Eventually, it gets to the point where what you are working on is just a tiny piece of the overall work, it just doesn't matter. Also, at that larger size, your input doesn't matter very much either, that's what the BA team is there for.
The best organizations will work to leverage the productivity of individual devs over just throwing bodies at the problem, but that doesn't happen everywhere.
by nologic01 on 6/11/23, 11:14 PM
Domain knowledge should be available in the team, not necessarily every member of the team. Together with good communication this solves the issue on a 80/20 basis.
The exception is of course if you work solo, in which case it does indeed become a full stack problem of sorts. Individuals who can pull this of can make significant impact.
by js8 on 6/12/23, 10:48 AM
I agree with the article, domain knowledge is important and under-appreciated. It's strange that companies hire SW engineers mostly on knowledge of the tools rather than understanding the problem domain. It's a wrong Taylorist idea that programmers should focus on how and not on why.
by AdieuToLogic on 6/12/23, 3:01 AM
> I believe that a lack of domain knowledge is the root cause of a lot of very bad software that gets developed and I think that it is up to computer programmers and their managers to deal with this.
This is probably the best thesis statement I have seen regarding S/W engineering in a long time.
by tanepiper on 6/12/23, 8:21 AM
At IKEA, we have something called "Front Days" that non-retail co-workers can sign up and work in the store for a few days. I did my first one three weeks ago, and it was a great way to get out from a desk and see the reality of what we're all working towards.
by aryehof on 6/12/23, 4:45 AM
While it would be ideal if all the software devs writing say a General Ledger application were accountants, the reality is that will not be the case.
I call domains where expertise lies outside of the software development team - “external domains”.
For these, programmers, testers and managers need additional skills in requirements elicitation and capture, and more importantly skills in modeling a system (real or imagined) based on those requirements.
In a software world dominated by technical requirements, how to determine and model functional requirements in an external domain can be what makes a programmer a great one.
by Dave3of5 on 6/12/23, 10:55 AM
From a selfish dev side learning too much domain will lock you into to a company.
I prefer not to have any vendor lock in so I focus my skills on the parts that are transferable to other companies.
Domain knowledge to me is primarily a BA responsibility. The bits that a dev needs to know are converting that into the implementation.
FYI this also probably comes from someone who hasn't had a very niche and difficult domain. The most complex domains I've worked in would have required decades of training and experience to understand. My job was to know enough to to my job well.
by ChicagoDave on 6/12/23, 6:42 AM
100% agree.
And some domains are extremely complex, requiring an extensive learning process. This is why large consulting-led projects fail, because there isn’t enough time taken to truly understand the domain.
by Domdomkusu on 6/12/23, 5:15 PM
I loved your idea. We have to be experts in our own field. The person who tries to learn everything actually learns nothing.
by jameshart on 6/12/23, 12:16 PM
But don’t fall into the trap, as a developer, of mistaking your hastily acquired superficial domain knowledge for actual expertise.
One particular Dunning Kruger trap that devs can fall into is fixating on the most complex parts of the domain that they understand in any depth, and the edge cases that complexity suggests, at the expense of addressing the concerns of the actual experts, that are most relevant to the task at hand.
This can lead to software centering domain concepts that are esoteric and obscure at the expense of the concepts needed to meet the actual requirements. Or embedding rules that to experts are more like guidelines.
Like: it’s great that you’ve developed a deep interest in and love for heraldry, the system of colors and tinctures, and the way flags can be described using a blazon - but it’s probably okay to just have an SVG url for an image of the flag in the database, not a full blown heraldic DSL.