9 ms·

Time to throw the cat amongst the proverbial pigeons and start the year 2023 off with discord and disharmony. Microservices are a solution to a problem. TDD is

Time to throw the cat amongst the proverbial pigeons and start the year 2023 off with discord and disharmony. Microservices are a solution to a problem. TDD is a solution to a problem, the same problem. Both are solutions that themselves create more, and worse, problems. Thanks to the hype driven nature of software development the blast radius of these 'solutions' and their associated problems expands far beyond the people afflicted by the original problem. That problem? Not using statically typed languages. TDD attempts to reconstruct a compiler, poorly. And Microservices tries to reconstruct encapsulation and code structure, poorly. Maybe if you don't use a language which gets hard to reason about beyond a few hundred lines you won't need to keep teams and codebases below a certain size. Maybe if you can't do all kinds of dynamic nonsense with no guardrails you don't have to worry so much about all that code being in the same place. The emperor has no clothes, he never had. Edit: to reduce the flame bait nature of the above a bit. Not in all cases, I'm sure there are a very few places and scales where microservices make sense. If you have one of those and you used this pattern correctly, that's great. And splitting out components as services is not always bad and can make a lot of sense. It's the "micro" part of "microservices" that marks out this dreadful hype/trend pattern I object to. It's clearly a horrible hack to paper over the way dynamically typed codebases become much harder to reason about and maintain at scale. Adding a bunch of much harder problems (distributed transactions, networks, retries, distributed state, etc) in order to preserve teams sanity instead of just using tooling that can enforce some sense of order.

ollien 4y ago
The assertion that TDD is a solution to dynamic typing falls apart when you consider that the TDD dogma was born out of Java programmers. I won't argue that Java has the most expressive type system, but it _is_ statically typed.
- Guid_NewGuid 4y ago
  My understanding is that it's kind of a 3-pronged thing, It originates (or is "rediscovered") by Kent Beck working in, at-the-time, Smalltalk. It has huge adoption in the RonR community. And lastly the usual Java suspects who never met a bad pattern they couldn't massively overadopt, e.g. the so-called "Uncle" Bob who never met a pattern he couldn't jam into code to overcomplicate it.
  - ollien 4y ago
    You know, I knew there was a major association between TDD and XP (wonder why!) and I had always heard of XP being Java related, but looking deeper I'm not sure that's has true as I thought
  - hbrn 4y ago
    > It has huge adoption in the RonR community Is that even true? DHH (RoR creator) hates TDD.
    - Guid_NewGuid 4y ago
      It's been hard to find a timeline or more general history of TDD and I should have probably used the word "had" above. But my understanding is RSpec[0] was a huge driver of the test driven development hype cycle. While DHH[1] has, as of 2014, come out against TDD and was probably never 100% on-board he is not the whole community and that's still a gap of 9 years where, in my understanding, it was broadly popularised as both "the way you should be doing things in Rails" and, as with most things in Rails "the way everyone should be doing things". [0]: https://www.stevenrbaker.com/tech/history-of-rspec.html https://www.stevenrbaker.com/tech/history-of-rspec.html [1]: https://dhh.dk/2014/tdd-is-dead-long-live-testing https://dhh.dk/2014/tdd-is-dead-long-live-testing
- randomdata 4y ago
  Not to mention that before TDD the same documentation was provided as plain text. TDD simply realized that if the documentation was also executable that the implementation could be automatically validated for compliance against the documentation. The idea that you are reconstructing the compiler doesn't even track on the surface. It is true that one may use testing to stand in for the lack of static typing, which is no dobut what the parent is talking about, but TDD != Testing. Testing long predates TDD.
rched 4y ago
I don't think this is true at all. A compiler can't check that your logic is correct. There may be a bit of overlap in the things verified by tests and a compiler but they don't solve the same problem. How are static types a requirement for encapsulation? Dynamic languages are perfectly capable of providing encapsulation. Statically typed languages are also perfectly capable of having very poor encapsulation.
hbrn 4y ago
> That problem? Not using statically typed languages. TDD was invented by a Java programmer. How does that fit into your world view?
- com2kid 4y ago
  Java's original type system, while static, was far from being powerful enough to provide strong guarantees of safety. Saying age is an int is great, but Java doesn't let you say age is an int ranging from 0 to 130. You can of course create an age object, but the constraints on that object cannot be expressed within the type system. So you have to add unit tests instead, the unit tests in effect extend the type system out to be as powerful as type systems from the 80s. Yay, progress! :/
  - hbrn 4y ago
    > Java doesn't let you say age is an int ranging from 0 to 130 This sounds good on paper, but good luck passing your custom types to third party libraries. Or even doing something as simple as calculating average age. You do realize the more powerful the type system is, the more closely it is going to resemble programming language, which means that structures you build on top of it will contain bugs? You're not really solving bugs, you're just pushing them to another layer.
    - com2kid 4y ago
      > This sounds good on paper, but good luck passing your custom types to third party libraries. Or even doing something as simple as calculating average age. Ada solved this in the 80s, it isn't some unresolved field of comp sci. (Java already does this for array bounds!) > You do realize the more powerful the type system is, the more closely it is going to resemble programming language, which means that structures you build on top of it will contain bugs? You're not really solving bugs, you're just pushing them to another layer. Unit Tests are no different, except with worse syntax than built in language support. At least with support in the type system you can turn off range checks for production builds. Meanwhile unit tests only run when invoked, giving less confidence than type checks that undergoing simulated usage as part of daily test builds. There is of course a gradient, JavaScript exists on one side of that gradient (unit tests are needed for everything, starting with what type of object is even being returned), Java exists in the middle, and you have actual type safe languages farther along. The point I was originally aiming to make is that Java is statically typed, but its type system is not so powerful as to negate the need for unit tests.
randomdata 4y ago
Microservices has little to do with tech. It is a way of organizing teams of people, funnelling all communication between teams through well defined specifications instead of ad-hoc meetings. It is not clear where static typing, or lack thereof, comes into play here. TDD is a method of documenting your application in a way that happens to be self-verifying. You could use a Word document instead, but lose the ability for the machine to verify that the application does what the documentation claims that it should. Static typing does provide some level of documentation as well, but even if you have static typing available static typing isn't sufficient to convey the full intent that your documentation needs to convey to other developers.
- Guid_NewGuid 4y ago
  # Microservices I think at the root this idea that Microservices provide this technical solution to a social issue, coordinating teams at scale, hides the driving motivation. Why can't the teams work on the same codebase and the same database? (again note my edited in disclaimer in the GP post that maybe at certain rare scales it's necessary). What is a well defined specification and why is it only a REST/proto/whatever network API? Why not a defined interface or project/library? Why aren't teams at this scale working in languages that support defining these things in code without adding a complicating, latency and error-inducing, network call? Statically typed languages are just superior at encoding this "well defined specification". It's a large part of their reason for being. Sure you can still bypass it and do reflection or other naughtiness, but we shouldn't pretend a network call is the only solution. # TDD Testing is certainly a way to provide a self-verifying application. TDD is a toxic, hype-driven, mess that has led many good developers astray. Static languages have their own devils here, mocking being chief among them (not to mention the Java clown brigade and their own enthusiastic adoption of -- originally Smalltalk conceived -- TDD). I added TDD both to annoy people but also to illustrate the general point. These are both concepts derived from the obvious drawbacks of dynamically typed languages that are then treated as generalist answers to complexity in software. If you'll allow me some pseudo-intellectual waffle, the complexity of a software system C_dynamic + C_software = C_total, that is, complexity of dynamically typed languages and their lack of rigour, plus complexity of software and the domain as a whole gives you total complexity. These approaches primarily target the dynamic complexity. Therefore introducing them and all attendant drawbacks in places where total complexity doesn't include the dynamic complexity because tools and approaches to remove this source of complexity are used actually worsens the entire field.
ReflectedImage 4y ago
Dynamic typing + Microservices + Unit Tests just blows everything out of the water on Development Speed / Time to Market. Most important thing for lots of startups and companies is Time to Market. Traditional static typing based approachs are just a bad joke (3 times slower on average) in comparsion. That's why we have the whole microservices and dynamic typing thing going on, because businesses that use it beat up businesses that don't. It's pretty simple really.

ollien 4y ago

The assertion that TDD is a solution to dynamic typing falls apart when you consider that the TDD dogma was born out of Java programmers. I won't argue that Java has the most expressive type system, but it _is_ statically typed.

Guid_NewGuid 4y ago
My understanding is that it's kind of a 3-pronged thing, It originates (or is "rediscovered") by Kent Beck working in, at-the-time, Smalltalk. It has huge adoption in the RonR community. And lastly the usual Java suspects who never met a bad pattern they couldn't massively overadopt, e.g. the so-called "Uncle" Bob who never met a pattern he couldn't jam into code to overcomplicate it.
- ollien 4y ago
  You know, I knew there was a major association between TDD and XP (wonder why!) and I had always heard of XP being Java related, but looking deeper I'm not sure that's has true as I thought
- hbrn 4y ago
  > It has huge adoption in the RonR community Is that even true? DHH (RoR creator) hates TDD.
  - Guid_NewGuid 4y ago
    It's been hard to find a timeline or more general history of TDD and I should have probably used the word "had" above. But my understanding is RSpec[0] was a huge driver of the test driven development hype cycle. While DHH[1] has, as of 2014, come out against TDD and was probably never 100% on-board he is not the whole community and that's still a gap of 9 years where, in my understanding, it was broadly popularised as both "the way you should be doing things in Rails" and, as with most things in Rails "the way everyone should be doing things". [0]: https://www.stevenrbaker.com/tech/history-of-rspec.html https://www.stevenrbaker.com/tech/history-of-rspec.html [1]: https://dhh.dk/2014/tdd-is-dead-long-live-testing https://dhh.dk/2014/tdd-is-dead-long-live-testing
