Saturday, January 29, 2011

anti-fragile software

I recently watched a video of Nassim Taleb in which he explains the difference between anti-fragility and robustness in terms of economics and nature. A short explanation is that "anti-fragile" describes something that benefits from mistreatment as opposed to "robust" which describes something that can survive or tolerate mistreatment.

After thinking about this, I realized a big problem with software development is that we expend tremendous energy trying to make systems robust, but seem to give little or no thought to making them anti-fragile. To counter this problem, I thought I'd share a few ideas on how to make software development more anti-fragile.

#1 Embrace the idea that unexpected results can often be positive experiences. "Bugs" should be a thing of the past and should simply be observations about what the system does instead of an indictment of how poorly someone has implemented some other person's idea of how the software should function.

#2 Create a culture around facilitating change instead of trying to restrict it. Instead of having a "Change Management Process" or a "Change Control Process", have a "Change facilitation process". The focus should be on getting changes done, NOT restricting them.

#3 Avoid unecessary monocultures. Anybody with a lawn knows how difficult it is to keep out "non-grass" plants (otherwise known as weeds). In the same note, expending effort to keep every server and every desktop on the exact same platform is more effort than can ever be recouped. At runtime, it doesn't matter if your system uses ruby, python, linux, windows, and z Series, it just matters that it works and all the pieces can work together.

These are just a few ideas and as with any solution, there are negative consequences for attempting to pursue this path. What I wonder is, what other things can we do to make development more anti-fragile?

Saturday, January 22, 2011

Is time a side effect of universal expansion?

I'm admittedly an armchair scientist... I believe I was quoted at one point as saying "well special relativity is just a THEORY, so it could be wrong" which was met at the time with a snarl from someone who kinda knew that stuff better than me.

Here's my layman's question: What if our perception and measurement of time is simply is flawed and time is really a function of how much the universe has expanded? Put another way; assuming that universe is expanding at a (mostly) constant rate, might time not be an independent dimension, but simply derivable from the difference in size of the universe?

If this is actually true, then isn't time travel really a lot less complicated? Don't we immediately remove paradoxes like "if I go back in time and kill my father will I ever be born?".

What it might mean is that time is not really some thing that exists independent of the spacial dimensions, but is simply a function of an underlying effect we don't yet fully understand.

Any physicists out there who could explain how to prove/disprove this idea?

Wednesday, January 5, 2011

Your enterprise domain model should not be represented in code

I blame Hibernate and Spring in the javaspace as well as a number of enterprise architecture astronauts who don't know how to communicate the difference between a conceptual model and a physical model (yeah, I'm probably one of them). Any number of java projects I've been on over the last 10 years or so seems to have followed what is now a fairly predictable anti-pattern. I'll call it the massively brittle domain model (MBDM).

The pattern goes like this: Build an java (C#?) data model representing all of the business "things" you think the business needs (extra points for spending a couple years building that). Usually this ends up being a funhouse mirror image of a bunch of relational database tables. Then you expose those objects via some sort of service layer, and build a binary package for all the clients to communicate with the business services. If you really want to make things complicated, use some sort of complicated xml serialization mechanism that requires configuration files or generating stubs and other fun stuff.

I can only imagine this working when the following are true: IF your domain model is perfect the first try, and IF your business doesn't change, and IF there is only one developer and IF there is only 1 server and IF there is only 1 client application.

Let me explain why this will not work in other situations:

First off, because the domain model is distributed as a binary package, the most typical pitfall is to rely on a serialization mechanism that fails the minute you change ANY of the domain entities. This essentially means that any project that uses your services will need to be recompiled every time someone changes the anything in the domain. This has the effect of coupling every client project to the back-end project. This causes a large amount of complexity in coordinating which version of the domain various clients need.

Second, because of #1 your development will inherently resist changes to the domain model. This means that you will descend into a serious of arguments with your business partner that essentially translate "we didn't model it that way and it's a fundamental change to our domain model which will break other systems".

Third, because of #1 and #2 coordinating which version of which domain entity you actually need will become a full time job. In addition, if you have multiple servers and services that are interconnected you will tie up multiple resources trying to keep things in sync.

If you find yourself in this mess, your first step is to remove the binary dependency. Note, this may be very difficult because invariably someone will have introduced secondary and ternary dependencies, most likely via the ubiquitous "utility" package that binds domain model to the binary service implementation. The key thing to do is to forget about the underlying database and binary representation when building services.

Put another way, build services around "things that need to get done and the information necessary to do it". While semantically, this means you will likely build a model for each service, that is better than trying to shoehorn everything into a one size fits all model of reality.

If you're building a new system and someone tells you they're going to build a "enterprise domain model" that "everybody can use" and it'll be "reusable", tell them it's probably a bad idea and point them to this blog post.