1. 14

I think this guy has caught the tail of something important…..

…but he is saying it very very imprecisely and very very badly, repeatedly and at great length.

Every time I think I understand what he is saying…. and try make a clearer statement, the mathematician in me proposes a counter example which rubbishes my statement.

Can anybody come up with a TL;DW; that will hold water?

In particular these statements make the mathematician in me howl about the lack of precision.

09:50 Being able to take a piece of code, delete it and rewrite it from scratch in one or two days is extraordinary valuable.

11:50 We optimize for deletability by moving away from monoliths and optimize for decoupling.

13:58 Greg’s rule of thumb: The time it takes to do a full rewrite for part of the software should not exceed one week.


  2. 1

    I haven’t watched the talk yet, but I plan to since I’ve found other talks by Greg Young to be interesting. What I got from the summary is that big(*), tightly coupled software is hard to work with and evolve. I work with a system that meets that description and I can agree. Microservices is one solution, but just constraining each individual bit of a monolith to not grow too large and be loosely coupled with the rest is another.

    (*) He mentions 100,000 lines, but I’m guessing that he’s also talking about systems a bit smaller than that.

    1. 1

      He could have said, “Coupling Bad, Cohesion Good”, and walked off the stage? And we could all have nodded sagely and said, yes, we know.

      I think, perhaps, he is on to the tail of something, but said it very badly.

      Something about decomposing systems into processes and state might have been something he was on about. I’m not sure.

      Sure I can delete any darn chunk of any system and rewrite it in a week… so long as I choose a small enough chunk.

      So that isn’t quite what he means.

      What defines a monolith? All in the same process? All on the same machine?

      I remember one system I worked on was decomposed into a front end data collector and parser which fed a sql server which had a daemon herding it and was view / controlled by a graphical front end. Sounds exactly like what he was talking about, nice non-monolithic system. Except it displayed quite a lot of Connascence Coupling between the various components.

      ie. Deleting any component and rewriting them would leave you in a world of pain as you slowly uncovered the various hidden couplings.

      ie. I wouldn’t point my colleagues at Greg’s talk, I would point them at http://connascence.io/

      But I still wonder if I’m missing something.

      I wonder if he isn’t just setting things up for his next talk on event sourcing or something.

    2. 1

      “The definition of a refactor is: I either change my tests or my code and I only change one out of the two.”

      Sure, you shouldn’t be making broad changes to the tests, but what if you are changing the API, for example procedural to OOP? Even just moving a single global function into a class could require changing 20 tests, if you now need to create an object for each on that could be quite a change.

      1. 4
        1. Extract the global function’s logic to the class and have the function use the class internally without changing tests.
        2. Update the tests to use the class.
        3. Remove the global function.

        Obviously it can be more complicated, but in principle, making sure that only one of tests/logic change at a time is more resilient against accidents than doing both at the same time.

        1. 2

          He does have a slightly too narrow definition of refactoring.

          The ori9ginal and I believe correct definition I believe states “no change in behaviour”.

          So you are correct in saying a change in API can result in a change in the tests, but no change in behaviour.

          1. 1

            Ok great, I can fully agree with that.

        2. 0

          23:08 At any point in time, I’m willing to delete my code and rewrite it from scratch. This is the unix philosophy, this is the Erlang philosophy, this is microservices, this is SOA, this is actors.

          Good luck with that.

          1. [Comment removed by author]

            1. 1

              The concept is valid (you should be able rewrite).

              The precision is lacking.

              What precisely is the boundary for the rewrite? All of debian? One package? One executable? One Process? One class? One method? One line?

              1. 0

                Take the specification of Postgress and the test framework, delete the code. Rewrite.