+972 52-548-6969
System flexibility
One of the absolutely most challenging things in designing software systems is that there is really no such thing is a perfect world. A business requirement that is set in stone turns out to be quite malleable. That can cause quite a big hassle for the development team, as they try to anticipate and address all aspects of change ahead of time.
A better alternative would be to not attempt to address all such issues in software, but in wetware.
I recently ordered lunch to go at a restaurant. I already paid and was waiting to get my order when the clerk double checked with me that the order is to go. The ordered was entered as if I was going to eat in the location, instead of taking the food away. After I confirmed that I want to take my order to go, I watched how the clerk fixed things up. She went to the kitchen window and shouted, “that last order, make it to go”. The kitchen staff double checked which order it was, then moved on with their tasks, eventually hanging me a baggie of tasty food to go.
On the way back, I kept wondering in my head how a software system would handle something like this. You’ll need to shred the idea of “an order is immutable once it is paid”, for example. Or you’ll need to add a side channel of additional instructions to the kitchen, etc.
Or, you can ignore the whole thing completely and shout at the cook. In software, that might mean that we’ll keep ourselves agile and provide a “Manual” mode in which a user can enter free text / instructions for the next person on the line to process this.
There are some cases where this would be a bad idea, but mostly these are involved not trusting your users to do their jobs. Sometimes, it is literally the software’s job to force the users to follow a specific path (usually because management decided that this must be so). However, a really important aspect of design is that it isn’t rigid, it allows the user to do their work, instead of working around the software. Part of that involves designing specific places where users can do stuff that you didn’t think that they would need.
For example, in an order, having a “Notes” text field that is editable even after the order is placed, which can be used for further communication. The idea is that you spend just a little bit of time to consider whatever scenarios you didn’t cover and try to give the user something (just bare minimum, maybe even below that), just to allow them to get by. The idea isn’t to provide a solution, but to get something that give the user a choice and that will raise enough feedback so you can plug this into the next iteration of your product.
Not having anything may mean that the users will solve their own problem using something else (email, or even just talking directly to one another) and we can’t have that*, obviously.
* It may sound silly, but in some cases, you literally can’t have that. Certain actions need to be logged, authorized and track appropriately for many purposes.
Comments
Flexible systems often tend to be unwieldy. If a system is trying to cover every possible scenario, it will turn into a monster.
We used to have an in-house change control system, it took 3 clicks to create a "maintenance" request (e.g. change a configuration value).
Recently the pointy-haired bosses adopted a vendor's package (based off SCSM I think). This jack-of-all-trades platform has literally hundreds of options, requires at least 20 clicks, and after 12 months of using it, nobody really knows what on earth makes a request actually flow properly, it all seems like voodoo.
Message-based systems handle the flexibility for a situation like this by adding new messages. In your example, placing the order was a message, and the subsequent change was a separate message. A new message can be added to the system without changing prior functionality. There is also the added benefit of understanding what actually happened during the “conversation”.
Peter, What you are describing is a system where everything must be coded up in the system. Usually the system give you "flexibility" in the sense that you got dynamic forms / workflow, etc. But that isn't real flexibility. It doesn't actually handle things.
I've read a Swedish book about designing systems for usability and technological ergonomics. There are many examples, but one of the examples is of a customer in a bar trying to order a drink that's a mix of two beers, so he would only need half a bottle of each. The bartender wouldn't let him do it because the system would yell at him about the missing bottle, since you can't buy half a bottle. I imagine the workaround is buying two bottles and getting two drinks, but that's being focused on placating the system rather than the customer. On the other hand, it is an art form to design a system that lets you do stuff like this and still remains good enough at being a system.
I enjoy both the deeply technical articles here and the ones, like the prison series before, about how you might use a NoSQL system and its modeling approach to solve real world problems. I think the best thing you could do to market your product is to have a weblog that's just this second kind of articles. The NoSQL world is obsessed with technicalities, and there's way too little information about actual problem solving like this.
It reminds me of an WMS system, I have seen implemented. If the customer regrets his order, he has to wait for it to arrive and return it even if his order has not yet been shipped. Much cheaper than searching and unwrapping a pallet in several layers causing delays :-)
Comment preview