Implications of no free will

I have recently come to believe with high probability that free will is simply a misunderstanding of the mass complexity in our universe and that free will does not exist as it is normally defined. I rationalize my belief through induction and that the universe (macro, micro, subatomic, etc) does not shift randomly when observed without rhyme or reason at the smallest time deltas available. 

If you have no free will, meaning that your very next action is predestined, then a seemingly logical progression is that the step following the next is also predestined. If so then everything you will ever do (no matter how many times you reflect on it … weird) have already been “done” and you are just waiting to experience it. 

However if you consider the implications of this idea, it leads to a rather confusing outcome where definitions of concepts like a soul, life, time and fate all seem to solidify.

  • Your soul then can be defined as a constantly changing but always known function of your DNA and the environment you have been exposed to so far.
  • Your life can be likened to a movie that has already been taped and that if accurately modeled enough in a computer could be fast forwarded and predicted with 100% accuracy.
  • Time is then defined as nothing more than a measure of distance in that movie and doesn’t imply uncertainty in the future as it always has for me.
  • Fate is simply a fact.
  • What you will do is what you have already done but you are just waiting to experienced it.

I find it interesting that humans have the ability to do predict things naturally (albeit limited and sometimes flawed) and that perhaps our projections of our futures (especially as we get older) may just be more reasonable than i previously thought

I also wonder if we could get a quantifiable metric on how well a humans can predict the future based on recorded interviews of individuals conducted at differing lengths in the past (1,2,5,10,20 years etc). My guess is pretty well. Doing a quick mechanical turk survey might just tell you a bunch about your future (not that you can change it or anything) :) 

When SOA is appropriate and when it’s not


I have had this itch to investigate the pros and cons of service oriented architecture (SOA) and its derivatives (ROA, WOA, etc) for many years but never really cared enough to do it. Usually because many of the projects I built didn’t use it or the decision had been made a long time ago and it was pretty much irreversible at that point. 

My experience with SOA systems has been at medium/large sized companies and generally I found that it worked sufficiently well for them. However SOA didn’t seem like a vastly superior solution relative to the architectural patterns I had been exposed to over time. SOA just had a different set of trade offs that really just made it feel like a different tool in the tool box. 

Now, I deliberately try to avoid religious wars with tools and somewhere in my mid 20s I stopped caring about what they did in “theory” as well. I care much more as a technically competent entrepreneur about what actually happens when you implement a solution across all of the business and not just the problem at hand (think hiring, execution risk, business flexibility, time to develop, etc).

Now, with my history and viewpoint clearly established i’ll jump into my analysis. 

Given my experience at medium/large companies where SOA is used internally to power the product here are the complaints of SOA that I have heard/experienced:

  • Services are only as good as the best architect on that service team.
  • Its expensive to move engineers from team to team because each service completely different.
  • If a service has a bug you have to wait for the service team to fix it.
  • It is incredibly hard to test changes across multiple services.
  • With each incremental service you add your client requires more integration code (different payloads, protocols, errors etc).
  • When a service introduces breaking changes to an interface it is hard to find who all the clients are and just how big of an impact those changes will have downstream.
  • When there are a nontrivial number of services its difficult to find what services exist and what functionality they expose.

Now let’s go over how SOA is meaningfully different from the traditional object oriented architecture (OOA).

  • You have the flexibility to use different everything in SOA (languages, libraries, operating systems, protocols, web servers, testing tools, etc) per service where as in traditional OOA you typically stay in one language have a list of common dependencies, on a single stack.
  • You usually have stateless communication between components where as in OOA you implicitly have stateful communication with pass by reference mechanics.
  • With SOA everything that is exposed publicly is done intentionally and its harder for “client” engineers to break service abstractions although that doesn’t stop the “owner” engineers from doing it on occasion.
  • In theory you get to deploy your service independently of others (until you make changes that break other clients, which happens frequently enough in practice for me to mention it here)
  • Strict permission control over code bases if you have contractors etc. 

With these differences SOA has the following advantages over OOA in my mind:

  • You can adopt new technologies independently from the rest of the org.
  • Monkey patching, accessing private methods, or otherwise inserting hacks into code you don’t really own is harder to do.
  • Prevents code commit conflicts and enforces ownership contracts.
  • With stateless communication implementation *can* be simpler, it certainly makes threading easier.

Here is my list of disadvantages of SOA vs OOA:

  • Its much more complex and therefore slower to execute initially.
  • You typically need more engineers for the same amount of work.
  • You need sr engineers and architects proportional to # of services.
  • It requires tooling for service discovery, registration and testing.
  • Moving engineering resources has larger fixed costs.
  • Cross service development requires more coordination.
  • Without solid architects there is significant execution risk.

I think SOA is really appropriate for large teams working on complex systems at medium/large profitable “cool tech” companies where the costs can be amortized over a longer time periods with great engineers without threatening the success of the business. I also think SOA is appropriate for communication between companies where each company is a service. At that level you really don’t lose much because few of the OOA benefits are applicable.

If SOA matches your company’s profile then i highly recommend taking a look at this:

If your company doesn’t match the criteria above then I think OOA is probably right for you. It is faster to start, easier to understand, more flexible from an engineering management perspective, and allows you to move much faster with smaller teams. I would also say that even if you are planning on being a huge successful company with 100s of engineers its not worth investing in SOA until you actually feeling the pain of your immense success.

Small aside: SOA’s tradeoffs actually remind me a bit of database sharding but for engineering teams. 

(Lead Image source:

First post in about a year

After a year long hiatus i have finally reconstructed my blog. There is a lot to talk about and not a lot of time to do it in. First thing is to put this placeholder in and start writing later this week. 

blog comments powered by Disqus