Al Shalloway

Forum Replies Created

Viewing 15 posts - 1 through 15 (of 113 total)
  • Author
    Posts
  • in reply to: FLEX and transformation #36317
    Al Shalloway
    Member

    i am replying to your first post

    in reply to: Xtreme Decoupled process Engineering (XDE) #30994
    Al Shalloway
    Member

    Hello Guy,

    Thanks for creating this discussion thread, surprised to find it after 2 months of publishing it.

    The idea of the short lived Bubbles is to promote awareness of shared (decoupled) responsibility among all existing teams. This disruptive and unstable format will increase the need of continuous refactoring which in turn exposes any architectural loopholes.

    You are right in saying that continuous improvement is difficult in this ecosystem. For legacy codebases, it can even slow the development down. The benefit is, when we realise why we want to do it. We want to reduce technical debt as early as possible and as often as we can. Once the teams are used to it, it will become a second nature and help them adapt any situation and be agile.

    Preetam.

    in reply to: Tables #29677
    Al Shalloway
    Member

    The scope I suggested was…

    specify a relationship between two kinds of variation

    So a textual spec when, for instance, there are zero forms of variation would make sense. A textual spec might always make sense. I’m not talking about which is better, just about what a two-dimensional table cross-referencing two different kinds of variation can do.

    As for overcoming the other form of overhead you mentioned, I’d need to understand it better. You said…

    where constructing an underlying model for the table format

    The first problem is that I don’t think there is always a mathematical model required. Take, for instance, a table where you need to cross reference two different factors and choose a rule that best approximates something. The following is like a cartoon of the real domain based on the scraps I picked up from SMEs…

    Let us say we need to decide how to guess two molecules will interact. There are three things that can vary:

    • Left side structure
    • Right side structure
    • Distance

    To make that into two dimensional tables, I would combine the first two into an axis. I’ll call it a reaction category because I don’t know any better.

    Reaction Category from Kind of Molecules Involved
    Small Protein
    Small Small Small-Bio
    Protein Small-Bio Bio-Bio

    There are all kinds of structures so that table would have more entries and be a little more flavorful but it’s good enough for this example.

    Next, I can take the new axis I’ve created by cross referencing two “primary” axes in this domain and relate it to the third axis: distance.

    Interaction Model by Category and Distance
    Small-Small Small-Bio Bio-Bio
    Near Algebraic Waveform Biological
    Far Algebraic Particle Particle

    I don’t think there is an underlying mathematical model required to understand or implement the specified rules. I know enough to know that the shape of those tables are correct but the content are, like I said, a cartoonish representation. If a SME filled out the content, I could implement the rules without any further understanding – somewhere else, we can explain how small molecule algebra works, how (we guess) objects interact on a quantum level, and how they interact as particles.

    All I need to know is how to pick the right one of those.

    It’s difficult for me to envision a scenario where you need to build an underlying mathematical model. If there is a mathematical model that matters and is part of the domain, it ought to be defined explicitly as part of the specification. In such a case, it would be hard for me to see that as overhead. If there isn’t a mathematical model required, then there’s no need to define one and therefore no risk of overhead.

    That’s a dichotomy, which don’t exist in nature nearly as often as people act like they do. Is there some weird third thing I don’t see?

    in reply to: Tables #29675
    Al Shalloway
    Member

    What I’m thinking about writing about is that they actually work 3/3 of the time when there are kinds of variation you need to relate because you can just unfold the portion of the time they don’t look like they work into more 2-dimensional cases.

    in reply to: Essential Refactoring (MG) #28940
    Al Shalloway
    Member

    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 5 years, 10 months ago by Al Shalloway.
    in reply to: Essential Refactoring (MG) #28935
    Al Shalloway
    Member

    So the only difference is the meaning of “small”. You can suggest that it be some small concrete amount of time. But others may “choose” a larger amount of time, based on their experience, choice, etc.

    in reply to: Essential Refactoring (MG) #28929
    Al Shalloway
    Member

    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
    Al Shalloway
    Member

    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) #28923
    Al Shalloway
    Member

    I would not discount the possibility. I would not get hung up on the word “need”. As you suggested, it could be “choose”.

    What is your thesis for this blog?

    in reply to: Essential Refactoring (MG) #28811
    Al Shalloway
    Member

    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) #28810
    Al Shalloway
    Member

    A little of both.

    in reply to: Essential Refactoring (MG) #28809
    Al Shalloway
    Member

    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: Essential Refactoring (MG) #28808
    Al Shalloway
    Member

    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.

    You state “A lot of people who want to “refactor” think primarily of their ultimate design goal. I think what’s happening is people are trying to race to the place they want to be”.

    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.

    in reply to: Don’t Be Fooled by Boxes and Lines (MG) #28807
    Al Shalloway
    Member

    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
    Al Shalloway
    Member

    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.

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