Design and Relationship with Real World Concepts

This topic contains 10 replies, has 3 voices, and was last updated by  Max Guernsey 3 years, 1 month ago.

Viewing 11 posts - 1 through 11 (of 11 total)
  • Author
  • #28290

    Max Guernsey

    I’m starting this conversation privately. If we decide it should be made public, any admin can always promote it.

    We may also decide that it should be a set of blog entries. Like how, back in the steampunk days, people used to debate via letters sent to the paper.

    Or you may all decide to just shut me down.

    I’m not sold on there being a naturally direct relationship between the design of your code and the structure of the problem you are addressing with that code. I think it’s an useful teaching tool. If people are struggling to figure out where the boundaries between entities should live, I agree that looking for the separation between real-world entities can help them.

    I don’t think that means that, necessarily, the entities in your code should mirror the entities in the real world. It feels more like a set of training wheels than like the way things “must” be done in order to do them “right.” Once a student starts to develop a sense for where things should be decomposed (which I think is basically everywhere), I think the wheels can come off and they can ride free.

    The essential insight, to me, is that variation must be encapsulated and coupling must be meaningful/logical/intentional. How you get there is, I think, an open question. Maybe you get there by modeling real-world objects. Maybe you get there by reacting alergically to switch statements. Maybe you don’t remember how you got there or have murkey memories from the distant past of such an awakening.

    Whatever the case, I wouldn’t let the lack of a corresponding real-world entity drive me away from encapsulating variation. Nor would I do backflips to find a real-world entity that justified encapsulating a variation.


    Scott Bain

    “A natural fit” is a rubric, a guide to thinking. It does not replace thinking. 🙂

    One example: When we do the paint thing in STDD (I’m assuming you use that exercise) invariably people have the constructor of the Paint object throw the InsufficientWhiteForGloss exception, or whatever. Making this new test pass causes the old test (persistence of state) fail, and this leads to a design discussion.

    Now you could easily argue, from a quality perspective, that the constructor is doing two things (persisting state and validating the white/gloss rule) and therefore lacks cohesion. Certainly.

    However, I also say this to the students. “Let’s imagine a real, physical can of paint. If you fill it with the glossy base, and then don’t give it enough white pigment drops, does it do anything? Does it complain or in any way reject its own creation? No. Something else, some mechanism in the factory that makes the paint would have to ensure this rule was adhered to.” This also leads them to consider the design change that the cohesion argument would indicate.

    I never say “this is how you do it.” I always say “this is something you can do.” I’ve seen many examples where this “model the reality” approach has lead to useful insights, and so it’s one of the things in my collection of tactics.

    • This reply was modified 3 years, 1 month ago by  Scott Bain.

    Max Guernsey

    Yeah. I’ve been doing that more and more. “That” being giving people – especially people who are struggling with the fundamental concept of cohesion – the “would the real thing do this” tool to help them find places to break large problems down into a collection of smaller ones. I tried to make it clear that I’ve been doing that, and agree with it as a teaching tool, in my original post. Sorry if I failed.

    To be clear: I’m cool with it as a tool. I like teaching it to people who need it.

    That said, I don’t think we unanimously agree that it is just one (admittedly useful) way of thinking about problems. I think that, at least, Amir would argue that it is the way of thinking about problems. Sorry for singling you out, Amir, and maybe I’m misinterpreting conversations we’ve had in the past. Let me know if I am.

    Part of why I made this thread private to start was so I can sense how far “out of bounds” my thinking is before I start conversing publicly.

    There seems to be a strong drive in the organization, right now, to develop consensus and for everyone to be saying the same thing. I don’t think that can be achieved in the technical world, where a lot of stuff is pretty black and white, as well as it can in the process world, where most everything is one shade of gray or another. However, I feel it’s our duty to at least try.

    So, what I’m getting from your post, Scott, as pertains to my not-so-well-delineated objective is that both ways of thinking are “in bounds” for you, so long as we don’t spend a lot of energy trying to call the other way “wrong”.

    Is that a fair assessment?


    Scott Bain

    I got that you use this “real world” thing as a teaching tool. I was just giving a concrete example. Sorry not to be more disagreeable 🙂

    I think you may be mischaracterizing Amir’s point of view a tad. He tends to use dogmatic language when he expresses himself, but I don’t think his thinking is inflexible. When talking about patterns I say “you don’t use patterns to solve problems. Problems have patterns in them, due to their nature, and you just need to find the patterns in a given problem.” Amir says “the solution is the problem” which is a similar point of view, just stated using more absolute language.

    He and I once argued about the notion that a given problem could have more than one proper design. He said no, I said yes. What we realized is that when you choose a different design it is because you are solving a different problem, even if only slightly. Perhaps you have understood it differently from someone else, or perhaps you have chosen to solve a somewhat different problem than they have. Requirements are rarely if ever absolutes, and thus the way you have interpreted them may lead to design X or design Y. This led me to realize that analysis and design are inexorably linked and one of the problems with the Gang of Four is that they tried to delineate a design paradigm absent any analysis. Alexander did not.

    To answer the question of “should we be in total lockstep?” I say no. To adopt such an attitude is to discourage creativity and critical thought, which is anathema to me. I do think we need alignment on values, and an expression of commitment to them, but if someone want to discuss the virtues of procedural code and the waterfall process, I’ll listen and participate. Even someone who is mostly wrong is usually partly right, and I’m always open to new insights.

    When I’ve spoken about the “smell” of data classes, for example, I always talk about “my friend Max” who “feels differently.” I am glad to have your point of view to refer to, and I think my teaching is better because of it. The last thing I would even want to recommend to a student is that they stop thinking.


    Max Guernsey

    I agree.

    Amir, if you’re watching and I’ve mischaracterized your position, I apologize.

    Yeah. I’m cool with the idea of presenting an array of options. Maybe we should create a library of conceptual tools that you navigate with something like the Inflection Point system (where you start with an outcome and work your way back to a practice or discipline).


    Scott Bain

    I think this is a good idea, so far as I understand it. Care to give a concrete example?


    Max Guernsey

    Well. I only have a basic understanding of the Inflection Points system – and it may need to be modified to work with technical practices anyway. Here’s something along the lines of what I mean. For example purposes only.

    What Kind of Problem Do You Have?

    What Slows Down Your Changes?

    Why Is the Same Thing Repeated So Many Times?

    Here Are Some Ways to Break Down a Large Concept

      …something along those lines.


    Max Guernsey

    I take an approach that there are multiple approaches to everything :). There are multiple designs that can solve a problem. Which one is better is not necessarily clear. It all depends on your viewpoint as to what tradeoffs are, their priority, and so forth, as well as your experience and the development context. Now all of those issues might be viewed a part of the problem making them different problems. I look as them as part of the solution space.

    On your original question, code terminology (e.g. names of classes) should typically reflect the domain terms. Otherwise you have an impedance mismatch which makes it harder to maintain code. (E.G. The domain term is DateOfDeath and the code says “DtoDth”.) Now responsibilities might be split into three classes – DateofDatePersistance, DateofDeathModel, and DateofDeathUserInterface. But that’s a design decision as to separation of concerns. But at least the classes reflect the problem domain.

    We are never going to be in lockstep. I think it’s valuable to show different viewpoints. A student can learn there are different views and he/she needs to be able to evaluate them. As someone once said, you can even learn from people who do the wrong thing – not to repeat their mistakes. With that as a framework, I’ve learned a lot.


    Max Guernsey

    What do you think about the idea of creating an outcome-driven catalogue of techniques and tools for the technical side, like what they are doing on the process side, Ken?


    Max Guernsey

    Please give me examples. I’d like to compare your thoughts to the list of techniques that I already have to see how they compare.


    Max Guernsey

    Is this sufficiently example-y?

Viewing 11 posts - 1 through 11 (of 11 total)

You must be logged in to reply to this topic.