mike.mainguy

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...

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 ...

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 mechanis...