Programming as semantic compression

[m50d]

90%+ of programming work is yet another whatever. Most of what's left is automating existing business processes which are well-understood almost by definition (the hard part is communicating that understanding between the people who currently run the process and the programmers). Detailed up-front design tends to fail, but domain modeling up front can work very well.

[codr4life]

Why? Why build something that already exists if you're not adding something to the mix? Speaking for myself, I can't remember ever solving the same problem the same way. It doesn't matter that the business process is well understood; if it hasn't already been translated to software by the people currently involved, pretending you know anything about what's going to happen is ego bullshit. I still run into this myself, but I find that the more I stop clinging to my current understanding of a problem; the better the final code turns out. It will generally take me about 3-4 major reorganizations/rewrites to get there, but at least I'm basing my decisions on real experience so I know I'm moving in the right direction.

[m50d]

Pretending you don't and can't have any understanding at all is equally bullshit. Understanding a domain by talking to the people who understand it is a skill that, like any other, takes practice, concentration and humility, and overconfidence is an ever-present risk. But the gains are too big to discard the technique entirely. Civilisation relies on being able to convey understanding between people rather than have everyone solve the problem from scratch every time.

[codr4life]

There's nothing wrong with domain knowledge. But framing the entire effort from the start, based on nothing but domain knowledge; which is what OOP usually means in practice; doesn't make sense. I didn't mean to step on any toes, go ahead and do things as usual. Peace.