Slashdot Mirror
Software Quality In a Non-Software Company?
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?"
You're obviously fighting an up-hill struggle. Going straight to the CEO is both a good and bad idea - if it works you'll get immediate affect, but it's likely to be ignored.
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?
ilovegeorgebush
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.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
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?
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.
I drink to make other people 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.
Management are possibly right, the important thing is getting the product to market. If the R&D people write bad code, but code that works, and it gets the instrument to market then ship it. If it's instrument based, the software isn't the critical problem (if it works better than the other guys you win, doesn't matter if the primary data analysis software sucks so long as it more of less works).
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/
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 ... These are also good points to whisper into management's ears.
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.
The reason we subjugate ourselves to law is to better procure justice. If law does not accomplish this purpose then it m
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.