All structure is derivative. It's one of those things that once you see, you can't un-see. I blogged about this a while back: http://tiny-giant-books.com/blog/

All structure is derivative. It's one of those things that once you see, you can't un-see. I blogged about this a while back: http://tiny-giant-books.com/blog/process-scale-invariance-uml-diagramming/ http://tiny-giant-books.com/blog/process-scale-invariance-um... I'm not a religious TDD person. I think it's the only way to professionally code mutable OO. At the business level it's the only way to manage your goals and progress. (ATDD, that is) But the thing that TDD brought to the table that was missing from the larger discussion is that things exist in code (and infrastructure) for reasons. When you can create as much stuff as you like, it's important to make those reasons explicit. TDD is not a test discipline. It's a design discipline. You write the test first, then the code/infrastructure/business/whatnot is created to support the test. It's not just a fashionable thing to do. It's the only sane way to plan out architecture. Otherwise you're just kind of looking at thing ascetically. And this is the reason we have such a framework explosion. You write function that does X, then you imagine X prime and X two, then you generalize, then you imagine some more. This is the same thing we see in startups: the desire to build over the desire to meet needs. Worst-case scenario is that people actually like 2 or 3 things out of your 100-thing toolset. Then you're off to the races building another 100. Blockchain is still struggling with all of that. It's such an attractive tech they'll probably get it worst than most. It's quite seductive to see something you might need instead of something you actually need.