randomdata 4y ago
Not to mention that before TDD the same documentation was provided as plain text. TDD simply realized that if the documentation was also executable that the implementation could be automatically validated for compliance against the documentation. The idea that you are reconstructing the compiler doesn't even track on the surface. It is true that one may use testing to stand in for the lack of static typing, which is no dobut what the parent is talking about, but TDD != Testing. Testing long predates TDD.

rched 4y ago

I don't think this is true at all. A compiler can't check that your logic is correct. There may be a bit of overlap in the things verified by tests and a compiler but they don't solve the same problem. How are static types a requirement for encapsulation? Dynamic languages are perfectly capable of providing encapsulation. Statically typed languages are also perfectly capable of having very poor encapsulation.

hbrn 4y ago

> That problem? Not using statically typed languages. TDD was invented by a Java programmer. How does that fit into your world view?

com2kid 4y ago
Java's original type system, while static, was far from being powerful enough to provide strong guarantees of safety. Saying age is an int is great, but Java doesn't let you say age is an int ranging from 0 to 130. You can of course create an age object, but the constraints on that object cannot be expressed within the type system. So you have to add unit tests instead, the unit tests in effect extend the type system out to be as powerful as type systems from the 80s. Yay, progress! :/
- hbrn 4y ago
  > Java doesn't let you say age is an int ranging from 0 to 130 This sounds good on paper, but good luck passing your custom types to third party libraries. Or even doing something as simple as calculating average age. You do realize the more powerful the type system is, the more closely it is going to resemble programming language, which means that structures you build on top of it will contain bugs? You're not really solving bugs, you're just pushing them to another layer.
  - com2kid 4y ago
    > This sounds good on paper, but good luck passing your custom types to third party libraries. Or even doing something as simple as calculating average age. Ada solved this in the 80s, it isn't some unresolved field of comp sci. (Java already does this for array bounds!) > You do realize the more powerful the type system is, the more closely it is going to resemble programming language, which means that structures you build on top of it will contain bugs? You're not really solving bugs, you're just pushing them to another layer. Unit Tests are no different, except with worse syntax than built in language support. At least with support in the type system you can turn off range checks for production builds. Meanwhile unit tests only run when invoked, giving less confidence than type checks that undergoing simulated usage as part of daily test builds. There is of course a gradient, JavaScript exists on one side of that gradient (unit tests are needed for everything, starting with what type of object is even being returned), Java exists in the middle, and you have actual type safe languages farther along. The point I was originally aiming to make is that Java is statically typed, but its type system is not so powerful as to negate the need for unit tests.

randomdata 4y ago

Microservices has little to do with tech. It is a way of organizing teams of people, funnelling all communication between teams through well defined specifications instead of ad-hoc meetings. It is not clear where static typing, or lack thereof, comes into play here. TDD is a method of documenting your application in a way that happens to be self-verifying. You could use a Word document instead, but lose the ability for the machine to verify that the application does what the documentation claims that it should. Static typing does provide some level of documentation as well, but even if you have static typing available static typing isn't sufficient to convey the full intent that your documentation needs to convey to other developers.

Guid_NewGuid 4y ago
# Microservices I think at the root this idea that Microservices provide this technical solution to a social issue, coordinating teams at scale, hides the driving motivation. Why can't the teams work on the same codebase and the same database? (again note my edited in disclaimer in the GP post that maybe at certain rare scales it's necessary). What is a well defined specification and why is it only a REST/proto/whatever network API? Why not a defined interface or project/library? Why aren't teams at this scale working in languages that support defining these things in code without adding a complicating, latency and error-inducing, network call? Statically typed languages are just superior at encoding this "well defined specification". It's a large part of their reason for being. Sure you can still bypass it and do reflection or other naughtiness, but we shouldn't pretend a network call is the only solution. # TDD Testing is certainly a way to provide a self-verifying application. TDD is a toxic, hype-driven, mess that has led many good developers astray. Static languages have their own devils here, mocking being chief among them (not to mention the Java clown brigade and their own enthusiastic adoption of -- originally Smalltalk conceived -- TDD). I added TDD both to annoy people but also to illustrate the general point. These are both concepts derived from the obvious drawbacks of dynamically typed languages that are then treated as generalist answers to complexity in software. If you'll allow me some pseudo-intellectual waffle, the complexity of a software system C_dynamic + C_software = C_total, that is, complexity of dynamically typed languages and their lack of rigour, plus complexity of software and the domain as a whole gives you total complexity. These approaches primarily target the dynamic complexity. Therefore introducing them and all attendant drawbacks in places where total complexity doesn't include the dynamic complexity because tools and approaches to remove this source of complexity are used actually worsens the entire field.

ReflectedImage 4y ago

Dynamic typing + Microservices + Unit Tests just blows everything out of the water on Development Speed / Time to Market. Most important thing for lots of startups and companies is Time to Market. Traditional static typing based approachs are just a bad joke (3 times slower on average) in comparsion. That's why we have the whole microservices and dynamic typing thing going on, because businesses that use it beat up businesses that don't. It's pretty simple really.