> But with an architectural problem (for example), it's usually a choice between 2 or 3 options. We know what the options are, we know what the trade-offs are, we can make guesses on what we think the impacts will be. It's a "known known" problem, with usually enough time to research it fully. Implementing it properly can be difficult, but that's the kind of thing that can be iterated if necessary - we don't have to get that right first time.
No, I disagree. Some problems are truly novel (or maybe, there are just a handful of competitors and you obviously can't see their source code) and you just don't even know what kinds of solutions might exist. There might be bits and pieces in the research literature, but good luck even finding them, let alone understand if they are applicable. The space of possible technical and architectural solutions is infinite-dimensional, so it's not always a "known known" issue. There might be crazy solutions out there that you simply didn't think of.
Now, if it's about "create a CRUD interface to you e-commerce store", then I agree that the situation is more similar to what you described, but that's not what everyone is working on.
I had to work on a scheduling problem once that involved going to a university to talk to Comp Sci PHD's who were working on similar problems. That was fun. In 25+ years of commercial coding, that's happened once ;)
Now you talk about an algorithmic problem and there I agree with you - there isn't much algorithmic complexity in normal business coding.
But in your previous post, you talked about architectural problems and there I disagree with you strongly.
Taken in isolation, individual technology pieces are relatively simple and easy to evaluate. But when you plug in one such piece into a middle of a larger system (let's say typical corporate IT landscape), then it becomes way more complex on all fronts. (Enterprise) architecture is also interfacing heavily with business decisions and company structure. You need to think a lot about how your ivory tower architecture will be actually used by the teams.
But if you get it wrong, what happens? You have to refactor (if you didn't get too far in), or start again if you did. No big deal - code is perfectly amenable to this.
But the political and social problems of "we got it wrong, we're going to have to start again from scratch" are the real problems. Dealing with a marketing manager who has a product launch scheduled for the 2nd quarter and you're about to tell them that you need to reschedule because you got the architecture wrong on the first try - that is a business problem not an architectural problem.
The tech problems get a lot easier if you have some kind of framework for dealing with the business problems.
> But if you get it wrong, what happens? You have to refactor (if you didn't get too far in), or start again if you did. No big deal - code is perfectly amenable to this.
This works nicely on a small scale, but not with the architectural problems.
> that is a business problem not an architectural problem
It's an architectural problem because this business constraint forces me to get the architecture right the first time - I won't get another chance.
There's no business reality where it's OK to say "just give me another 2 years to re-do the system in a (probably) better way".
But there is a business reality where you can say "I don't know which architecture option is better, give me 3 months to do some prototyping and I can make a definite decision".
But knowing how to frame that, and manage the expectations of the other people involved in that negotiation, and recognise their objectives and priorities, is a business skill.
And, y'know, if you spend 2 years building a system on the wrong architecture because you didn't know how to ask for more time to make a better decision in the first place... well, you need some management training ;)
> But there is a business reality where you can say "I don't know which architecture option is better, give me 3 months to do some prototyping and I can make a definite decision".
And now back to your original claim. You need 3 months of prototyping only to reach a decision, but you still insist that it's an "easy" problem?
Then there's a problem that prototypes often don't uncover unknown unknowns. Investing effort into prototype improves your chances at arriving at correct solution but by no means guarantee it.
No it's not an "easy" problem - like I said, I get that these can be tricky. But in my 25+ years of commercial software experience, I've not bumped into one like this. I have bumped into complex technical problems, but the answers were/are always out there and findable. As I said, these kinds of problems are "known known" - you know what the problem is, there's a decent definition of what "good enough" is, and there's usually a lot of Comp Sci literature around to help.
Remember, this is in contrast to the people/business problems. For these, because they're involved the specific personalities involved, there is no definition of the problem (people will react to a situation according to their nature, and you can't check their source code). Often there is no good definition of what a good solution even looks like (except a broad "get everyone happy and working again" maybe). There is no literature describing the solution to the problem, or usually even addressing similar problems. And the problem always has a time limit - taking no action is seen as an action in its own right - and it's usually days at most. You literally have to make up some solution as you go along, not knowing if it's going to work or not. That's why I called these "unknown unknown" problems. In 25+ years of commercial software experience, I've bumped into at least a dozen of these (that's not including the "normal" run-of-the-mill management problems).
Your experience may vary - mine led me to conclude that the tech problems were not as difficult as the people problems, and that therefore I should get some training for the people problems.
For example: the network admin comes out as gay, starts having a relationship with someone on the night shift. The number of "emergency network outages" during the night shift suddenly spikes. A quiet word didn't seem to have any effect. The night shift supervisor is getting fed up of the disruption. Sacking the admin isn't an option. Sacking the nightshift worker isn't an option. Going down any kind of formal disciplinary process is the "nuclear" option as the company has to make absolutely sure it's not in breach of discrimination legislation. Ideally everyone would go back to work and be happy and the network would stop having problems at night (one of those where there is a well-defined "good result"). I didn't manage to solve this problem - the network manager ended up leaving in a huff (though thankfully not sueing us). I still to this day have no idea if I could have found a better solution to that problem. There is no technical problem that I've ever faced where I wonder 20 years later if I could have found a better solution (though plenty where a better solution has become available later).
No, I disagree. Some problems are truly novel (or maybe, there are just a handful of competitors and you obviously can't see their source code) and you just don't even know what kinds of solutions might exist. There might be bits and pieces in the research literature, but good luck even finding them, let alone understand if they are applicable. The space of possible technical and architectural solutions is infinite-dimensional, so it's not always a "known known" issue. There might be crazy solutions out there that you simply didn't think of.
Now, if it's about "create a CRUD interface to you e-commerce store", then I agree that the situation is more similar to what you described, but that's not what everyone is working on.