Software Quality In a Non-Software Company? 308
Nicros writes "I work for a publicly traded biotech company that happens to write software that is, in fact, kind of critical for the business — without it no data would ever be read from our instruments, and no analyses would be performed on that data. The problem is that as a 'biotech' company, we are not taking software quality seriously. We have no senior management with any history of commercial software development — our C level has really no clue whatsoever what software really is, much less what is going on in software development. All of our quality processes are related to manufacturing our system (not software), so we are constantly forced into ad-hoc development since there is no real process for our development. Repeated requests to hire someone with some real commercial software development experience have gone unanswered. I have been to the CEO directly one-on-one and although he agreed this was an issue, thanked me, and said he would look into it, that was the end of it. He has bigger things to worry about. So the question: Is this just a fact of life and I need to deal the best I can? What else can I do to get some attention on software quality in the company?"
Practice What You Preach (Score:5, Insightful)
You need to argue this case as much as possible. If you're the developer, or in charge of development, enforce decent developmental practices and ensure your estimates include them. Err on the side of caution. Take an estimate and double it. Managers talk money, not standards, so you'll have to hit them where it hurts.
Otherwise, is there anything off-the-shelf that could alleviate some development?
Re:Practice What You Preach (Score:4, Informative)
A version control system is critical to have, and to document what your processes are when developing software is the second part of the process.
Impose a coding standard where some outlines for coding style is provided, but more for the sake of how to maintain the code quality. Compiler warnings shall be at an absolute minimum, utilization of compiler safeguards shall be used whenever possible. Enforcing "Option Explicit" in VB for example.
For version control - go for a simple solution like CVS or SVN. SourceSafe isn't really safe... It has a tendency to drop files if the area where you check in files on suffers from a full disk.
But there is no support at all from management when it comes to safe software development it may be time to drop the issue and say that "we need to buy some software here" and hire a consultant company for that. Then it starts to get expensive and wrong unless you get the right people...
Last option is to leave ship and leave the sources in an unstructured order without any useful documentation. Then wait and see if someone comes back asking you politely for help. If you aren't alone bring your coworkers with you too. There are always companies looking for people with skills.
Re: (Score:2)
I'd not adopt CVS these days, or SVN.
I'd advocate Bazaar ; it's faster than SVN and supports more workflows, and it's branch/merge support is a full generation beyond SVN. Feature and bugfix branches are a "good practice" that is far more costly to use when your tooling doesn't support it adequately.
If your language has one, get a *Unit testing framework and start to write tests for it. When you encounter a bug, write a test that exposes it before you fix it. When you need a new feature, write the tests for
Re: (Score:3, Insightful)
I'd not adopt CVS these days, or SVN.
I'd advocate Bazaar
First of all: I agree with you. I use Bazaar for my own personal projects.
But I think it's important to remember that any version control is better than none. Here's what I'd suggest as an order of importance:
Get onto version control, if you're not. If the VCS you choose sucks, you can change later, but anything's better than simple shared network storage -- or worse, emailing files (or patches) back and forth.
Next, make sure it's open source, if you can. Your source code and version history are probably yo
VCS + TDD + CI = Profit (Score:3, Insightful)
Good advice. Mod parent up. From a technology perspective, a Version Control System, Test Driven Development, and Continuous Integration can go a long way towards improving quality. If the OP is in a MSFT shop, then you are most probably stuck with VSS or TFS. VSS is file based so it is not very good for distributed development. You will need to enhance VSS with SoS [sourcegear.com] if you have remote developers. TFS doesn't have that problem and also has support for TDD's unit testing. If the OP is willing to use OSS, the
Re:Practice What You Preach (Score:5, Informative)
I also work for a biotech but we're lucky enough to have a CEO who's a computer scientist so he knew the importance of IT. As such we have a rather larger IT dept which includes a software development team.
In order to show the bossesses that proper software maintenance/creation/validation procedures are important just explain what would the FDA or some other regulatory agency do to your collective bung holes if they were to probe deeper into your practices.
Mission critical data being handled by non-validated/non-documented software is just like having untrained people working with samples in the lab, it's a big no-no.
You need paperwork that supports your claim, start with all the areas where un-validated software is used, then add to that a second section explaining the cost of poorly planned development iterations. We work using monthly iterations and when we told the people responsible for the software in the field that an iteration cost about 30 000$ just in labor costs they started paying attention and making the lists of demands count, i.e. removing the superflueous demands (ex: "it would look nicer in blue" was replaced with "The standard deviation calculation should be done with X+1, not just X.")
Get a test audit (Score:3, Insightful)
I write software for clinical researchers. From the summary description, sounds like the company has software that is part of their clinical quality system which is not being tested/validated. If the description is correct and the software is actually part of the clinical therapy they're selling, they should have an external auditing agency take a look at it before the FDA does.
The first time one of their products is audited by the FDA, the warning letter they receive will communicate to management exactly
Re:Practice What You Preach (Score:5, Funny)
In order to show the bossesses
Yes, precious, we'll show those nassssty bossesses, yes, we'll shows them!
Re:Practice What You Preach (Score:5, Insightful)
I also work for a biotech (... this my other brother Darrell), and we're facing the prospect of FDA regulation as a device. So we're presently working our way through ramping up a formal (21CFR820) Quality System now. My boss happens to have been through this before and to be a pretty effective evangelist for the FDA's Quality System methodology [fda.gov], which is required for all medical devices and drugs. As he says, a Quality System is just putting to paper all the things you should be doing anyway. So one place you may want to start is by discussing the utility of complying with FDA regs with regard to software.
My boss also notes (on any occasion where there's an opening) that when the FDA introduced design controls, most companies complained they were going bankrupt (as companies are wont to do when regulation, merited or unmerited, is proposed). But when the FDA went around doing their roadshow to show that they weren't just making rules without listening to industry, people from the device companies gradually started to get up and explain how using a Quality System actually lowered their costs and decreased their time to market for revisions and product upgrades.
So as an evangelization tactic I'd look on the FDA's site for guidances relating to the introduction of the Quality System Regulation. For example, this guidance [fda.gov] on general principles of software validation is pretty good. If you mentally translate into software industry language you can really see that they're trying to get you to do better engineering by thinking and documenting early, really getting straight what the software is trying to do, and being structured about showing that it does what it needs to do. The truth is that despite the startup effort of introducing documentation and procedures, controlled engineering methodologies work way better - they reduce requirements failure, increase code quality (and more importantly, design quality), and - though developers start out hating paperwork - even make the developers happier because more code works and sees real use. If the company plans to be in the software business for the foreseeable future, it's almost certain that the effort invested in good software practices will pay huge dividends down the road. The key is point out that quality is not an esoteric consideration, it's a driving cost and business risk consideration. Sooner or later the cost of low quality software shows itself.
One thing I will note is that the QSR is pretty waterfall oriented, both because it predates the formalization of iterative/agile methodologies, and because it's written for engineering of physical boxes that have to be released to manufacturing (which implies a fair bit of waterfallism). Part of our effort is to practice iterative development methodology while documenting to the FDA's standards.
Anyway, take a look at all that.
Re: (Score:3, Informative)
In most companies where software is not the main focus, the deadlines are for the main product and the software had better be done by that deadline. The software guys have nothing to say about the schedule.
software must be ready when product ships (Score:4, Interesting)
In most companies where software is not the main focus, the deadlines are for the main product and the software had better be done by that deadline. The software guys have nothing to say about the schedule.
I saw this effect first-hand at Digital Equipment Corporation. Although we did a lot of software, the corporate culture focused on hardware, so the software had to be ready when the hardware shipped. Fortunately, the software guys were generally able to get a prototype far enough in advance of "first customer ship" that it was possible to get the drivers written. From a software point of view the hardware documentation was sometimes lacking: once I recruited the assistance of an in-house field service guy to help me read the engineering drawings so I could figure out how to program a new device.
Re:Practice What You Preach (Score:5, Insightful)
Between being right and being popular with bosses being popular wins out every time. Pestering them about better ways to do things is not a great idea. Play golf with them and never mention a darned thing relating to work and if something does crop up then make them think it was all their idea all along. Money shall flow to you as well as job stability. Make sense and be logical and you might as well start a job search.
Thia may not apply in other nations but in America it works every time.
Re: (Score:3, Insightful)
Re:Practice What You Preach (Score:5, Interesting)
Rarely does the statement "You've got a problem and you need to solve it" ever get a good response.
If you say "We have a problem, this is how other people solve it, and this is what I will need to solve it. Give me the budget and I'll solve the problem." then you are vastly more likely to get what you want. Then you'll have to deliver, but if you are like me (not that I am the best way to be), you'll find the responsibility gratifying and the deadline invigorating.
Re:Practice What You Preach (Score:5, Insightful)
"We have a problem, this is how other people solve it, and this is what I will need to solve it. This is what it costs us _not_ to solve it. Give me the budget and I'll solve the problem."
If you can show that the software development 'process' currently in place is costing the company $N a month and you will need to spend $X to improve the process, if you're going to be developing software for more than (X/N) months, it'll be more cost-effective to fix the process.
Re: (Score:3, Insightful)
If you can show that the software development 'process' currently in place is costing the company $N a month and you will need to spend $X to improve the process, if you're going to be developing software for more than (X/N) months, it'll be more cost-effective to fix the process.
Right. The best way to deal with a CEO is to make up numbers, so he can feel like his job is "quantitative".
Re: (Score:3, Informative)
If you say "We have a problem, this is how other people solve it, and this is what I will need to solve it. Give me the budget and I'll solve the problem."
That approach is nicely encapsulated by the motto "Do not fix problems, pursue opportunities," which (I think) is attributed to W. Edwards Deming. The parent post offers excellent advice.
Garbage in, Gospel Out? (Score:5, Insightful)
Unfortunately, software quality isn't even on most companies' radar. Until it exposes them to major losses like a balsa-wood skyscraper built next to the airport on the shores of the Petrol Sea.
Software has the disadvantage of being intangible and we all know that "Any kid can write software".
Any kid can bandage a cut, but that doesn't mean you want that kid doing a colonoscopy on you.
At some point the software industry is going to need to establish itself as a rigorous practice with rigorous standards. Not some silly cert that says you know Language-of-the-Week, but something along the lines of GAAP for accountants. I'm not holding my breath, though.
IF you happen to have - or be able to cultivate - the right social skills, take an active role. However, despite what the "don't like it, get-entreprenurial" crowd asserts, there are those of us who'll never be able to tolerate forcing their introverted personalities to assume an extroverted task on a long-term basis even with the best of counseling, self-help and medications. It can be wearying and it steals time energy from what we can do that the extroverts can't.
So if you aren't socially adept and don't see yourself swimming through office politics like Nemo, the best advice I can give is keep your resume up to date and network to whatever degree your social skills allow so you can bail before the tower collapses.
Then again, you can be Monty Hall and still come out of the losing side in the office, so keep the resume up to date anyway.
Anarchy is an opportunity (Score:5, Insightful)
It sounds like in your company there is no one doing this job. You've talked to the CEO. Get him to make you VP of software and tell him you'll solve the problem if he gives you responsibility.
Anarchy is an opportunity for the ambitious and unprincipled. Take it and make yourself software Czar.
Re:Anarchy is an opportunity (Score:5, Insightful)
Agreed. Don't raise issues for other people to solve, you are just labeling yourself a trouble maker. Raise issues, attach costs to them, and then present yourself as the person with solutions, and ask for budget to solve them. Make a proposal with figures, planning, clear savings, and get approval. Then hire and build a competent team and/or find a good subcontractor. Use open source where possible to save costs. Report your progress and ensure you get budget every year.
Think of ways to turn a profit from the software. Maybe it can be licensed to other firms? If you can earn revenue you will suddenly become much more valuable.
Problem is: you will stop coding and become a manager. But if you do a good job, you can get power in the firm.
If you present a good plan that will solve real problems for the company, and you are not given the green light, then look for another job. If/when things go bad, they won't thank you for it.
Comment removed (Score:4, Insightful)
Re:Anarchy is an opportunity (Score:5, Informative)
Re: (Score:2)
Re: (Score:2)
Re:Anarchy is an opportunity (Score:5, Insightful)
Careful what you wish for though....
The flip side of becoming a point of authority in an environment as this is that if/when code defects bubble to the surface on your watch that result in a major hit to the company's bottom line, you may need to have a thick layer of asbestos underwear on in order to prevent the blame game from claiming you as a victim.
Right now, you've identified the problem for your mgmt and have suggested solutions, but you're not yet responsible for the implementation of those solutions. Becoming the VP of such an org not only makes you responsible for the fixes, but also directly accountable, possibly including from a legal standpoint. In other words, you'd better hope that the bugs in your software don't have the potential to cause medical or financial harm to your customers.
Re:Anarchy is an opportunity (Score:5, Insightful)
If you want to keep yourself safe, document and report all 'blind spots' in your method.
Make sure you present an overview of what you can control and what you cannot control.
If management does not agree with a certain blind spot, show them the resources required to cover that blind spot.
You cannot have bug-free code without strict rules and a literally astronomical budget. (and even NASA has had a few bugs)
What you can do is prevent embarassing/dangerous bug from making it into 'production software'.
Re:Anarchy is an opportunity (Score:4, Interesting)
Excellent point, if you present yourself as the man with the solutions, and especially if they promote you as such, you're going to be taking the heat when things do not go perfectly.
The thing about rigid development and testing processes is that they delay releases. You can do featureful but buggy from-the-hip releases rapidly, or you can do rock solid heavily tested releases very slowly.
It's the old speed, quality, cost diumverate. Sounds like today they're choosing speed and cost, and quality is there only because your product isn't yet so mature that regression bugs aren't common.
Companies starting a development methodology need time to adjust to the reduced agility that these require. It's best to work your way into it.
Start with introducing source control and some formal testing, along with build releases. It's not very likely that they're going to reject you on these things as their benefits are fairly clear and they shouldn't have that much impact on your bottom line. Create a branch per release, and suggest that the software not be released to manufacturing until that release passes formal testing.
Later you can introduce things like regression testing and a proper software development lifecycle.
You have to be careful how you present it. Make sure they're aware that you're easing the company into a larger methodology, and until fully implemented there's still going to be gaps for bugs to fit through. Explain that during this process you'll be performing gap analysis on each bug that does appear, identifying how it got through testing, and adjusting the process as necessary to ensure that such a thing is less likely in the future.
You don't want to present it as a silver bullet out the gate, you want to be sure to explain that it's iterative and the objective isn't immediate perfection but continual quality increase. Even if you have 30 years of software development lifecycle managerial experience, you can't convert a company to a full-blown lifecycle overnight, and depending on how a company works and what its needs are, lifecycles will in fact differ a bit from company to company. Even if a perfect lifecycle existed, you still need to give people time to get accustomed to it, so you can't just throw the switch over night or everything comes to a halt.
Re: (Score:2)
It's a bastardized word intended to invoke the meaning of a triumvirate while indicating that you only get to choose two.
I may have spelled it poorly, but I'm by no means the only person to try this word [google.com].
Thanks for skipping all the meat of the post and instead nitpicking a word you didn't grok though; that was a meaningful contribution.
Re: (Score:2, Insightful)
Careful what you wish for though....
The flip side of becoming a point of authority in an environment as this is that if/when code defects bubble to the surface on your watch that result in a major hit to the company's bottom line, you may need to have a thick layer of asbestos underwear on in order to prevent the blame game from claiming you as a victim.
I am not familiar with your capitalist system.
I was thinking of Stalin, a great Russian leader. Stalin saw several problems in Russia and approached Lenin (like a CEO). Stalin amassed political power while Lenin was alive and then replaced him once he died.
If people start to blame you, I would recommend (based on Stalin's methods) that you conduct a witch hunt for saboteurs and spies. Also make sure everyone is too busy imposing the new working methods to stir up much trouble.
Additionally make sure the CEO
Re: (Score:2, Interesting)
It sounds like in your company there is no one doing this job. You've talked to the CEO. Get him to make you VP of software and tell him you'll solve the problem if he gives you responsibility.
Management may be doing its job perfectly well! This could quite possibly be R&D code that was hacked together by scientists with no formal training in programming (most likely Biologists). The R&D code then found it's way in to production (because they needed to get something out the door).
The software is good enough to get the device working, and it's the performance of the device that makes the company money, the software just has to work ``well enough'' the device is where the money is made.
Man
Re: (Score:2)
I am not advocating fully blown production system and project management, however chaos and lack of documentation 'because this is one off tool we will not be using anywhere else' is likely to be costly if things go wrong, author is sick or left company and deadline is pressing.
Then again this all depends on the size and importance of particular software. You need not document every software fart people write to get some one-off calculation/result fast.
For drivers and such I would keep a copy and care for d
Re: (Score:2)
This is a good idea, but ... ... make damn sure you have all the decision making power to be able to take on the task you're making yourself responsible for.
E.g. you can blabber all you like about code quality and procedures, but if your department is understaffed you will not be able to do anything about it.
Also, if someone dictates deadlines for the completion of parts of the software, and you have no influence on these deadlines, you're f**cked too.
Make sure you're not setting yourself up for failure ...
Opinion from the outside? (Score:5, Insightful)
Could you propose to hire a software test consultant for a day or two and let him point out serious quality issues (data integrity, security, correctness..)?
A serious, alarming report by an external software test professional could help reinforcing your requests?
Re: (Score:3, Interesting)
Could you propose to hire a software test consultant for a day or two and let him point out serious quality issues (data integrity, security, correctness..)?
A serious, alarming report by an external software test professional could help reinforcing your requests?
Won't work. Obviously, the CEO doesn't actually care about this issue. I've been there - except it wasn't for a biotech company, it was a small software development company. The execs there were content to allow the development team push code to production whenever they cared to. The dev team was also responsible for production support. As the lone test/QA person, I had zero pull. "that's the way we've always done it" was the mantra. We were pretty good on security, but code quality was awful. We ha
I have the same problem (Score:5, Insightful)
I have the same problem where I work, the problem is I am the dev with real commercial experience; I just can't convince them that we need to do things in a manner that I would consider correct - it's all ad-hoc development and it's all driving me nuts.
The problem is, if our software doesn't work correctly, then the data we collect and process using it becomes screwed up, which is a major issue for the core business - data is our crown jewels.
My current solution to the problem is looking for a new job in a company that actually takes software development seriously. I just can't see any way of getting things here working the way I want. There wasn't even any revision control in place on the source code when I started.
The problem I'm finding is that the lack of structured development and design here is actually beginning to hurt me professionally: prospective employers, who have software development as a core aspect of their business, actually ask about this kind of thing. If you're looking to hire someone who takes their profession serious, for god's sake make sure they're actually going to be able to do their job - otherwise your company is just going to turn in to a blot on their CV.
As a C-Level for a Software company (Score:5, Informative)
Prepare a brief for the management-level at your company. Show them basic tools for managing software quality. Dig up documents that show different ways of improving software quality. Talk about development methods (agile, etc).
Tools like Redmine are very pretty and manager-friendly (and free). Show them how easy it is to add tickets, approve and deny work, track changes to the software as it evolves and isolate changes until they are tested properly.
Point out that there is a potential legal minefield if they get something wrong and it's proved to be the software at fault. Show them that tracking each and every change along with who authorised it, who did the work, who approved the changed software to run, etc will help lift some of that liability.
Managers aren't all clueless, and all ones that I know are genuinely willing to do things better. Often they are too caught up in doing things to appease the board that they don't have time to look at things that seem menial to them.
If you don't prepare a brief and suggest a really good solution or two they'll eventuall get a contractor in who will charge a fortune, tell them that everything sucks and then leave. Then you'll be stuck with a half-arsed process based on some pie in the sky ideas from a contractor who really can't know the day to day ins and outs of what you do.
At the end of the day what you need to demonstrate is that by putting a process in place and then tools/staff to support it you'll be able to achieve better results.
If he does this ... (Score:3, Informative)
... his C-level management may end up promoting him to be the software development manager. It might even include a raise.
Re: (Score:2)
It's all very well getting a raise, but not if it takes you out of a job you enjoy to a job you loath.
Re:As a C-Level for a Software company (Score:5, Informative)
All the folks who have suggested coming up with solutions not problems have got at least part of the answer.
I've spent a few years working with a team that has moved from being a bunch of individuals who just make changes to the code ("highly skilled desperados"), to a team where there is:
All of this has helped improve software "quality".
And it's in an R&D environment, i.e. it's internally written software to support teams of research scientists and their data and instruments.
We now feel we have reasonable control of changes we make - we know why we want them, and what they are likely to impact. It's much better than when we started - 3 months of firefighting, just trying to keep the software system afloat.
Suggest some or all of the above. Try to quantify the costs, or at least the risks, associated with leaving things as they are. Talk to whoever is the CIO or equivalent. Find the highest-ranking person in the company who understands software and sell the problem and solution to them.
Other angles to try - see who you could get to give a talk at your site on software quality etc. Can you tap into a professional body - like the BCS in the UK?
Good luck!
Re:As a C-Level for a Software company (Score:4, Insightful)
Do not bring up agile in this situation. You want to push them into a paradigm that is structured towards responsibility, not something that allows development to wash their hands from anything and just blame business. In the situation described in this story the best way to go is by setting up a structure that forces a couple of things: documentation of requirements up front, system and design specs, phased iterative development, unit testing of course, QA department, responsible management. I know it sounds difficult, but you have to work towards it, nothing is easy.
A suggestion on how to handle this (Score:3, Interesting)
Very interesting question. I see two things that might help. First, don't go to the CEO. You and him clearly speaks different languages. Go to your nearest manager instead and explain to him the consequences of not having procedures. I am sure you can convince him of this, and after the discussion do not settle for a "I'll look into that and get back to you". Always end your meetings with a list of action items with _who_ does _what_ and _when_. This way, you will have clearly defined dates you can follow up on. Have him commit to a date when he will do X (for instance - talk to the Director) and set a date for a follow up meeting with you where he will explain the outcome of said meeting. Should the meeting be canceled, be sure to get a replacement date and set follow up meeting accordingly.
Use We instead of I (Score:5, Informative)
So instead of "Sorry I cannot do this since I believe that you must follow the testing procedures." you could write it like this "Sorry, We cannot do this since we believe that you must follow the testing procedures."
I lol'd but I find myself writing such mails from time to time..
Re: (Score:2, Informative)
The only people who should use the Royal We are editors and people with tapeworms.
-- Mark Twain
Mixing of two mindsets (Score:3, Insightful)
Hi OP,
I'm a developer/Engineer for two biotech companies: one a small startup, with me being the only part-time employee. The other is a large DOD-backed institution. I can tell you that in the short time that I've been there, it has been a frustrating uphill battle to instill an Engineering/Developer mindset. While I firmly believe Scientists and Engineers seems to have a similar approach to work, it's interesting to see how passive the science-minded folks are towards hardware/software advancements. They are only concerned about how many protein cells it can accurately count, or whatever. There is no interest in what goes on 'behind the scenes', and consequently, what goes on to get there.
There are absolutely no Engineering controls in place at either Employer, and software development is as you said: made for the moment. Personally since I am the one-and-only, I find that I just have to do the best with what I have. I comment and doccument well, keep a code revision repository, and do my best(within reason) to make sure someone else can pick up where I left off.
It won't be my problem if/when the day comes I leave, but at least I'll be able to sleep at night.
Re: (Score:3, Interesting)
I had a family member who used to work with these kind of measuring machines...
He would often complain about how the old but functional machines would be replaced with fancy computer controlled ones, where the software would be extremely limited and often horrendously buggy.
Make the case (Score:2)
Make the case to them for why they should care. In terms of money saved, or reduced legal liability, lost opportunity cost risks associated with buggy research software, etc.
If you can't figure out how to make that case, then your company might actually not need improved software processes. If you *can* make the case, then...
(a) you might get the help you're looking for, and
(b) you'll have a better understanding of the
business and of software development, and
(c) you'll look go
Reminds me of Ariane 5 (Score:5, Interesting)
We have no senior management with any history of commercial software development
That reminds me of Arianespace. It took the crash of a 150M$ rocket to make them change that.
Re: (Score:2)
I think this is actually the clue to a good solution to your problem. Don't just say "we have a disconnect between our engineering and software development processes" - show them examples of where this has FAILED in the past.
Ariane 5 is one example. The Therac 25 [wikipedia.org] is another one that comes to mind. You can find many such examples on the Risks forum [ncl.ac.uk] which has been documenting such issues for YEARS.
Good luck.
Open source it (Score:5, Interesting)
However, you should try and convince you're management to open source the software. In this industry the probability is that if you don't open source it someone else will write an open source replacement (see Phred/Phrap, and the open source replacements of the primary data analysis software on next-gen sequencers which are starting to appear). That means your company losses control of the primary data analysis and possibly device control software, and that's bad for your company.
Open source has the added benefit that your development costs will fall (you can start using GPL code), it'll help you engage with the scientific community and you'll get people outside the company doing free work for you (seriously people want to get this stuff working, they'll help). You'll also get free peer review on your code which will drive standards up.
Scared of showing your crap code? Don't be, in this industry I've seen enough to know that most of it sucks (a lot of it's written by Biologists with no formal training). The clincher? "ABI are doing it, why can't we!" http://solidsoftwaretools.com/gf/ [solidsoftwaretools.com]
Re:Open source it (Score:4, Informative)
Re: (Score:2, Interesting)
It's gotten somewhat better over the past 5 years, but as the hardware lives for 20 years, we end users get to enjoy the crappy software long after the company has moved on. It certainly does color my decision about which hardware I will buy in the future, though.
Yea I wouldn't argue that ABI software sucks, but it's a useful stick to beat management with. I'm not sure it's got much better... They've not open sourced the primary data analysis or device control software for the SOLiD sequencers (which suck hard). From what I could see a lot of the device stuff uses messy perl scripts.
I really wish they, and Illumina the current next-gen leader, would open source their software (both device control and primary data analysis). If that were the case I'd be refactorin
Re:Open source it (Score:5, Informative)
Been There - Don't Burn Yourself Out (Score:2, Interesting)
I worked for a small medical electronics manufacturer in the UK. They had no software development team apart from me. I was fresh out of college and eager. I replaced the previous "software guy" who had walked out. No documentation or code was actually in place. The software standards that we were supposed to abide by were considered by the management to only be important when a product was finished. I ended up stuck in the middle between t
It depends on if you are a dev yourself. (Score:2, Interesting)
If you are a software developer yourself, try to set up proper division yourself by talking to appropriate people in positions.
If not, stick to biotech. Software developing is engineering too, and it is not a good idea to do amateur in-house engineering, especially if your software products need to be of mission-critical kind. Outsource all software related job(s) to someone else who specializes in software design and development, and you yourself will sleep better.
Some hints for your situation (Score:5, Insightful)
I'm in a quite similar situtation, and perhaps I can provide a few hints from what we're currently doing.
I'm working for a relatively well-known institute in academia (biotech field), with a group that among other research projects, also provides web-based services to the research community. Funding is partially tied to the operation of the services, so there is actually enough pressure to make sure that they work and work correctly at all times.
Still, until about a year ago, development was very ad-hoc, in a mix of languages, and with many "islands of knowledge", where some parts of the system were only known to one post-doc, and other parts could only be fixed by the group head (who, as they are, was usually busy with many other things...). After some hard times and near-misses, we started looking around for ways to improve our development.
I was quite attracted by the ideas of Agile, and I believe that they're a good fit to the kind of processes you find in science, as well as in software engineering. We initially had a professional Scrum coach come in and talk with us about software development practices, and then decided to apply Scrum to our processes.
It's now a bit more than 1 year since then, we're still using Scrum with a few adaptations to fit the academic environment (we're also using Scrum for projects that are really science and research, not software development). In a recent secret poll among the team, Scrum got high marks for making the team more productive, and for creating an environment where code and knowledge is shared. People are happy with the structure that Scrum provides, and we always know where the project stands. Incidentally, we also write better software faster.
But we're still improving the way we work. The transition is slow and painful, and we're only slowly adopting things such as test-driven development, automated builds and pair programming. In my experience, there's a lot of resistance against these "newfangled" methods in the academic culture, especially that of people who weren't trained as software engineers, but rather as physicists, chemists, biologists, but now find themselves producing software.
Some hints on what I've found useful in re-shaping our work environment:
- You can't change the whole structure in one day. Get permission to run a small, isolated project in "the new way", and use this to demonstrate the advantages. Remember, there are many metrics for success: Code quality, timely delivery, not having single points (persons) of failure, as well as team velocity and personal satisfaction. Try to make a case from this small project (and gain experience while doing so), and then grow it out slowly.
- I would not advise to do some clever "breaking the build, and thus showing everybody how fragile the system is" exercise. This may not be seen as constructive.
- Instead, provide convincing evidence by example that your way is more productive and more certain. Bugs that are fixed stay fixed, and don't creep in later again. Timelines are better kept. That sort of thing...
- If you can get someone in to talk about the current best thinking in software development, do so (someone else mentioned this already). It's good to hear an outside opinion, and to understand that these practices are not theoretical but used by large companies world-wide.
- I found Joel Spolsky's 12-point assessment very useful to find out where your organization stands: http://www.joelonsoftware.com/articles/fog0000000043.html [joelonsoftware.com] ... These are also good points to whisper into management's ears.
Quality Software development is hard (Score:5, Informative)
As someone above mentioned, good advice on this question really depends on if you are writing software or not. If you are not involved in writing software, and you are not executive level then just stay out of it. Even if it is mission critical and you see something seriously bad, it's not your business. You've explained the issues, your observations have been listened to and acknowledged. Now you have to trust that your management is doing the right thing. If you don't trust that, then you have *much* bigger problems than software...
But if you *are* involved in software and you want to improve the situation, then it *is* your business. But after years of doing software process improvement I'll tell you that it's a long hard road you'll be walking and you need to be patient.
First of all, making it widely known that the people writing the software are doing a bad job is not going to make you friends. You may not have intended to insult everyone who works on software in your company, but by walking up to the CEO and telling them that nobody knows how to write quality software, you've pretty much done that.
Software process improvement is less a technical issue than it is a political issue. You've got to work on your people skills. You've got to make friends. You've got to make people eager to hear what you have to say. So the absolute very first thing you've got to do is "turn that frown upside down". Nobody wants to hear that they suck. You've got to be positive. You've got to smile. You've got to encourage people and sing their praises.
I know, I know... they really all do suck. Been there, done that, got a closet full of t-shirts. But you are where you are. And you aren't going to move anywhere by attacking these people. So sit down, relax, take a deep breath and get used to what you see. Because it's not going to get to great any time soon.
BUT (big, big, big BUT) if you are smart, and skillful, and patient, little by little by little you can improve things. If you are a coder then you can start with yourself. Do one small thing. Be successful with it. Then go to your buddy and say, "Hey... I started doing this one small little thing and my life is better. Wanna try?"
Keep doing that. Ask other people for their opinion on something that would make life better for you. Then say, "Hey, cool idea! Let's try it!". Keep doing that.
If you see something that's good, yell it out to the world. Say, "Wow! That's fantastic! Did you see what so-and-so did? We should all do that!". Keep doing that.
And smile. Every day. All day. Tell people how smart you think they are. Build up their confidence. Look at their code and compliment them. If you see something that could be improved, say "Hey. You know what? I have an idea... what if we did X here? Do you think that would work?" But for every time you do that, make sure to find 10 other things right that they are doing.
It's bloody hard. It's fucking hard. To be so positive every day. To tell people that you think they are good people. That they are good employees. That they work hard. But that's what it takes to make improvements.
Trust me. And in the end your patience will be rewarded. Because in my experience, most people want to succeed. They want to be kick-ass at their job. They just want a nice friendly person to guide them there. And then they'll go. Easily and willingly. And after all that, it turns out (from my experience) that all those nice things you said over all that time -- turns out to be true (9 times out of 10 -- the other time the guy really is a hopeless wanker).
you're pressing the wrong buttons (Score:5, Informative)
Have you quantified the benefits of improving software quality?
Have you laid out the risks (both personal, to the directors and to the share-price) of low software quality
Did you make the guy aware of the legal implications and liabilities?
Did you describe what the competition does?
Did you actually propose a planned and costed solution - or were you just moaning at him?
But most importantly, did you wear a tie?
Re: (Score:2)
What exactly means "Non-Software Company"? (Score:5, Insightful)
Don't raise a problem.. (Score:2)
Turn up with a solution...
What the Hell are you talking about? (Score:2)
No one has any "quality control procedures" in software. At best a company has someone responsible for testing, and some product-specific set of tests that products pass through before being released or placed into production environment. If you are a developer, just make those things and write a deployment procedure that includes them.
Re:What the Hell are you talking about? (Score:5, Insightful)
Go read up on the Capability Maturity Model (CMM) or ISO 9000 and come back when you have a clue.
You don't even need to formalize the process to that extent to make leaps and bound improvements on the hack-it-together and test it approach you are suggesting... At a minimal a decent software development process should have:
Requirements specifications & reviews
Design specifications & reviews
Test specificiations & reviews
Codng standards
Code reviews
Source control
Regression tests
Functional tests
Load tests
"good enough" is good enough (Score:3, Interesting)
The company's troubles get worse when in the process of discovery, the plantiff attorneys find that instead of due diligence with respect to software development processes, there was no diligence.
The situation is a disaster waiting to happen. If the author has presented his concerns to top management and they've been ignored, if he's proposed to solve them himself (they probably do need somebody C-level in software development) and that fails, the guy needs to update his resume and call the headhunters.
Or become the fall guy when good enough is demonstrated to be not good enough in a court of law. CYA records of meetings and e-mails demonstrating that the writer saw a problem and tried to get it fixed to run into management non-cooperation might get the author off the hook for personal liability, but probably won't save his career.
Its pretty common don't you think? (Score:2)
It seems to me that in business outside of the IT department it is pretty common that the software element of the widgets they sell is just not important. That is until someone get hurt or worse. Just look at the trend of outsourcing programming. I see things sold all the time that require some kind of embedded software to control the various components that are munged together to make some kind of "system" that the customer has dreamed up. Then when it is installed all of the various contractors that are o
Open source (Score:4, Insightful)
This sounds like the perfect scenario for open sourcing your software with you as the main developers maintaining it.
For the regular users, nothing much will change.
For the power users, those most likely to complain, this will be a tremendous benefit. If they don't like it, they have the possibility to improve it. This often reduce the number of problem reports and increase the good problem reports from your knowledgeable customers. Sometime you might even get useful patches, that save you some work. If you're really lucky, you might get a few users who start to code enhancements.
It also might generate some good-will towards your company and ease the integration of your bricks with other solutions.
What has this all to do with software quality? With your software out in the open, quality problems tend to be treated more like bugs that will be fixed as fast as necessary and possible and you get a better feedback where work is important. Making the software and drivers open source won't save your company any money, it won't cost more either, but it will improve what you get for your effort.
About Open Sourcing (Score:3, Insightful)
I'm a big fan of open source.
Most of the hardware at home has had its OS/firmware replaced with open-source variants.
BUT
Keep in mind that the software in certain types of devices is part of the 'competitive advantage' over other suppliers.
If you open-source the firmware/software of your instrumentation, a competitor can very easily build a similar device cheaper (because you already did most of the development).
I'm not saying you shouldn't do it, but you should show management that you are not 'giving away
Contract IT Consultant(s). (Score:3, Insightful)
No they are not as evil as the Democrats says. Most of them want to do a good job so you will call them back in the future.
Why contract except for hire.
1. They can be paid for out of your department budget not the general budget. So it requires less steps up to get approval.
2. They work outside of HR. So you can hire them and fire them if you feel they are not doing the job correctly
3. Use a Multi-level support system. Get some Jr. Consultants to do the grudge work for cheap for 3 days on 2 days with a Sr. Consultant to insure the Jr.s are on track and solve larger issues deal with your department give any bad news and estimates etc...
4. More experience for less years. Especially if you get a good mix. You can get a specialist in X and Y and Z because you can use a consultat for their strong points.
5. If you give them motivation that there may be more work down the line they will focus on getting the project done. Yes they want to stay there but if there is a chance of a new project further down the chances of them milking you is a lot less.
Certification (Score:5, Interesting)
If you are in the bio tech field then all of your processes need to conform to ISO13485. There is a section specifically about software. Your company won't be in an FDA/CE regulated environment long unless you comply with those quality standards. I suggest you research the guidelines and point them out to your quality manager.
Re: (Score:2, Informative)
Perhaps you need to include this link in your .sig
http://www.google.com/search?q=fda+warning+letter+software [google.com]
These are the types of things that shut entire divisions down for months to years at a time. If your company does not have enough money to run with full staff plus very expensive compliance consultants for 12 - 18 months without manufacturing or shipping product, this could cause your company to fail.
Re: (Score:3, Interesting)
Yah, but the FDA takes Section 201(h) of the FD&C act to define software as "a device".
It doesn't even have to be controlling hardware, things like a blood bank inventory database gets covered since if it screws up, then actions happen that are covered by the FDA(bad/wrong blood gets used).
Look at some of the letters in the other AC's google query, the FDA will come down on you for things you'd think are barely related, like your bug tracking software not requiring you to reference and collate similar i
Been there, done that, got fired (Score:5, Informative)
Old chinese proverb: "The nail that stands out gets hammered".
I was in a very, very similar situation. In a company with not a shred of software quality control. Everybody listened to my presentations suggesting we get someone with software engineering experience in the loop. Even a "thank you" from the CEO.
Six months later, I got very firmly terminated on wholly made-up charges of poor performance.
Draw your own conclusions.
Re: (Score:2)
Conclusion: You spent too much time putting together presentations and not enough time doing your own work?
Personally, within a software development environment, I've found that the people that focus too much on processes are often the least productive. Too much red tape can be every bit as bad as too little.
Without knowing the actual metrics against which your performance was being measured there is no reasonable conclusion to draw. (Unless evaluating your software quality control systems was part of what
Re: (Score:3, Informative)
Logical conclusion, but.
The last three projects I did got done ahead of schedule, and passed all the tests.
And yes, I was supposed to be working on quality issues.
Apparently middle managers do not really like having their cluelessness pointed out, not even if it is gently and diplomatically presented. Who knew?
Missed the obvious solution (Score:4, Insightful)
Make it fail. Make it fail spectacularly, to the tune of millions of dollars. That will certainly get the CEO's attention, and he will be sure to take measures that will stop such failure in the future. Of course, I can pretty much guarantee that you will not like his solution, but software development will be much more professional afterward.
If this is not what you want, ask yourself what you actually want to change. You do know what you want to change, right? Discuss those things with colleagues and managers, then formally propose doing them.
I'm guessing you probably want a more structured development process, with better-organized change requests, and at least some semblance of formal testing. That is very, very hard to set up, because it also requires the help of your users, and they don't care about software, they just want to have their problem solved. If this is the case, always remember that you are there to solve their problems, but they are not there to solve your problems. In other words, don't force them into a process they don't like. You might do better if you can show an advantage other than "it makes my life a little easier".
If all you want is a bugtracker and a version control tool, just request a budget of about $2000, then buy a Dell PC with Linux and install Bugzilla and SVN on it. That will set you back $400 or so, the rest of the $2000 is to show that you are a business thinker and did not forget to include installation time ;-)
If you want to institute Methodologies (like extreme programming or similar), good luck with that. It will probably end in your colleagues defenestrating you...
Re: (Score:2)
You're going to put something as important as your source code repository on the quality of hardware that comes with at $400 PC?
You're right, that will make it fail, and spectacularly.
proactive synergy and high positive visibility (Score:3, Interesting)
Some people here will tell you to start dropping managerisms (like those in this message's title) and talk costs. They are correct, if you want to move into management. If you want to stay a programmer, however, just fix the damn problem. Nothing you described is too terribly difficult to correct on your own. Install and use Hudson [java.net]. It has plug-ins for .net and java language support (and probably more). Make sure you really use its code quality plug-ins (things like fxCop, findBugs, and PMD). In short, do al little every project to improve the development environment. These are free tools and fairly trivial to set up. Getting your environment right is part of your job as a developer. Don't abdicate that responsibility to management, especially if management doesn't understand what your development environment needs.
It is a fact of life that most non-software companies have not yet woken up to the emerging criticality of their software divisions. What you describe isn't surprising or unusual. Be better than 70% of your peers by fixing the problems as you see them. You will learn to be a better developer and management will learn to appreciate your efficiency. If they don't, so what? Move on with all the knowledge you gained building up their development infrastructure.
So That's Why Instrument Software Sucks... (Score:4, Interesting)
I've been a research scientist for, well, long enough and a computer nerd for a lot longer. I've always wondered how it is that a company can make a state-of-the-art piece of research equipment and then bundle it with a PC running Windows 95 with a serial interface and the worst, least intuitive, and most expensive software I have ever seen.
Now that I'm in charge of picking what we buy I make it a point to find companies that support Linux because it usually means they have a real software development team and that they don't outsource their development. (Jovin Yvon who bought up all their competitors were the worst at this, charging $5,000 to re-install their fluorimeter software, the installation CD for which they refused to sell based on "licensing" issues.). And I'm usually right.
Most recently I purchased a $70,000 high-speed InGaAs camera that came with Windows-only software (that wouldn't run in virtual machine either because it required low-level NIC access). They charged another $2,500 for the "intermediate" software package (which I have no problem with in itself) that had a bug in it. The bug? It wouldn't export movies longer than 10,000 frames, which at 1,000 fps is 10 seconds of video. It took them three months to get me a beta version of a different piece of software that would allow me to export longer movies.
Another company, which I love doing business with so I'll mention them here, EPIX Inc., makes less expensive high speed cameras, but develops their software in Java and releases Linux versions. The software is buggy--as is all instrument software--but I can actually call a real software developer on the phone and tell him/her what the problem is--imagine that!
Sorry for the rant, but this story makes it clear to me why instrument software is so terrible. The first major company that figures out how valuable intuitive, functional, cross-platform, (and for the love of god, not hardware-keyed) software that doesn't store data in some unholy proprietary format that physically ties people to the machine that the instrument is attached to just to process the data is... Ok, well the few companies (I'm looking at you Bruker) that have figured that out have staying power and brand loyalty in university research where as the others are used as pejoratives.
Perhaps nothing is broken? (Score:2)
First off your primary company mission is not software development it is just a cost of doing business. Next thing you have to ask yourself is anything really broken? I recently got hauled into a project which by all accounts sounds similar. The code and architecture of this system is very fragile and difficult to maintain however it does work and performs probably one of the companies most mission critical functions. I am presented with two courses of action, rewrite to make it more stable and maintainable
It's ABI isn't it? (Score:2)
God their software is awful
w00t! (Score:2, Funny)
It's really not that complicated; I'll paraphrase your two fundamental options in a way that most
This is your last chance. After this, there is no turning back. You take the blue pill - the story ends, you wake up in your cubicle and believe that your organization is on track. You take the red pill - dust of your resume or maybe start your own company.
If you find yourself losing sleep over the matter just ask yourse
My erstwhile employer had a similar problem (Score:4, Interesting)
Let me tell you a little anecdote which was relayed to me by the IT manager at a previous employer.
When he came to the company, software quality had never been taken particularly seriously. They'd insourced IT where previously everything was handled by an outside company, presumably in the hope of getting better quality services for their money, but were seeing little benefit - mainly because the IT department was so busy implementing new features the business wanted they never had time to debug existing issues.
Helpdesk call levels were very high, the IT department wasn't particularly highly respected in the rest of the business and while the business probably did want less buggy software, they were always too busy chasing after the Next Big Feature to allow the IT department to concentrate on bugfixing.
So he went to the business (ie. the directors/senior management) and said "OK, here's a suggestion. We'll spend the next three months working on nothing but bugfixes. No new features. What glitches with the system are impacting your staff?". The business wasn't hugely keen on the idea of no new features for three months, but he was able to persuade them that the benefits of having more stable software outweighed this.
Three months later, the business was so impressed with the improvements that they asked if the IT department could spend another three months doing nothing but bugfixes.
Sometimes, the business needs a little poke from IT to understand how to get the best benefit from the IT department. Being able to recognise this and make a suitably diplomatic poke is what IT management is there for. If there isn't clear IT management in place to make such a poke - well volunteered.
Use the right language (Score:5, Insightful)
Find out how much it will cost the business if the software stops working. Estimate the risk (number between 0 an 1) of this happening. Multiply these two numbers. The result in dollars is the amount of money your company will lose with certainty. Not maybe, with certainty.
Switch jobs (Score:3, Insightful)
Either start working for a company that do care about software quality, or start your own. I know it is a pretty drastic thing to say, and one I haven't (yet) followed myself, but I do believe that it is the only way.
My hopes would be that the more good engineers that start software companies that care about how things are done (and thus the end result) the less new companies needs to be started because the old ones suck. There are reasons why one sticks around a crappy company that treats you badly in one way or another (which I think is the case in this case), and the best hope for the people who can't leave that easily to form their own company is others doing so and they following when things have stabilized.
Keep in good contact with each and every good engineer you get to know :)
Be careful what you wish for. (Score:2)
Therac-25 (Score:2, Interesting)
http://courses.cs.vt.edu/~cs3604/lib/Therac_25/Therac_1.html [vt.edu]
In summary, you're fucked. Get as far away as you can before the lawsuits come.
(And yes, I know that he isn't making therapeutic equipment - like that matters in today's legal climate)
I work for a Very Large Non-Profit with a biomedical branch, and they've been working on a new software system for years. After hundreds of millions spent, they still can't figure out how to process a lot of database transactions quickly. When asked why banks can d
What, exactly, are you? (Score:2, Insightful)
Are you a programmer? A SysAdmin? PS? QA?
Are you a worker, a lead, a manger, a PHB?
Each of these generates a different answer.
You Don't (Score:2)
C level execs don't even talk a language that can frame software quality into a meaningful concept. It's a CIO's job because they would recognise that as a factor and translate it into points that the other execs could understand.
You say "software quality is a real problem because we will have to re-implement systems a few years down the track"
They say "We have some challenges that can dictate our capacity to grow in the 5 to 10 year timeframe"
same thing - different language. You should think of a CIO a
I've been there and I feel your pain! (Score:3, Informative)
what your company must do (Score:3, Interesting)
The comments in this list about federal law requiring a quality system *including software quality procedures* are correct. There is no way out of this and the company has a tiger asleep in engineering. The reason the omission has not surfaced is that FDA's budget has prevented them from auditing deeply enough - yet. They haven't been able to send auditors with enough software background to be able to detect the absence of the expected levels of software QA. They definitely have the qualified people, just not enough of them.
An additional reason could be that the product/service has not hurt anyone, or if so, the incident(s) have not been reported - which is another federal law incumbent on the manufacturer AND the hospital/clinic/doctor. FDA audits and warnings can come any time if enough of these reports stack up. Or if the docs send them in and the company does not.
Even if the code is really good and no medical problems have come up, that will not stop FDA from pulling your product off the market if they find you non-compliant with their regulations.
So the company has 'enjoyed' a prototyping phase. Once the management has read the FDA regulations on the personal liability of the company officers, they will probably want to get started with the formal software QA system right away. It doesn't have to be completed overnight. But when/if FDA look deeply enough into your company, you would want them to find records of your diligent work in building up the software QA procedures and practice in an ongoing and steady way. And doing the right things first.
Are you out of your mind? (Score:3, Interesting)
Are you out of your mind? By going to the CEO with a quality problem, YOU are the one who is going to be fired when the flaws in the jury-rigged software cause a major problem in the company profits. You tell me that I'm paranoid and crazy. Well, sir, this is the way that American management works. You understand technology; they don't. They understand corporate politics, backstabbing, and manipulation of employees for their own gain. You don't. The fact that you went for a one-on-one with CEO proves this.
The only time that a mid-level technical employee goes for a one-on-one with the CEO is when you are setting up a fellow employee to get fired over a problem that you caused. It's a classic 'cover-your-ass and make someone else take the blame' type of situation. Which, if the situation really is what you say in your company, is not far in the future. By going to the CEO and discussing the situation, the CEO is going to assume that YOU caused it and are doing a preemptive bid to pass the blame on someone else. When the major problem does occur as a result of the unstructured software, the CEO is going to agree with all the other people in your group who are going to put the blame on you to save their own jobs. And you are the one who is going to be fired!
You should get another job in another company as quickly as possible. And, my friend, never go to management with a problem that has its underlying cause in someone's lack of management ability. It's corporate politics rule #1.
Create two presentation slides (Score:4, Interesting)
1) We create software.
2) Software is used in medical devices.
3) We forego QA and industry best practices for software development.
4) Something goes wrong.
5) We get sued AND we lose (to the five-nines sure).
6) Change #1 to "Update resume".
SLIDE B
1) We create software.
2) Software is used in medical devices.
3) We follow industry best practices for software development and have a solid QA program.
4) Something goes wrong (yes, it still happens).
5) We get sued.
6) Our controls and best practices are a reasonable defense.
relate it to legislation / federal regulations (Score:4, Interesting)
One route to making people serious about IT processes is to relate it to relevant federal regulations.
For example, we've been doing work that will eventually involve us as a partner in upcoming clinical trials. There's a bunch of federal regulations about IT processes connected to clinical trials, and it has been easy to get management to accept that while our current processes can be as ad-hoc as we like, at some point having compliant processes will be essential to continuing the work we do, so we may as well get it right the first time rather than have to reimplement years worth of ad-hoc development somewhere down the track.
In my case, one trivial example has been being able to implement gpg signing of documents as a consequence of setting up the infrastructure to be able to be quickly compliant with 21 CFR 11 [fda.gov], which we'd need to do if we're part of a clinical trial.
That is terrible advice (Score:2)
Re: (Score:2)
My reading was that the person isn't so happy with the situation, they want to improve it some what.
Well, they've tried, they even talked to the CEO. They aren't interested.
Besides, if you are scared of getting fired, nothing will even happen. How do you think most workers rights were brought about? They weren't brought about by bowed heads, there were strikes, and sabotage, and police shooting protesters.
So, don't be scared, step up to the plate and swing the
Re:Plant a bug (Score:4, Informative)
Re:Plant a bug (Score:4, Insightful)
There are better ways of doing that, such as persevering, practicing what you preach (good development standards and approach), being firm with management about the issue.
Re: (Score:2)
Very few people will complain about bugs anymore, microsoft has convinced them that bugs are normal and to be expected, and that you have to try and work around them...
People used to complain, but years of getting no sensible response has worn them down.
Re: (Score:2)
lol... actually, it could work... insert goatse into the error dialog, or about box, or if it deals with images, every 50th image is, or has an overlay of goatse...
"see? there's no quality control here, we need to fix it"
Yeah ok so its not the best idea, as someone will probably get fired, not to mention pissing off clients, but I bet they pay more attention to the coding there-after...
Re: (Score:2)
Document the hardware, provide details of how it works, how to control it and how to read data from it..
Provide a few small programs that acquire data and output them in standard formats (as you pointed out, text).
Don't try to be too fancy, provide good functional and open tools that other people can build on. Depending how niche your product is, third parties may write software to work with it, or the customers may have especially custom requirements that aren't served by the bundled software anyway.
Re:Here's a revolutionary idea (Score:5, Insightful)
This argument is also known as "The Enron Gambit": those wildly successful guys who are raking it in hand-over-fist must know better than those of us who think that their business model makes no sense. They sure showed us.