I got hired by a company about a year ago that doesn't normally do software development. They had contracted out to a firm to get some software written for them. Later, they hired me to help maintain it. What this software does is gather data locally at a rig site, stores it in a local SQL database, and periodically uploads the data to a remote database that is maintained by my company. This allows people who are not at the local rig site(say, the clients CEO) to use a remote version of the software to login, and see what is going on. Each rig site has a name associated with it: Rig 1, Rig 5, etc. The main problem is that the client can create a username/pw each time they run the software. This leads to many logins all associated with new rig sites created with the same names. There are numerous reasons why this happens, the least of which is that the software doesn't check to see if a username already exists. And quite frankly, my company and all the clients all appear to not care about any of this.

The most difficult part of it all is if something goes wrong, I don't hear about it for almost 4-6 hours later. And when I do hear about it, I get the very vague "It's not working". When I try to prod them for more information, no one is ever doing anything when it "broke", or no one remembers. This is frustrating to no end, and I get yelled at when I can't successfully fix the issue in a timely manner. I've informed my boss about this issue, and again, no one really seems to care.

So that brings about my question: How do I make them care? How do I get them to impose some semblance of standards that will not only make my life easier, but benefit them as well?


Standards I'd like implemented:

  • 1 username/pw per client (makes it easier for the client to see all the rigs they own in one place).
  • Faster response time to issues.
  • Detailed reports of what was going on when issues occurred. (Both these get the site up and running faster.)
  • What kind of standards are you talking about? Sounds like there is no incentive for anyone but yourself to impose them - if you can show how such standards would benefit the client and/or company (save money, time etc...), then someone might actually listen.
    – Oded
    Feb 20, 2013 at 21:32
  • 1
    Edited to show some things I'd like implemented. I've pointed out how beneficial they'd be to all involved, but it just falls on deaf ears.
    – PiousVenom
    Feb 20, 2013 at 21:40
  • 1
    Can't you just implement some of them as part of your day to day work?
    – Oded
    Feb 20, 2013 at 21:41
  • 2
    @TyrionLannister they obviously didn't have the manpower to write the app in the first place or they would have done it in house. There will never be a team that you will be a part of that will rewrite anything as long as it is cheaper to treat you like a code janitor than to make long term solutions. If you can't make the case and nobody will listen then you have to decide if being a janitor in the long term is in your long term career goals Feb 20, 2013 at 22:06
  • 2
    This sounds like a rant against your current employer.
    – enderland
    Feb 21, 2013 at 1:24

3 Answers 3


It's not obvious to me that you need to impose standards or make anyone care. Since you're maintaining the software, it sounds like you have the opportunity to propose some solutions to common pain points.

For example, have you suggested to your boss that you add code that checks to make sure that the same username doesn't get created multiple times (presumably in concert with a fix to make it possible/ easier to reset the password to an account if that's why new accounts are getting created)? If you can explain that you spend x hours per week trying to unravel problems that are caused by duplicate accounts or y% of the issues are related to this while fixing the problem will require z hours of effort, you should be able to put together a pretty reasonable case for prioritizing the fix.

Similarly, if people get upset when problems aren't solved quickly enough, have you suggested to your boss that you add additional logging/ monitoring to the software? If you can show that spending time up front to add logging would allow you to more quickly identify the root cause of an issue (or at least focus your efforts) rather than trying to get people to remember what was going on 6 hours ago, it would seem like a very cost effective investment for the company to make.

  • I have brought up these points. But every time I mention them, I get reminded "We'll be rewriting the software soon, so there's no point in changing the existing." And anytime I mention wanting to add these standards, I get told we'll implement them in the rewrite. This has been going on for a year now, and is really getting old.
    – PiousVenom
    Feb 20, 2013 at 21:39
  • 2
    @TyrionLannister - Then you have a prioritization problem. Presumably, there are issues with the software that you are addressing in your day to day work. That implies that someone is prioritizing those changes over the changes that you want. Does that prioritization make sense? That's where you have to make the case to your boss with numbers. How much value does the company derive from the changes that you are making now? How much value would it derive from the changes that you want? Feb 20, 2013 at 21:44

At the end of the day, you really can't impose any standards unless the target wants it. So if you really want to push for changes, you must be able to convince them that it is in their interest to do so.

It's hard to provide a specific answer since the question is pretty open ended. but try to at least consider this:

Know your target.

Who are you communicating with? The boss has a different priority (Security? Risk of company secrets being made available to competitors?) from the programmer (I've already got a work backlog 10 miles long) from the User (I just want it NOT to suck).

There are few things worse than pitching the right things to the wrong target or the wrong things to the right one.


I've had clients tell me they were going to do something, I told them it was not a good idea, and they did it anyway. When it bit them in the *, they told me I should have told them more emphatically. My personal philosophy is not to tell customers what to do. The customer is always right, and the customer is always responsible.

There are two things that make sense: document extensively and circulate such documentation to the 'offenders', particularly if you're being held responsible for problems. If someone acts carelessly, make sure they're aware that a better approach is possible.

The other is to identify, and if possible, quantify, risks. If you have a crazy name/password arrangement, you could remind people that various groups sponsored by foreign countries like to hack into American infrastructure. If anyone can create an account, 'outsiders' can nose around in your system.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .