On Tuesday, November 1, 2016 at 3:31:07 AM UTC-5, Peter Damoc wrote: > > On Tue, Nov 1, 2016 at 2:25 AM, Kasey Speakman <[email protected] > <javascript:>> wrote: >> >> 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. >> > > Wow... this is so silly that it almost looks like a joke. Unfortunately, > I've seen enough to know that it happens. >
After thinking on this, I can tell you exactly how it happens. The program was made on a contract basis, so either the contractor didn't discover the No Show use case, or it was not in the business processes at the time it was implemented. Later, a user in charge decides they themselves can implement a No Show feature without going through contracting by making policy around the data. "If you see a grade of 1, that means it was a No Show." The user probably congratulates themselves for saving money. This kind of thinking leads to more of this. And that's where we are. Sometimes this kind of shortcut might be the only way to get things done under time/budge pressure, from the user's perspective. -- 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.
