Max Guernsey

Forum Replies Created

Viewing 15 posts - 1 through 15 (of 75 total)
  • Author
    Posts
  • in reply to: Essential Refactoring (MG) #28940
    Max Guernsey
    Keymaster

    I guess. The size of changes or classes is a topic worth discussing but out of the scope of this blog entry.

    The Aside

    “Small” and “validated” are both implicitly related and asymptotic. You can never reach infinity small because that’s zero large but you can get damn close to zero large. You can never get 100% validated because that would be 0% risk but, likewise, you can get damn close.

    Remember, in this case, “validated” is shorthand for “validated as non-behavior-changing”.

    “Small” and “validated” are linked. The maximum amount of risk carried by two small validated changes is never greater than the maximum amount of risk in lumping them together. It is often less because you are, at the very least, risking abandoning less work when validation fails. Similarly, (as an aside) “automated” and “validated” are linked, too, because automation makes fewer mistakes and makes the same mistakes every time.

    So choosing to do something larger when you can figure out how to do it smaller, or doing it by hand when you could lean on automation is wrong. That’s not a big deal. Everything we are doing will eventually look wrong.

    In one-thousand years, they will laugh at how we do nearly everything we do just like we laugh at people who used leeches to solve problems. That doesn’t h

    That Said

    This article is about the what the process is, not about how to optimize that process. I could write another blog entry about working in the smallest increments possible and another one extolling the virtues of defining the smallest classes possible.

    • This reply was modified 4 years, 5 months ago by Max Guernsey.
    in reply to: Essential Refactoring (MG) #28929
    Max Guernsey
    Keymaster

    The reason I got hung up on the word “need” was because I couldn’t tell whether you actually meant need (like I need gas to make my car go) or a choice (like I need goggles to swim).

    Admittedly, maybe I’m also just generally hung up on need/choice confusion because I have an eight month old and I’m noticing how many people say things like “you need to hold still while I put on your onesie”.

    in reply to: Essential Refactoring (MG) #28928
    Max Guernsey
    Keymaster

    The thesis is that refactoring is working in small, validated, behavior-preserving changes with a way to abort if something goes wrong.

    in reply to: Essential Refactoring (MG) #28811
    Max Guernsey
    Keymaster

    So you actually believe that you sometimes need to spend a long time in a non-green state? I’ve not no response to that that is in the scope of this blog.

    How could I have made the thesis clearer to you?

    in reply to: Essential Refactoring (MG) #28809
    Max Guernsey
    Keymaster

    Moving a method out of a class to make it testable appears to me to be more clunky than just making it protected. This is a viewpoint. So the example doesn’t seem relevant to me.

    I made it more clear what my motivation is – making the method testable and (more importantly) mockable.

    I know you can mock stuff with protected methods but that’s inheritance to specialize and I don’t know why people would do that when they have the alternative of composition.

    I don’t think that this is as bad as you make it out to be. You may need to spend some time in not-green in order to do some non-automatic refactorings. It’s up to the individual to decide how long they are comfortable with that.

    I disagree with your use of the word “need”. This is a great example of where subjectivism simply does not apply. Objectively, you don’t need to spend a long time between green states. You may choose to and you may want to do that. You may even be comfortable with that. You don’t need to do it. Not ever.

    Even the rote manual refactorings we show in our STDD course demonstrates this essential way of working. You always get back to green as fast as possible. If you have two paths that lead to the same endpoint, you choose the one that gets you to green sooner even if it looks like it will take longer in the long run. This is because the path with the shortest maximum green-to-green time tends to take the least amount of time to get totally done.

    If I ever bothered to read the Refactoring book, I’d wager that I’d find all the rote refactorings are expressions of this process.

    Did I fail to communicate the thesis or do you just not agree with it?

    in reply to: Don’t Be Fooled by Boxes and Lines (MG) #28807
    Max Guernsey
    Keymaster

    First of all, it’s totally true that you can add anything to the code that isn’t in the UML. You should. The UML is just some made up B.S. That’s the point of this article.

    Secondly, how do you figure there isn’t a dependency between the packer and the format in the code?

    in reply to: Don’t Be Fooled by Boxes and Lines (MG) #28806
    Max Guernsey
    Keymaster

    Because what the class diagram says and what the code says are not the same.

    The uml says there is a dependency on the enumeration. Your code does not have it.

    By this logic you can add anything to the uml and ignore it in the code. For example, i will add an encryptor strategy, a happy meal builder, a bridge, and sixteen visitors on a hierarchy rooted with an abstract message packer.

    And here is the code:

     public class MessagePacker
    {
      public string Package(Message message, MessageFormat format)
      {
        return format + "|" + message.Id;
      }
    }

    Because if we ignore the uml, lets go all out.

    in reply to: Don’t Be Fooled by Boxes and Lines (MG) #28805
    Max Guernsey
    Keymaster

    …hence my earlier reply:

    “…look again, Grasshopper.”

    in reply to: Don’t Be Fooled by Boxes and Lines (MG) #28804
    Max Guernsey
    Keymaster

    You have a tendency to think you’ve proved something when all you have done is said it.

    Your claim was that there wasn’t a dependency on the enumeration and that somehow invalidated the argument. If that were true, it still wouldn’t invalidate the argument, which is that diagrams (like all documentation) lie.

    However, the fact that it is not true – that there is dependency as depicted – makes me wonder why you think you “proved” it.

    in reply to: Don’t Be Fooled by Boxes and Lines (MG) #28803
    Max Guernsey
    Keymaster

    I am glad it was useful.

    The one big problem i see is that ypu think the short bit of code ypu put in this thread matches the design, when I proved it does not.

    in reply to: Don’t Be Fooled by Boxes and Lines (MG) #28802
    Max Guernsey
    Keymaster

    You may or may not have wasted your own time but you have not wasted mine. I think that version 3 (linked in a previous post) of this blog entry is a lot stronger as a result of this debate. You forced me to demonstrate the ambiguity not as a result of surprise but as a result of two alternative (and equally valid) interpretations of the same diagram.

    I actually didn’t say what you said was irrelevant. I said the answer wasn’t something you could detect from a diagram. Then I supplied you concrete evidence to support that claim: two bodies of code that both fit the diagram (as “completely” as possible in their respective cases).

    My point is that you can only have an incomplete design in UML. The incompleteness is what actually gives it its power – it allows us to pick and choose what matters in a particular context.

    Now, as a result of the debate, I’m rethinking the whole article – much as happened with another entry in a conversation with Scott before I opened conversation up to the wider audience.

    Maybe I don’t want to be Admiral Ackbar, here. Maybe I want to lead with “here’s a way that diagrams are really powerful” and end with “but there’s a trap into which you might fall.

    I’ll have to think about that over the weekend.

    in reply to: Don’t Be Fooled by Boxes and Lines (MG) #28801
    Max Guernsey
    Keymaster

    I will write these blogs when I will have the time and will to do so.
    You asked for comment on your blog.
    I feel the entire premise of the blog, whether the design sits in the code or not, is flawed.

    If you have an incomplete design in UML you cannot depend on that UML diagram.

    The point I am trying to make, and that you are painfully evading, is that just by looking at the (perhaps) incomplete design diagram, I can tell whether the diagram is complete or not. I do that by asking the simple questions I outlined above. I told you what the conclusion is given the two possible answers, and how I can tell whether the code would be horrible or not.

    Instead of trying this technique out, or ask me for clarification, you keep telling me what I am saying is irrelevant.

    So – to this end, I feel that I am wasting your time, Max. Please publish your posts at your pleasure.

    Peace out.

    in reply to: Don’t Be Fooled by Boxes and Lines (MG) #28800
    Max Guernsey
    Keymaster

    Max and me are as thick skinned as an elephant wearing another elephant’s skin.

    Man I wish I had the skills to create an elephant Buffalo Bill animation and set it to Goodbye, Horses, right now.

    You’ll all just have to imagine it. Go on, imagine it!

    in reply to: Don’t Be Fooled by Boxes and Lines (MG) #28799
    Max Guernsey
    Keymaster

    If you type that one more time while looking into a mirror, I’ll appear behind you when you turn off the lights.

    That said, look again, Grasshopper.

    in reply to: Don’t Be Fooled by Boxes and Lines (MG) #28798
    Max Guernsey
    Keymaster

    I’ll admit I didn’t get the snapping thing, actually. I imagine I’ll start to get more up to date with all the SJW terms in about five years, though hardly because I want to learn them.

    I second that, though.

    Don’t worry about Amir and I hurting each other’s feelings. It’s extremely improbable and our own problem, should in the unlikely event that it happened.

Viewing 15 posts - 1 through 15 (of 75 total)