> > "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] > <javascript:>> 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.
