I just recently started with a new employer and have to choose my benefits – healthcare and so forth.

This is a normal event for most people. And most systems are built to handle this scenario just fine.

The company has also just announced that the benefits provider is changing. Again, this is a common enough event that systems should handle this without complaining.

But then you mix the two. Before my original selections are processed I need to change my elections because they’ve already changed. This is something that broke ADP’s system.

I can look at this from two different points of view. 1) They should make the system smarter. 2) The system just needs to handle the common cases and delegate to people when things get out of hand.

At Insurance.com we would always pick #1. The problem with is the number of cases you need to deal with skyrockets. And every case can interact with every other case. The coding is nearly insurmountable. The testing is even worse. You can build a system that you think works, but you have no way of proving that it’s working. You can do TDD to your heart’s content, but you can never account for all of the business rules and the interactions. (Ok, I guess you probably can, but never on time)

Option #2 seems like a cop-out. And it is. But it’s a safe cop-out.

Trisha has to spend a little bit of time on me and some other folks and manually set things up. Then it’s working. And we’re all happy.

How is that more efficient? Well, for one instead of spending weeks dealing with one set of business rules to figure out all permutations the system just punts. The empowered business owner, can make a game-time decision to set up things the way they should. She knows everything (more than a programmer can ever hope to know about a specific situation) and doesn’t have to ponder every possible set of cases — just my case. She decides, and it’s done.

The problem with #1 is that even if you nail all the rules, they keep changing and evolving. As things get even more complex (systems rarely get simpler over time) the possible interactions keeps exponentially going up. The rate of change commensurately keeps going down.

People are better at dealing with these poorly defined things than a program. People can make a snap decision, programs have to try to meet a deployment schedule.

Sometimes being in the middle of it can be frustrating. It can take longer and you wonder why the person designing it messed up and didn’t handle your case. But sometimes it pays just to have the smarts of a real-life person at the wheel.

Simple repetitive things are for computers to solve. For complex one-offs, I like to trust a person.

She’s on top of things though. In the end I know my benefits are set up right because a person made sure they were.

This is similar to my previous business post: The Cost of Perfection is Too High… this takes it the next step. Not only is it too expensive to be perfect, it’s too expensive to even think about getting perfect!

So many times in meetings you quickly get together and solve the main problem that’s sitting in front of you. High fives all around and the project gets scheduled.

Then you start thinking about how there are holes in the idea. (I’m as guilty as anyone BTW) You start with a solution that works for 95% of the people out there and then start to think of the last 5%. How can you get that last bit? Or perhaps it needs to be configurable at runtime? Or maybe a test? What about that partner, we can’t have it be on for them.

The list is endless.

Before you know it the complexity of the solution goes up by an order of magnitude. The once simple project is now a beast. As the project grows in complexity the reach of it grows as well. More people need to be brought in to make sure the growing scope doesn’t impinge on their fiefdoms — of course it does and adds ever more complexity.

It’s a vicious cycle.

The product that gets built is now hard to test and too hard to use for the normal case. You would be sure that it covers all of the use cases in the spec if you could only test it, which invariably you can’t. The product that’s delivered to solve the world’s problems can’t even be proven to solve any problem. The complexity that the business community asked for in the live configuration capabilities is now too hard for them to use.

Now you have this albatross that was too expensive to build to throw away. Now you have no choice but to maintain it.

—

Or you could have just implemented the 95% solution and wait for real life to tell you what you need to add. For all you really know, the “5%” might never even be hit anyway.

Don’t over-plan for the future. You’ll most likely be wrong anyway.