3 ms·

> 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,

> 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.

marcus_holmes 6y ago
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 ;)
- The_Colonel 6y ago
  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.
  - marcus_holmes 6y ago
    Again, I get that this can be tricky. 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.
    - The_Colonel 6y ago
      > 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".
      - marcus_holmes 6y ago
        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 ;)
        The_Colonel 6y ago

marcus_holmes 6y ago

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 ;)

The_Colonel 6y ago
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.
- marcus_holmes 6y ago
  Again, I get that this can be tricky. 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.
  - The_Colonel 6y ago
    > 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".
    - marcus_holmes 6y ago
      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 ;)
      - The_Colonel 6y ago