| Software Flexibility (Avoiding the next hack) As computer scientists, it often feels like our job is to tell the business user, "No, we can't do that because the software you asked for, and we built, doesn't allow it ..." Then, after a long and relatively silly meeting where your soul dies a little, the business user typically gets 80% of what they wanted (and are no more than 8% satisfied), and horrible hack number 20456 gets implemented. Some hacks are innocuous-looking enough. A seldom-used salary column stores a supplemental email address. That column was mostly empty, and our super urgent need is more important than why this column was added, right? (Clearly, they were storing a number in a text column, so perhaps they got what they deserved?) These "misappropriation of column" hacks are unlikely to bother much code, but untangling the mess can be a substantial undertaking when they do. Other hacks are far more heinous. Say you have a system where users order products. A longstanding business rule is that if an order is paid with a credit card, a coupon for 20% off is sent. The solution was hardcoded into the application code; everything worked, met requirements, and passed all the tests... so the programmers moved on. This seems like an acceptable solution to a new person who does not know how business works. But a few time units later (days, weeks, probably not months later), the business user comes in and says, "Starting tomorrow, all orders get the same coupon." After profanely shouting something, including the word "tomorrow," in your head, It is time to make it happen. So you start hunting around. How is the current coupon code sent? Is there a setting to determine who gets it? If not, how can we change the code? Of course, in my (aggregated from other true stories) story, we know that the method created to send coupons was hard-coded to be triggered in one (and only one) way. Given the time constraints of "tomorrow," are likely too fast for the average company... horrible hack number 20457 is probably coming up next. This hack (as stated, based in truth) was put into place where customers not paying with a credit card would have a non-processed credit card charge added by the person taking the order. This fake charge caused a coupon to be created, and orders and payments were still processed. In a few days, those payments were simply deleted. Hack completed, and quite successfully, too... in terms of a coupon being sent. Unfortunately, now it looks like all orders are paid (at least somewhat) by credit card. Slowly, customers noticed reports all say 100% of orders were paid for electronically. The Data Warehouse/ETL team has to spend days and weeks working on hack #20458 because, as it turns out, reporting data didn't wait for the fake payments to be deleted before loading data to the Data Warehouse. And so on. How do we avoid hacks such as these? If you thought to yourself, "Everyone should just say no to the request and take the time to build the new iteration correctly," you win the optimist of the week prize. Sometimes you have to do the request immediately. My previous boss occasionally transmitted an offer to the members, and we had a few hours to implement it. Only sometimes is this something that you can prepare for. The real answer is that we cannot completely stop it. Software can never be created so perfectly that we can cover everything someone comes up with within 10 minutes, no matter how good we are. But when creating software, we certainly can see places where flexibility will likely be needed. Understand your customer, and realize that the customer's needs are very likely to grow faster than you can adapt rigidly written software. Even if you have to hard code everything, just modularizing code to individual activities that make sense is always good. For example, if the coupon ordering process was its own piece of code or its own microservice, the solution to this problem may have been easier. Achieving the right amount of flexibility is a work of art. Too much, and you are wasting time. Too little, and you are potentially wasting a lot more time. Knowing where that balance is a very tough challenge that generally comes with a lot of experience. Louis Davidson (@drsql) Join the debate, and respond to the editorial on the forums | 