11

I recently started work at new office that uses a proprietary program written by a solo developer. He's occasionally around as part-time tech support, but the company has signed off on this software and he's no longer being paid to develop it.

As a user of his software there are many issues that leap out to me as a source of concern:

  • very simple to directly view the DB as a low-privilege user
  • passwords stored as plaintext
  • dictionary admin passwords
  • app uses the DB root account
  • DB doesn't meet 1NF (eg. appointment1, appointment2, etc.)

I feel like these are serious issues and that if I were him I'd want them pointed out to me, but I'm not a qualified programmer (I'm a social worker) and I don't know if it would be rude of me to just buttonhole him and start blabbering about salted hashes and normal forms, especially when this is no longer a paid task of his.

Is it out of line? If not, how would you broach it?

Edit - more info prompted by comments:

  • The application holds sensitive data.
  • It's for internal use, but it's running on lots of machines in several cities and many visitors come through our offices.
  • My concerns are for the developer's future projects as well as this specific one.
gnat
  • 21,442
  • 29
  • 112
  • 288
Ian Mackinnon
  • 401
  • 2
  • 7
  • It sounds like a collection of security holes, not just poor programming. How sensitive is the data? I'd be tempted to raise this with the company you work for and let them decide an appropriate course of action. As for whether you should raise this kind of thing with a developer in future you might want to pick one or two. Also, have you ever considered a career as a tester? ;) – dannywartnaby Oct 07 '10 at 15:45
  • @dannywartnaby, yeah the data is pretty sensitive. A non-finger-pointing word with management seems like a good idea, though we're a charity so proper solutions are often financially precluded. Also, social work is basically unit testing for wetware :) – Ian Mackinnon Oct 07 '10 at 16:02
  • You have yet to describe the purpose of this app? Sounds to me like an internal application that is protected by a LAN firewall so it is not as much of a concern in regards to the things you mentioned. Plus if its not broken why fix it upper level will say as they might not understand the implications of the problems in the app. – Chris Oct 07 '10 at 18:26
  • @Chris, I'll add some more detail in an edit... – Ian Mackinnon Oct 07 '10 at 18:31
  • After working in the industry for a bit, I would say you're describing many 'professionally' developed systems. It's likely that criticism will risk your reputation, especially if they have a good working relationship with the original developer. This is always a risk. I find that people don't generally receive this sort of criticism well. Unless you can clearly explain what's wrong to your bosses, be careful. Perhaps select one item to address at a time and think hard before you bring it to them, think of what they want to hear, what they'll say to you, etc. – Sprague Jun 18 '13 at 07:36

9 Answers9

14

If you are not in a position to change the code yourself then you should decide which issue is the most important one and approach him about it. Rather than couching it as "criticism" do it under the guise of "feedback".

When I say feedback I mean a VERY distinct process of stating the behavior and the effect of it, along the lines of "When you X, here's what happens..." and speak STRICTLY of things are directly observable. Do not attack him, his professionalism, etc. Stick to the facts.

For a great overview on providing peer feedback listen to this postcast: http://www.manager-tools.com/2006/10/the-peer-feedback-model

If you have success with the first item, move onto the next most important one.

Good luck!

Todd Williamson
  • 2,358
  • 15
  • 19
6

As a social worker, would you appreciate it if this programmer were to come to you to advise you on how he thought you had mishandled an important case you once worked on, but were no longer assigned to?

I'd say that he would be on very shaky ground for approaching you; the reverse is also true.

Under the circumstances, I'd say that if you have concerns for the security state of the application in question (and given what you've written here, you should have such concerns), that would be best served by bringing your concerns up to those who have some power to effect corrections. Trying to educate the former developer is not your bailiwick, and is more likely to be seen as interference than anything else.

Cyberherbalist
  • 1,841
  • 2
  • 17
  • 26
  • 2
    I hope I would always appreciate feedback about my work from anybody that took the time to offer me advice, regardless of their profession, and that I can continue to learn from others throughout my career. But I admit there are lots of other factors like context, delivery and organisational structure that will affect how advice is received, so I think you're probably right to advise caution :) – Ian Mackinnon Oct 07 '10 at 22:15
4

As he's no longer being paid to work on it, probably not. There are two possibilities:

  • He knows it's crap and hasn't fixed it.
  • He thinks it's good so he hasn't fixed it.

In either case, telling him it has serious flaws isn't going to improve it, since it's no longer being developed.

Fishtoaster
  • 25,909
  • 15
  • 111
  • 154
  • 1
    I agree that this program is probably not going to get fixed, but I'm mostly thinking about helping him avoid these practices in future projects (that I may end up using!). – Ian Mackinnon Oct 07 '10 at 15:36
  • Most likely your company got what they paid for. Nothing more and nothing less. You help him by convincing your company to pay for more hours of his work. – gnasher729 Jun 06 '15 at 21:29
