Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: A question about ethics in Computer Science
1 point by MattyRad on Jan 31, 2014 | hide | past | favorite | 4 comments
I work for a university, programming software for a certain discipline. I inherited the software only in the last month, and it would be generous to call it poorly programmed. I am confident that I can improve it however, given several months.

Nevertheless, some faculty and I went to a nearby company with the intent of selling the software. The demo went fine, and indeed, it has the ability to perform as advertised, but not without many bugs and crashes (demo was fine because we knew what not to do). The company was mildly impressed and is considering splicing/replacing their software with ours.

It is my personal belief, at this point in time, that doing so would be a bad idea for their company, with them potentially sinking a lot of money into a risky action. (If you think any weight should be given to how successful the company is: they are a small, financially stable consulting firm that sells software on the side, that is all I know.)

While we by no means have lied about the integrity of the software, I feel like we've hidden important details. The company has a third party programming their own software, so it's not like they asked us the important software related questions.

Should I personally email the company (behind my employer's back) and tell them the truth: that's it's janky software? Or should I just leave the software sales to the appropriate faculty member, it's their problem? Should I care more about the company's position because it actually affects people with jobs instead of tenured faculty? It brings up many questions and this is the first time I have had to deal with ethics in CS.




My position would be to fix the bugs as swiftly as you're able to deliver a product you're proud of, even if the core of it was not yours.

Rather than totally sabotage the situation, suggest testing. Bugs found in testing allow the company to make informed choices while you and your CS department have an opportunity save the relationship by fixing the issues in development level software. (After all, we are all humans and bugs happen, even if the best of code.)

There is a world of difference between development software and production ready software. Demo software is rarely the finished product. Now, if it was presented as 100% complete, tested and ready for production... that is a different story.


Are you willing to lose your job for the sake of white-knighting some crappy code?


All software is janky.

At my first internship i saw all these problems with their code base. Documentation was nonexistent at best, or lagging way behind the code at worst. Tons of hacks and larger structural issues. "No way these guys will last more than a few years, I thought."

That was 2006. They're still alive now.

It sucks to realize in some ways, but the code most companies produce and use is crap. Don't worry about it; if it works and has the features they want, they know there'll be bugs.


Buyer beware.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: