<-- home

Thermodynamics

Published: January 22, 2018

Edited: March 11, 2021 (v0.0.11)

A revered colleague of mine shared a thought on the internet the other day. I just had to capture the thought here, since I feel like I see this all the time.

So many software engineering trends are driven by a misaccounting of complexity. Change how we organize a system, misunderstand the costs of the new system, tell everyone about the revolutionary new idea: you’ve got a silver bullet on your hands!

Software complexity should be treated like thermodynamics: if you think you’ve eliminated complexity instead of just unknowingly dispersing it into adjacent systems, treat your results with maximum skepticism.

How elegant!

-

CAP theorem? Good example.

-

I’ll use the remainder of this note to list out some of the debates I’ve seen in the wild that may benefit from reflecting on the laws of thermodynamics, along with some follow on reading you can do if you’re interested.

–

Second order effects - beware!

Science, ceteris paribus, didn’t do this well enough. Try again?

You didn’t understand the space well enough? Thermodynamics, pushed complexity somewhere else and caused unintended effects? Microservices?

On https://vladikk.com/2020/04/09/untangling-microservices/,

He’s missing one major thing, which is that a big difference between a monolith and microservice system is that you’re trading code complexity for operational complexity. And if your operational tools aren’t ready, then you won’t be ready and you’ll find the whole experience to be much too complex. I suspect that at a high level, people just see complexity, failure, and confusion as themselves, as opposed to having types. And so they go to a microservice environment and “bad things” happen and then they improperly blame their development philosophy rather than the way they applied that development philosophy.

–

Side effcts.

One of the side effects of getting rid of business analyst team is that devs need to understand lix, ramping, business metrics.

One of the side effects of getting rid of test team is that the devs need to understand all types of testing, integrations, release, etc.

Not understanding side effects may move complexity (and problems) in decision making.

\n

  1. [1]M. D. Penta, “Understanding and Improving Continuous Integration and Delivery Practice Using Data from the Wild.” 2020 [Online]. Available at: https://on24static.akamaized.net/event/22/47/06/0/rt/1/documents/resourceList1589293089866/sigsoftwebinarmaxdipentacompress1589293087671.pdf. [Accessed: 12-May-2020]
  2. [2]V. Khononov, “Untangling Microservices, or Balancing Complexity in Distributed Systems.” 2020 [Online]. Available at: https://vladikk.com/2020/04/09/untangling-microservices/. [Accessed: 22-May-2020]
  3. [3]M. Klein, “Monorepos: Please Don’t!” 2019 [Online]. Available at: https://medium.com/@mattklein123/monorepos-please-dont-e9a279be011b. [Accessed: 2020-Apr-7AD]
  4. [4]C. Sridharan, “Testing in Production, the safe way.” 2018 [Online]. Available at: https://medium.com/@copyconstruct/testing-in-production-the-safe-way-18ca102d0ef1. [Accessed: 01-May-2020]
  5. [5]M. T. V. Gleison Brito Ricardo Terra, “Monorepos: A Multivocal Literature Review.” 2018 [Online]. Available at: https://arxiv.org/pdf/1810.09477.pdf. [Accessed: 2020-Apr-7AD]
  6. [6]E. Murphy-Hill, “Advantages And Disadvantages Of A Monolithic Repository.” 2018 [Online]. Available at: https://people.engr.ncsu.edu/ermurph3/papers/seip18.pdf. [Accessed: 2020-Apr-7AD]
  7. [7]P. Hammant, “Trunk Based Development.” 2017 [Online]. Available at: https://trunkbaseddevelopment.com/. [Accessed: 11-May-2020]
  8. [8]J. L. Rachel Potvin, “Why Google Stores Billions Of Lines Of Code In A Single Repository.” 2016 [Online]. Available at: https://dl.acm.org/doi/pdf/10.1145/2854146. [Accessed: 2020-Apr-7AD]
  9. [9]M. Fowler, “Microservice Trade-Offs.” 2015 [Online]. Available at: https://martinfowler.com/articles/microservice-trade-offs.html. [Accessed: 2020-Apr-7AD]
  10. [10]M. Hawthorne, “I Push, Therefore I Am.” 2013 [Online]. Available at: http://mhawthorne.net/posts/2013-etsy-netflix-I-push-therefore-I-am/. [Accessed: 22-May-2020]
  11. [11]M. Fowler, “Frequency Reduces Difficulty.” 2011 [Online]. Available at: https://martinfowler.com/bliki/FrequencyReducesDifficulty.html. [Accessed: 2020-Apr-7AD]
  12. [12]M. Fowler, “Continuous Integration.” 2006 [Online]. Available at: https://martinfowler.com/articles/continuousIntegration.html. [Accessed: 2020-Apr-7AD]
  13. [13]A. Miller, “A Hundred Days of Continuous Integration.” Microsoft [Online]. Available at: http://www.ademiller.com/tech/reports/a_hundred_days_of_continuous_integration.pdf. [Accessed: 11-May-2020]