4

I don't think there's a lot of point discussing this with the programmer. For a start, he might not take kindly to being told how to do his job by an "amateur".

However, you might point out any serious security issues to your management. Let them decide what to do about it. In some cases, it sounds like the fixes would be simple changes to database account permissions that can be implemented in a few minutes.

But you (and management) also need to consider whether the security of this application really matters. Does it contain valuable or sensitive information? Are you likely to have problems with disgruntled employees? Is the network properly secured?

Stephen C
  • 25,180
  • 6
  • 64
  • 87
4

  • Do you know the story behind the program? Perhaps it was written in a very short time frame where the developer made these decisions rather quickly as the software had to be done as quickly as possible without a bunch of investigating being done into it.

  • Does the support include patches on the code? This may work for some minor things that the code has that you see as major issues. The other thought is how hard would it be to replace this software.

There are cases where a peer helping out a peer with unsolicited constructive criticism can work but this is a bit different to my mind. I'd say be sensitive about how you communicate the issues and try to keep it professional.

JB King
  • 16,795
  • 1
  • 40
  • 76
3

First of all, as an end-user, you are one of the most important stakeholders in this software development project. Your views are totally valid, and they deserve to be heard by management!

Secondly, you do seem to know what you're talking about (you know when a DB isn't properly normalized), regardless of your job title or academic credentials.

Thirdly, you obviously feel very strongly about this matter.

So you should voice your concerns to management. Just make sure that you state your case articulately and in a highly respectful manner.

A. N. Other
  • 1,539
  • 8
  • 14
2

Don't bring it up to him. Bring it up to your bosses.

--- edit ---

Oh, and do so in writing, in an e-mail (with receipt acknowledgment on if your mail server supports it.) Keep the e-mail and all subsequent acknowledgments and receipts (print them and scan them on pdf... and keep both the pdfs and print outs.)

Because blowing the lid on the issues you just mentioned could backfire you. After all, they were written under your bosses' noses, so they are partially responsible for it (or someone up the food chain.)

That means that there is the distinctive possibility that your professional and ethical efforts to raise severe issues might not be welcomed by someone above you. So keep record of all conversations related to this issue.

For, if things hit the fan because of the security concerns, you have a record that you did your part. And by documenting everything (including the security issues), you can cover your ass when the spin doctors come into place.

luis.espinal
  • 2,560
  • 1
  • 20
  • 17
2

What is your intent in telling the programmer that his code needs improvement?

Are you trying to get him to be a better programmer? Then yes, you're out of line, it's not your place to tell him that his programming skills are subpar.

If your goal is to raise security concerns about the code, then yes, that can be appropriate, but not with the programmer. Talk to whoever is in charge of the application and ask if they're interested in some concerns you have. Do not just go and say "Hey, you know that app that maintains the records about foo? It sucks, and here's why." Describe the problem separate from the issues of how it got to be that way, and who did it.

Consider if you noticed that the overhead door to the warehouse was secured at night with a piece of twine. You wouldn't say "Your security sucks, and whoever set it up is an idiot, and if you don't fix it now, you're screwed." Even if you knew all the backstory about how it got to be that way, you'd leave all that out.

Instead, you'd say "I saw something that I thought I should point out. I saw that the warehouse door is closed with twine, and I'm afraid that wouldn't be strong enough to keep out a determined burglar." It's entirely focused on the problem you see, and doesn't get into the drama of how it got to be that way.

And if you say "Hey, I've got security concerns" and they say "Yeah, it's OK, it's internal, it's no big deal," then let it drop. You've done your job.

Andy Lester
  • 4,810
  • 2
  • 16
  • 23
  • I think he is more than fully justified to try and make the bad programmer a better programmer out of pure good will. Who says there have to be any animosity in improving the world one small step at a time? Perhaps my opinion is cultural, on the other hand, being a Swede. – Henrik Feb 12 '11 at 20:48
  • People are not computers, and people usually react poorly to unsolicited opinions telling them that they are substandard. That's why there will be animosity. It's not a matter of being "justified", it's a matter of what works and what doesn't. – Andy Lester Feb 13 '11 at 04:18
1

My experience is developers rarely take criticism well (who does?). Thats why there are so many heated religious arguments about anything to do with programming (best language, platform, framework). So I would just bring it up in casual conversation as you mention you have been looking at the system.

Craig
  • 4,302
  • 3
  • 21
  • 21
  • Competent developers produce code that is worth what was paid for it. Some companies are cheap, pay little, and as a result get code that is worth little. In that situation, there will be no argument. Just a reply "if you convince your boss to pay me to fix it, I'll fix it". – gnasher729 Jun 06 '15 at 21:33