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?"
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.
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:Plant a bug (Score:4, Informative)
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:Open source it (Score:4, Informative)
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: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: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:Anarchy is an opportunity (Score:5, Informative)
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.")
Re:Open source it (Score:5, Informative)
Re:Certification (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:Practice What You Preach (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.
Re:Use We instead of I (Score:2, Informative)
The only people who should use the Royal We are editors and people with tapeworms.
-- Mark Twain
Re:Been there, done that, got fired (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?
Re:Practice What You Preach (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.
I've been there and I feel your pain! (Score:3, Informative)
Resource (Score:2, Informative)
Fearless Change. A pattern book for how to introduce change in the workplace. Originally written for the software industry but having universal application its located in the business section
Re:Practice What You Preach (Score:2, Informative)
Re:Practice What You Preach (Score:2, Informative)
I want to underscore something that electroniceric touched upon:
Your biotech firm's lack of SOPs and BPs on software development is in direct violation of the Code of Federal Regulations. If the FDA audits your firm and finds this lack of compliance to 21CFR820, then the FDA can issue a Warning Letter, which will absolutely have an adverse effect on the company. Warning letters always hurt the company's stock price; investors take WLs as a sign that the company is being mismanaged.
If your CEO doesn't want to believe this, then he or she shouldn't be in that position.
FYI, here's one example of a medical device company that received a warning letter from FDA for failure to properly document software development:
http://www.fda.gov/foi/warning_letters/s6752c.htm [fda.gov]
But Warning Letters aren't the worst thing that FDA can do. For failing to follow CFRs, FDA can determine that drug products (small and large molecule) or med devices are misbranded or adulterated and can demand the company recall said products. This will destroy a start-up or small company....
Good luck with this issue.