Skip to content

Out on a LIMSThe Blog for People Who Risk Life and LIMS on a Daily Basis

Value-Added Dilemma

Volume IIEntry 59 of 113 in 20162 min read5 comments ↓

Written by Gloria Metrick on . Published as written. It may not reflect how these systems work today.

A couple days ago, I ran into a problem with some code I was writing. It was almost finished expect for one problem - just one last thing to tackle.

As I started planning how to fix the final problem, something occurred to me - it wasn't really a problem for anyone but me. No-one else would see it. I was planning to spend a lot of time and programming, costing the customer more money, to fix something that didn't affect anyone but just personally offended me and my sense of professionalism.

What to do?

As often happens to me, the answer usually comes when I'm far away from my desk and not focusing on the problem. The answer that came to me is that I shouldn't spend money to fix something that isn't adding value for the customer, that isn't affecting them, and that won't make any difference to their work or to the system's maintainability. I shouldn't fix things just because I find them offensive.

Sometimes, we get in the middle of these tasks and we make our lists of all the things wrong with the programs we're working on or even other tasks and it's hard to pick out the list items that shouldn't be there. In this case, I also passed this by the customer who also didn't feel I should necessarily be spending their money on this item and I believe I've made the right choice. Okay, well, but I still feel offended by the bit I left behind but willing to live with it.  ;-)

The bottom line is this: Sometimes, we have to step back from our own opinions and think hard how the customer wants their money to be spent. If I spent their money on something they don't want, they have less money left over for something they DO want. We insist it's for the customers' own good. Sometimes, that's actually true. Other times, it's our way of justifying doing something we just really, really want to do. We all need to be careful of these times.

Gloria Metrick
GeoMetrick Enterprises
http://www.GeoMetrick.com/

The conversation

5 comments from 3 people, June 16 to June 18, 2016. Gloria replied once.

  1. Greg Mendizabal

    I agree. While not a consultant, I am very bad at stepping back and looking at things objectively and hence drive my boss and PM crazy. "Perfect is the enemy of good enough" also applies here where a requirement can be met very simply but will be a little extra work for the user but you spend hours enhancing it to make it "perfect"--and the user just shrugs because as you note, they will never see all the work that went into that.

    1. Gloria MetrickAuthor

      The other sad thing is that the best programs, the ones that work most efficiently, that took the most work, that were built and tested to be the best - those are the ones the user will never notice. They won't realize the work that went into them because there's nothing about them to get the user's attention - because they just work.

      It's sad but it's the way it should be - that we need to make programs seamless and less noticeable so that they become part of the user's routine in the most natural way.

  2. Phil Wolfe

    Voice of the Customer is always a good touchstone. For us the horns of the dilemma sharpen when the "want-to-do" is repayment of technical debt that will ultimately save the customer time/money, but typically in a longer time horizon than their current budget or project. We try to quantify the payback and risk and let them make the call, but as a "hidden" benefit the answer is usually "we'll get around to that later." Result = increased technical debt.

  3. John H. Jones

    Phil makes very good points about Technical Debt. For those not familiar with the concept it is truly a real thing: https://en.wikipedia.org/wiki/Technical_debt

    Too much technical debt eventually renders the application insolvent or bankrupt and thus time for replacement.

  4. Phil Wolfe

    Thanks, John. The analogy works well because unfortunately most people understand debt intimately from painful personal experience. Included is the concept that you'll have to pay eventually, and more than the original cost (interest).
    I've learned that there's also "business debt" that works similarly, and can prevent payment on technical debt due to lack of resouces, insight, leadership, etc.

Comments are closed. This conversation is from 2016. Ask us to remove a comment

Working on the same problem in your lab?

Talk to a laboratory informatics scientist