Just wanted to say, thanks for posting this Kasey. It's great to hear the nasty details, though I'm sure it's not so great to live with them day to day :) It's a great point about implicit behavior pushing off programming from the system onto the users. Thanks also for the links.
I have been moving away from "data-encoded behavior" styles in my work too, especially for applications that have quite structured state transitions. A key thing I have realized is that for many applications a 'form submit' does not represent creating or updating an entity directly -- it represents an intent to transition state in a particular domain-specific way, depending on current state. In this way it is very similar to the `Msg -> Model -> Model` update within the Elm app, but extended to the backend. On Monday, October 31, 2016 at 8:25:14 PM UTC-4, Kasey Speakman wrote: > > "Explicit is better than implicit." > > -- Tim Peters > > > So the main way "data-centric" happens is by modeling behaviors implicitly > in the data. A common example is an item being active or not. I often model > this as a boolean property "isActive". The usual way to tweak this value is > to have the user edit the item and toggle that box. So, the problem lurking > here is that deactivation may, in fact, be a process. If you have to check > on save `*if oldValues.isActive <> newValues.isActive then // do extra > de-/re-activation steps*`, that is an indication that you have implicit > behavior hiding in data. That should be changed to be an explicit action > the user can perform (e.g. a button in the UI) and have its own use case > (uri or method call) on the system API. (Imagine this: to cancel your > Amazon order, you have to edit the order and check the IsCanceled box.) > > So here's a concrete example of how we did it wrong in our legacy system. > To close a trainee's registration as "No Show", an employee has to create > an exam against that registration and grade it as 1%. This is an implicit > concept which our employees and our software understand as "No Show". > Instead of making it explicit by programming in a No Show > button/action/status, we have to *program the employees* (current and > future) to recognize this situation. > > And this is just one example of probably dozens in our system. Because of > that, it takes 6 months or more to get someone fully trained to use it > properly. And even then it's hard for people to keep dozens of cases in > their head at once, so minor mistakes/inconsistencies can happen easily. > > It's also hard to add features and fix bugs in such a system. Not only > because there's a lot of potential dev time spent on support, but also > because we programmers can't keep all these implicit behaviors straight > either. (We often don't know them as well as our users do, because we don't > work with them every day.) So deployments always carry at least a moderate > level of risk even when we believe the changes are minor. > > Going forward, we refactor these implicit behaviors to be explicit > actions/API calls as we have feature/bug requests against them. It takes > more time, but improves quality in the long run. So we are pushing it in > the right direction, and users generally still manage to make good use of > it in the mean time. > > I should also note that for non-functional reasons, it may not be possible > to make behaviors explicit. I worked on another project where I was not > given leave to do this. I figure it was deemed prohibitively expensive, > because I would need too much time with subject matter experts. Such is > life. > > On Monday, October 31, 2016 at 10:36:24 AM UTC-5, Peter Damoc wrote: >> >> On Mon, Oct 31, 2016 at 5:24 PM, Kasey Speakman <[email protected]> >> wrote: >> >>> There is a danger in focusing on data over use cases. It's not a >>> guarantee that you make this mistake (I have), but you know you've gone too >>> far with it when most workflows are Load/Edit/Save (or Create/Save). And >>> the user is left to know what field to change to have a specific effect in >>> the system. I've seen this termed as data-centric. Seems okay at first but >>> after a few years in production this leads to long user training times, >>> brittle workflows, and high support loads. >>> >> >> What are the alternatives? How would an approach focused on use cases >> look like? >> >> >> -- >> There is NO FATE, we are the creators. >> blog: http://damoc.ro/ >> > -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
