[indogooner]

This is a post which touches on a subset of "hard" parts while downplaying other hard parts. I agree that a developer with a deep domain knowledge is precious. In fact, I have seen quite a few developers rising up the hierarchy despite being mediocre on technical skills. The code written by them is big ball of mud but they are good at communicating with stakeholders and understand the business well(And also good at drawing boxes) . This does not mean that there is no cost to it. It is just hidden from others. The memory leak issue, the several bugs introduced due to multiple if-elses encoding the business rules, swallowing exceptions or failing to set right properties for client timeouts. These can exist despite the "deep context" and most of the time junior developers are to be blamed for this because the so-called architect is busy all day in meeting with management.

Also the experience may vary. In my admittedly not so long career(less than a decade) I have seen teams where business rules are the major source of complexity while there are other teams which have less business rules (example the databases/data warehouse/build systems team). Admittedly there are less teams of second type in the world so the general perception is that the hardest part is communication and understanding of business context.

Coming to domain knowledge, even the Mainframe and COBOL chaps make a lot of money while smart open-source contributors freelancing don't. Money is not the only way to judge the hardest problem about software development.

[walrus1066]

The way I see it, my job isn't to just blindly implement what the business thinks they want. It's a two way thing. If a set of business rules are too complex and convoluted, I explain that this incurs a cost, in increased likelihood of bugs, and slowdown of future development. We then think about how we can simplify the rules, or reduce complexity elsewhere. In one such case, we agreed with the business to remove an entire feature, to make the new feature more robust and easier to develop. I deleted 1/3 of a codebase as a result, ultimately the overall complexity of the system was substantially reduced after the new feature. It was immensely satisfying.

[indogooner]

This is where a good product team helps. Understanding the threshold at which technical debt would undermine a business feature. Glad that it worked out well in your case

[davidjnelson]

Great points.

> multiple if-elses encoding the business rules

A good architect would add a linter with a cyclomatic complexity check that fails the build. There's always a way to avoid these hideous nested else ifs. Code review is helpful here to train people who don't understand some of the various abstractions to avoid this such as polymorphism. This is also the code that has high value for unit tests.

[BatFastard]

Not saying rules encoded in "if-elses" are good, but they can put all the rules in one location. Polymorphism can spread those rules out in somewhat obscure ways. I use both, depending on what I want to do.

[davidjnelson]

Right, I wasn't saying polymorphism was the only solution. I was saying deeply nested if elses are hard to maintain. There's many solutions to avoid them. So I think we agree, use what makes sense given the context.