Too much flexibility can hurt

Bendy giraffe by Chris Crafter @iStockphoto

I’ve learnt the hard way that sometimes, designing and coding an application to handle every single kind of scenario is painful. It hurts to maintain and it hurts when it comes time to grow. Flexibility is overrated.

With experience, comes wisdom. I learnt to set limits on what an application can do while still adhering to requirements. It’s when I didn’t assert my programming expertise to inject doses of practicality into users (and their customers) that I run into trouble.

Unbounded flexible requirements

It used to be an Excel spreadsheet macro-run calculation. It was simple and effective. Right till the point where the user had to manage many customers (which was a good thing). Then he had to deal with some non-standard calculations from the customers that’s hard to use macros to run (which was not so good).

So he came to my (ex) manager and wanted a system, an application to help grow and sustain this business. Parameters to the calculation algorithm were discussed. Business logic were added. Reports were needed. Database tables with master and detail relations had to maintained. User groups, profiles, access rights.

It just grew and grew.

Then the customers started pushing their way. They wanted a more customised agreement with the user, which resulted in more customised solutions and parameters to the existing agreements.

So my manager and my colleague discussed at length and cracked their brains for a generic application solution. It had to include the customised parameters and still work for every single existing customer agreement. After much head-cracking, a flexible and generic solution was found.

Then the data source files were modified. Had to change a little. The accounting system required something from the application. Had to change a little. The tax in Singapore changed from 3% to 5%. Had to change a little. The tax will probably change, so made sure future tax changes were catered for. Cracked brain a bit more. The customers wanted something more. Had to change a little.

Granted, some of the changes were forced upon us, and the application had to adapt. What about the changes where there was some control? What if the user had been a bit more adamant about the agreements, to simplify his relations with all his customers by having set conditions and parameters in his contracts?

Sure, he might lose some business. Yet his existing customer contractual agreements would be easily understood. Right now, some of his contracts contain wildly different calculation logic than some others. And the application had to cater to every single one of those logic conditions.

And it’s hard. It’s like trying to find the ultimate single explanation that unifies all the four fundamental forces. There is that distinct possibility that there might not be one.

Unbounded limits of depth

I was once asked for advice on another team’s project, which involved some storing of user and departmental data. They were doing some feasibility analysis, and there’s this requirement that theoretically, data about users could be stored to infinite levels of depth.

For example, a clerk could be reporting to a supervisor, who’s reporting to a manager, who’s reporting to a senior manager, who’s reporting to a director and so on. The users of that team wanted the flexibility to dynamically change user group relations and store many levels of users, as in unlimited.

Very few things stretch to infinity and still work practically. When credit card companies say you have unlimited credit, what they meant was that you have a very very large credit limit. When web host companies say you have unlimited storage space, what they meant was that you have a very very large amount of bytes to play with.

The word “unlimited” refers to the fact that you are very highly unlikely to ever reach the maximum limit imposed. There’s still a limit. It’s just that you are very highly unlikely to ever reach it. Get the drift?

So back to the project. What the users want was not unlimited levels of depth. What they want is the flexibility to go up to any number of depth levels. So I asked the team members, “What is the highest number of levels the data can go up to?”

5. Maybe. So I told them to just write their application based on a maximum depth level of 8. Their users would probably never hit this limit. Even if they did hit the limit, the code should have been written such that it’s easy to extend anyway, so it’s not a problem.

But what about game modding?

That’s slightly different. I’ve been talking about logic flexibility, the ability to change the rules of the program in a dynamic way. Game modding involves data flexibility.

Game programmers still write code based on specific rules and logic. But they allow their code to work with a large variety of data, thus increasing the flexibility of the code. This is one of the ways computer games extend their lifespan.

For example, The Sims have set rules on the behavioural simulation of virtual people. Yet by allowing user generated content, such as custom furniture, hairstyles, clothes, players have much more varied experiences. The rules and logic didn’t change. The data did.

Closing

In short, design your application to be more generic than the requirements you receive. This allows some room for changes and improvements with little code change. However, you don’t have to cater for the largest possible set of scenarios that can possibly happen.

Know when to stop expanding your code’s limits.