+972 52-548-6969
Code that? It is cheaper to get a human
Rafal had a great comment on my previous post:
Much easier with humans in the process - just tell them to communicate and they will figure out how to do it. Otherwise they wouldn't be in the shoe selling business. Might be shocking for the tech folk, but just imagine how many pairs of shoes they would have to sell to pay for a decent IT system with all the features you consider necessary. Of course at some point the cost of not paying for that system will get higher than that…
This relates to have a chain of shoe stores that need to sync data and operations among the different stores.
Indeed, putting a human in the loop can in many cases be a great thing. A good example of that can be in order processing. If I can write just the happy path, I can be done very quickly. Anything not in the happy path? Let a human deal with that. That cut down costs by so much, and it allow you to make intelligent decisions on the spot, with full knowledge of the specific case. It is also quite efficient, since most orders fall into the happy path. It also means that I can come back in a few months and figure out what the most common reasons to fall off the happy path are and add them to the software, reducing the amount of work I shell to humans significantly.
I wish that more systems were built like that.
It is also quite easy to understand why they aren’t built with this approach. Humans are expensive. Let’s assume that we can pay a minimum wage, in the states, that would translate to about 20,000 USD. Note that I’m talking about the actual cost of employment, this calculation includes the salary, taxes, insurance, facilities, etc. If I need this to be a 24/7, I have to at least triple it (without accounting for vacation, sick leave, etc).
At the same time, x1e.16xlarge machine on AWS with 64 cores and 2 TB of memory will set me back by 40,000 a year. And it will likely be able to process transactions much faster than the two minimum wage employees that the same amount of money will get me.
Consider the case of a shoe store and misdirected check scenario, we need to ensure that the people actually receiving the check understand that this is meant for the wrong store and take some form of action. That means that we can just take Random Joe Teenager off the street. So another aspect to consider is the training costs. That usually means getting higher quality people and training them on your policies. All of which take quite a bit of time and effort. Especially if you want to have consistent behavior across the board.
Such a system, taken to extreme, result in rigid policy without a lot of place for independent action on the part of the people doing the work. I wish I could say that taking it to extreme was rare, but all you have to do is visit the nearest government office or bank or the post office to see common examples of people working working within very narrow set of parameters. The metric for that, by the way, is the number of times that you hear: “There is nothing I can do, these are the rules” per hour.
In such a system, it is much cheaper to have a rigid and inflexible system running on a computer. Even with the cost of actually building the system itself.
Comments
Hi, nice that you find it worth discussing. I would say there's one more aspect worth mentioning - the cost of getting the system design right from the scratch. For sure you should get the happy path right, but if you try to understand all these accompanying variants, deviations, exceptions and special cases you either will spend a lot of time just gathering the information and processing it, or spend hours implementing extra functions that won't work for the customer and will have to be re-implemented. And for sure some functions will have to be reimplemented anyway, no matter how hard you try to get the requirements right (i'd even say that if a function is not re-implemented three times it's probably unused). So the reasonable approach for this would be - handle the most important feature first and be flexible so users can work around the missing parts. Then when you gain some understanding, try to handle some more functions.
Rafal, Absolutely. The key here is that you don't have to tackle everything on day one. In fact, limiting the scope to 50% of the work, just the happy path, dramatically reduce the complexity of the system. It also put in, from the get go, the ability to say "I don't know how to handle this". That is important, because the second stage is to deploy the system and see what is the next thing that s 50% of the work. Eventually you get close enough that only the very rare cases, which would take forever to spec properly are handled by humans.
You have a system that works, and an upgrade path if needed.
Oren, The other thing I find important is "dwell time", i.e. letting the users get used to the system, you then get the "Ah ha!" moments when "Oh, so you can handle X, it would be really useful if you can do Y"
Most people don't think like programmers, so it can be difficult to get them to specify things without a working example of what you can do already - which is the premise of agile development if taken from the business side of the fence.
It also leads to more sensible business discussions "Well we can automate case Z which happens twice a year, but it will cost $XXX to do so"
I like this discussion.
Getting everything correct up front is incredibly difficult. Paul Hatcher nails it when he describes the user discussions. Often users need to see the system being able to do X and Y, and then naturally lead themselves to Z.
Writing semi off-the-shelf software (niche market) I benefited from the cumulative effect of this over the last two days. I visited a customer who were on an older platform of ours. Showing them the new platform - how they do all the existing things but on the nicer screens (web-based rather than old win32 app), they thought things looked nicer but weren't particularly excited.
However I've had the web system in at other customers for the past couple of years and we've been rounding off all those little paper cuts and "oh, but what if it could?" kinds of questions that the old win32 system had. So I had actually excited users for a line of business app when they asked about those paper cuts being solved and, lo and behold, they were already present :) I just left them until after showing the "here's where we moved your cheese" bits on purpose since opening with them would've been too hard a departure from what they were used to.
I know the paper cuts that exist at the moment, but don't always know the best way to solve. Rapid iteration and tight feedback is what helps with this. At the same time, you need to avoid sprawling code and causing grief for yourself downstream. Nothing's ever easy :)
Comment preview