1. 6
  1. 3

    So, you say, towards the end of the vdieo, that all structure is derivative, but I’m struggling to understand the implications of that beyond a general “every needs to be considered in context” sense.

    1. 2

      I was telling a friend online today that it’s a struggle trying to find the right pace for the material I have to cover. If I go too fast, people miss the point. Yet if I take my time and establish foundations, people complain it’s too slow. This is a good example of that.

      Basically there is a system to explain why structure is created, any structure from a database design to a bridge. Although I know that sounds overly-broad, understanding the system that creates structure allows us to start teasing it apart and optimizing it, looking at how we code and architect systems from the outside rather than as people down in the trenches in the heat of battle.

      Structure has to exhibit some desired behavior and conform to whatever rules you’re carrying around in your head when you create it. Most of these rules are invisible, unconscious even. For instance, I’ve been brought on to the beginnings of large systems being designed only to be given a list of things they’ve already decided to use, no negotiation. That kind of thing can have vast costs and cause vile and pernicious problems downstream … and the folks suffering through it would never know that the org brought this on themselves.

      Behavior is pretty easy to track. We have behavior we want and we have tests to validate that behavior. (The tests can be formal or just in your head). Rules/Values are another thing entirely. It’s possible to have tests here too, though! So a while later we’ll talk about infrastructure testing, where things like the simian army comes in. But we’ll only do that once we drive out more details about what exactly we mean by rules or values.

      So I had to start somewhere. One of the interesting things about “all structure is derivative” is how many senior programmers and architects that will dispute it! You have to sit down with them and take them through example-after-example, usually from their own work, for it to finally sink in. When we talk about the modern development environment being overly-complex and systems that are built far beyond what’s needed, the failure to understand this is where it all starts .. and where we can start fixing it.

      1. 3

        Expanded out just a hair, it makes a bit more sense. So, to make sure I understand the point, all structures (languages or tools) are shaped by the structure/context that led to their creation. We can take advantage of this knowledge by trying to apply some our systems knowledge one level back.

        To start with a trivial example, while you can do most tasks with most tools, choosing a tool that is a good fit makes for getting the task done easier. Hammering nails, rather than smashing a screwdriver or a fist into them (or, using Rails or PHP for a website rather than using C++ or CGI/Bash).

        Taken a level up, architecture choices in a software project, or how many people are working on a given product can have a big influence (Conway’s Law), or the like.

        Of course, the more levels up you go, the more you switch towards politics and a messy system of people. A messy system of code can come from one person, or from many.

        Why do you think so many senior software devs are resistant to the idea? Is it pride? Part of the consequences of the software industry having a myopic and incomplete view of its own history?

        1. 4

          It’s a weird thing because so much of it we are unable to see. It’s like the old “you can’t explain water to fish” thing.

          I believed, taught, and preached YAGNI for years. I can’t convey the shock I felt when I finally realized I wasn’t doing it. Yikes!

          You should be able to point to any piece of code or architecture in your solution and be able to explain why you were forced to have it there. Most of the time people think they can do this, but when pressed it’s just a lot of arm waving and talk about best practices and such.

          1. 2

            How did you realize that you weren’t practicing YAGNI? It’s something I’ll admit I don’t adhere to nearly perfectly, (but then, I also admit that I don’t follow any software principle perfectly).

            I’d like to think I’m somewhat self aware, but I will also admit that I struggle with a lot of patterns that recur and seem less than ideal. But then, I’ve also grown up in a cross cultural setting, so my water has been shifted a lot, which makes me more aware of it in general.

        2. 2

          So, are any of these reasonable ways to paraphrase what you mean by “all structure is derivative”?

          • “No part of a system should be present due to dogma. Every bit of it should be chosen based on reasoning from first principles.”
          • “No choice about how to design/build a system is inherently correct or incorrect. Rather, the key question is how suitable each choice is towards the desired outcomes.”

          I’m just trying to figure out whether I’m getting your point clearly. If not, maybe it would help if you were to provide a fictional example of a conversation with a senior programmer who starts out disputing you, and then is convinced as you talk through examples from their work.

          1. 2

            How about (in regards to coding): It is impossible for any line of code to be written unless the programmer is balancing what she wants the code to do against their own set of rules for how things should be coded. The behavior part is explicit and what everybody focuses on. The values/rules part is almost entirely hidden.

            If we want to write better code, we need to understand how coding happens. From there, we can “drive the train backwards”, taking coding situations where we have poor outcomes and looking at the desired behaviors and values the coders used when creating them.

            I’ve got a few concepts that this is the foundation for, such as Good Enough Programming, Incremental Strong Typing, and Code Budgets.

            From there, I’ve got a few examples of fun coding projects that apply them. I’m hoping to get there with these videos. But you gotta start somewhere. If folks don’t understand why code happens, the balancing act that is required, they’ll just get hung up further down the road.

      2. 2

        An interesting video, thanks. I’m not sure I really understood your main point, but it was fun making some attempt at doing so. I’m just here to comment because I was annoyed that your talking head obscured the fourth quadrant on your penultimate slide and I would be interested in knowing what those words were. I’m guessing that was the Rules/Values section so the word starting with “V” is probably “Values” but I’m not sure for the rest.