1. 9
  1.  

  2. 1

    In the case the author describes I would rather think of the original sin as trying to predict the right architecture for a future system upfront. Instead, I believe an ideal architecture should always directly follow from the functionality that the system currently implements.

    Such an architecture can never be wrong or insufficient unless a current user-facing feature of the system is also wrong or insufficient. In that case, both need to be changed simultaneously.

    This has a number of consequences:

    • If a functional change would result in an architecture that no longer suits the resulting system, the change should not be accepted until the architecture is also changed within the same change set.
    • Simple functional changes sometimes need to turn into large projects.
    • Sometimes an architecture is turned upside down for a small functional change and then turned sideways for the next.
    • The architecture is fluid. If code can only be trusted to work within a certain architecture, it is a liability, hence the appeal of pure functions and loose coupling.
    • Because the architecture is being changed all the time, the effort of keeping it very simple will be in the engineering team’s core DNA.
    • When you see an architectural pattern that is not an obvious match with your understanding of the business requirements, it is always prudent to investigate.
    • Junior engineers should never get the answer, “I know, but that’s how it was originally built, you will learn to work with it”, but rather “you will understand when you read up on these requirements”.

    I am aware that this describes a utopia, but for me it is at least always in the back of my mind.

    1. 1

      Have you actually been able to implement a software architecture this way? I definitely understand it as a platonic ideal of architecture, but I don’t know that I’ve ever seen it play out in the real world, side-project or otherwise. Maybe with SQLite?

      1. 0

        I have, but only for three to six months projects and for the products we sell with a two person engineering team. For the 300 man team / 20 years old products I work on, it’s definitely different, the main bottleneck always being the understandable reluctance to change working code.

        But whatever the situation I believe that trying to design the perfect architecture for a product upfront classifies as an Original Sin well better than any individual design choice.

      2. 0

        That sounds like a utopia indeed. Agreed that this would be ideal.

      3. 1

        I really object to this religious imagery.

        1. 1

          Ah, sorry. Perhaps a better title would have been “the root mistake” or “the original error”.

          1. 2

            I don’t think that’s any better: Right and Wrong aren’t measured this way except by the Church, and no programmer is doing themselves any favours by joining a cult.

            I will try to explain, but I do not expect it to be easy to understand.

            Often, one or more of these assumptions is incorrect, and it is often one of the core decisions, rather than one of the ancillary ones. (Or, perhaps they both have an equal chance to be incorrect, but if it is a core assumption, I notice it more.) This is the “root mistake”.

            Just because your assumptions turn out to be incorrect, does not mean you have made a mistake. Did Twitter make a mistake by using mysql and fail-whaling every day? Depends on whether your goal is to make software that you can maintain, or your goal is to make a tonne of money. If it’s the latter, you’ll incur a lot of technical debt by making simple incorrect assumptions early because the thing about technical debt isn’t that you have to pay it back, it’s that you have to get more out of it than it costs to keep it around.

            Okay, so if it depends on your perspective and your history whether you even agree there’s a conversation here, you may be able to see this kind of thinking doesn’t produce useful arguments: You’re going to find people who agree with you, and people who don’t, and you’re not going to be able to bridge the gap, so you’ll gain nothing from the people who agree with you (and see no other things you can do with “mistakes” besides live with them or not), and you’ll understand nothing from the people who disagree with you (and don’t see the point in building a taxonomy of “mistakes” that might not be mistakes at all, if there’s no meaningful predictions you can make about them, and no conclusions you can make at retrospective, and so on).

            So what’s the point?

            1. 1

              I think you raise an interesting point. People make the choices they make at the time they have to with the information they have.

              What I’m pointing out is that sometimes these are the wrong decisions (when one has more knowledge about the needs of the business and the system).

              I’m not blaming anyone for making them, but making an incorrect decision has ramifications that shape future decisions and opportunities. As I pointed out in the original post, you can either work around such choices, rip them out, or throw the application away.

              I’d say that Twitter worked around it for a while and then ripped it out.

              As far as the point, I wrote this post because I do think there’s value in pointing out that architecture choices have long shadows and that you have a variety of painful options when something is chosen that seems correct at the time but is not as the application grows. That could mean that you’ll be more open to researching at the beginning, or you’ll put facades over systems that may make it easier to swap out or you’ll think about technical debt more.

              1. 2

                What I’m pointing out is that sometimes these are the wrong decisions (when one has more knowledge about the needs of the business and the system).

                That sounds like just another name for Path Dependence. Software isn’t unique in past decisions impacting future decisions.

                https://en.wikipedia.org/wiki/Path_dependence

                1. 1

                  I love the concept of path dependence!