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?
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.
Yeah, I had a sig once; I got bored of it.
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!
I remember this WTF article at the DailyWTF (I forgot the title) where in order to become firm and get your point across, his superior told him to use WE and OUR instead of I and ME in his email correspondence.
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..
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.
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).
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?
politicians are like babies' nappies: they should both be changed regularly and for the same reasons
I have worked in enough software companies to know that they are not necessarily better.
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
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.
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
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.
Censorship is telling a man he can't have a steak just because a baby can't chew it. --Mark Twain
...and that language is money.
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.
My opinion? See above.
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.