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;
This is a common theme from many companies, especially the one I'm with right now. Companies just don't get it sometimes and they let things slip by them. The biggest issue is, should you care more about it then the Management above you? Should you burn yourself out? Let them worry about the botttom line, u should do whats best for yourself. And above all else, don't stress yourself out over it. Once you've learned to let go, you'll realize how many other things are more important in your life. Plus you can always switch jobs so no biggie!
The US Gub'ment. Lots and lots of GS15s sitting on their collective asses waiting for 5 o'clock to roll around. I was amazed, and moved on.
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.
From my experience, just give them your thought, complete with benefit & risk. Give them the insight on what would happen if they don't follow, and then let it rest. Make sure you give it to them in WRITING. Should something happen, you have your defense.
I know, this might seems a little coward. But In your case, the software is like the heart of the company. Dealing with your company who don't take their software seriously is like a doctor dealing with patient who don't take their heart seriously. The patient might agree that his heart condition is an issue, but takes no action nevertheless. If the patient gets a heart attack and die, can we blame the doctor??
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!
If the problem is that critical, the business will either:
A) Fix the problem, because the problem will cut into the bottom line.
B) Go bust because of the problem.
If you do not own or have shares in the business, i dont really see it as your problem.
If you think B is inevitable, dust off your resume.. and if you also own shares, sell.
Just make sure that you have documented that you have spotted a problem, just to cover your own skin.
Darwinism@Work.
Nah seriously, do you even have a proper IT person/team? Do you have an effective back up system in place?
Maybe you could (after making sure that the back ups can be restored in the event of disaster), trash all the source for the software (making sure that it can't be associated with you of course). When the bosses notice that the entire company is going to go under because this "software" that they don't know anything about is gone, restore the back up and make the case again...
Another option is to have the entire crew refuse to write any more software (go on strike), especially if it isn't detailed in your contract as a duty. You may even get a pay rise out of it.
So yeah, there are three options (leave, strike and sabotage). Try one, then the other, and finally the third (not in the order I present them in of course). As always, keep your CV up to date and have decent savings.
I wank in the shower.
You want something from the management and you have to convince them to give it to you. That being the case, answer these questions for yous boss:
1. WHY do you need to improve software quality? What pitfalls exist in the current design? What benefits would be accrued from a more structured design/QA process?
What metrics do you want to use to rate software quality/performance? (Management absolutely requires quantitative measurements.)
2. How will the changes affect the company (and it's employees?) How much will conforming to these standards cost? Gain?
Answer these questions and present the boss/ceo with a clear, positive solution and they should be all over it. If they think it's unnecessary or too expensive, they'll just ignore you. Sell them on the benefits of increased productivity and superior resource utilization.
... his C-level management may end up promoting him to be the software development manager. It might even include a raise.
now we need to go OSS in diesel cars
I must admit, I agree with this idea.
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.
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..
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.
*-PGP Please!-*
Plant a horribly looking but not serious bug. Then when somebody complains just say that if you had a proper development cycle none of this would've happened.
I personally hate hardware-bundled soft that can't provide data easily and in usable form for outside processing, and at the same time has inadequate analysis tools. There are plenty stand-alone data analysis applications and your clients surely have one of them already. So first thing they need from your soft is data output. Tab-separated .txt will do :)
First option, you have no job. Second option you probably end up with no job and a reputation as a troublemaker. Third option you probably end up with no job, and maybe a criminal record as well.
As you can't expect to explain this in technical terms and get it across you need another approach - more emotive and in terms the CEO can understand. Use words like "shambles" and "amateur", "skin of teeth", "matter of when not if". Then lay it on thicker with "I like working here but I can't carry on losing sleep at night worrying about what's going to crack next or how quickly I could repair it in an emergency."
Using a suitable analogy helps. For example you might ask the CEO what they'd think if the firm purchased lab equipment or reagents according to just what somebody thought was a good idea at the time without any strategy, checking of the suppliers and quality assurance of the products. Yes it really is that bad!
How long have you been out of college? How much combined experience does the management team and board of this company have? Has it occurred to you that they may know what they're doing?
Drop the "oh noes they don't do things my way". Getting a product to market under budgetary constraints is something you don't understand. You told you concerns to everyone you can. Now let everyone else do their job.
There is no such word in bioinformatics. Been there, did that, all failed. Everything is a hack and the high-level has no idea of what software or software quality is at all. All of them are scientists, none is technical or developer and barely anyone really knows what software is. Hal: there is no such thing as VP of software in bioinformatics. There is barely informatics... Thegrassyknowl: briefings works when the audience at least have a clue on what you're talking about. Bioinformatics is doomed!
Have you looked into all the processes in your business manual?
Obviously, biotech is different than software development. But there should be some similar high-level processes: I've seen similarities in nuclear power stations, trash incineration plants, and software development.
Since you are at a biotech company, you should have some sort of quality processes in place. Use those (high-level) processes and tailor them. Talk to your Quality Control and Process Management teams.
As part of the tailoring, include the tools you use (issue tracking/ticketing, source control, time tracking, etc.).
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 good to upper management, which
is always a good thing. (Just make sure to
also make your immediate management look good
as well.)
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'd advise not taking the burden of sole responsibility yourself.
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 the customer the management, the marketing team and the hardware boys. I became quite adept at software/hardware debugging (for that project at least) and all the while attempting to keep the documentation going ( which was considered a waste of time by management of all levels). The crunch came when they took an order for 30 finished units before the prototype was finished (including documentation, third party software/unit tests etc..) despite my constant protests.
I burned my self out and am now a green oak carpenter. I blame my own young naive mind. And the fact that I trusted the management to be dealing with this sort of stuff.
If you don't abide by standards and have a half decent software development work flow organized by the management you're going to be in a fire fight. Get vocal and demand it now before you become a gibbering wreck trying to keep everybody happy. And the management will keep their jobs not doing there jobs.
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.
As you understand it and others already pointed out, a serious screw up in your software may be dear. Depending on the data consumers there may be various kinds of problems, ranging from loss of money and credibility/reputation to major legal issues if somebody gets harmed or someone's property gets damaged. If your company gets caught with something serious, it's in trouble and will be liable.
Now, I don't know if that software is just for internal use or your system actually includes this software. In the latter case, if this software can be accidentally broken (e.g. a typo in the input data or something pretty trivial) or easily compromised and eventually is, you can have problems just as well.
Educate your management on this.
Finally, managing software will be much easier if it's implemented well, documented, tested and all its versions and bug information are kept in the source and bug control systems, where everything can be found by you and whoever else works with it in the future. If the code is lost or you can't reliably undo last incorrect modifications, it's pretty bad.
Take it into your hands, even if nobody gets hired to help you out with it. Set up a source control system, something for bugs and use those. Add tests for your software, little by little. Somebody will thank you for that.
Is the software a critical piece of the puzzle in that company? It doesn't seem so. If it worked until now, why fix it?
If the Software Company that I work for doesn't care about Software Quality, what hope does a Non-Software Company have?
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).
Explain in terms of managing risk is the best way to communicate to non software folks about your needs. No shortage of books on risk management and software as good starting point.
That said, you might find management is quite comfortable with the current level of risk. Most young companies have sacrificed software quality to get to market (and have been succesfull doing so).
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
If they're using in-house software to gather data from experiments, this stuff better never get seen by the FDA! There's a whole lot of rules once they're involved, and if the company can't do things like audit trails and the like, they'll get tossed out the door.
Therefore, they better put plans in place NOW to avoid a whole lotta trouble later.
I have worked in enough software companies to know that they are not necessarily better.
Turn up with a solution...
"Consider how lucky you are that life has been good to you so far. Alternatively, if life hasn't been good to you so far
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...
many companies are like that. People and software are expensive and difficult to put an exact $$$ to show a return. That's what it's about being able to show ROI. Most likly a body isn't in next years budget, so it won't happen. Like others have said, fix it yourself. You're either a solution or part of the problem.
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.
Contrary to the popular belief, there indeed is no God.
until something goes really wrong in the field and the company gets a product liability suit based on crap product. What's described here sounds like this is the inevitable future of the company if they don't fix their software development process.
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.
Tech Public Policy stuff
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 only interested in selling their particular tier, point their fingers at each other and declare, it is the other guys responsibility to get it working. It would be rather amusing if some of this stuff wasn't so critical. The latest one I have seen is some branch of the govt threw out a rfp for a rig to exhaust high heat exhaust gases from an apu in a hangar for an aircraft. Everyone in the channel is clueless including the engineer that "designed" it. It would scare you to find out who ultimately will wind up programming this thing. I have long said that computer scientists need to get outside of IT, and into engineering and fabrication for this reason. I usually just get ignored but, there is a huge need and opportunity for skilled people. The next time you see something that looks complicated and does things automatically respect it may have been programmed by a convenience store clerk. be afraid, be very afraid...
If you are manufacturing medical substances or other things that will need an FDA approval, i'd say you are in DEEP SHIT. Since you need to at every level in research, manufacoturing etc prove that you have control over everything. Have reliable qualified software and hardware etc. If you cant prove it. Youre in for a legal ride! Heard of GxP?
"Never EVER mess with a jumper you don't know about, even if it's labeled 'sex and free beer'." - Dave Haynie
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.
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.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
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.
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...
If you work for a US BioTech company which ever intends to get FDA approval for any product, all software used must be validated as per 21 CFR Part 11. Bring this to the attention of the CEO.
So you work for Applied Biosystems? Why don't you open source the rest of it and stop writing in-house code? The Human Genome Project has produced superior software for almost everything you do. As part of that project, we even wrote code to run the machine (ABI 377) better than you guys. Ya really blew it when you switched from Mac to PC anyway.
Sorry for the rant. No coffee on board yet.
I worked at a company for over nine years. We had a group of software engineers who constantly complained that they were not given time to write quality software. Strange, I worked for the same company, I wrote design documents for every project I worked on. I wrote automated tests. I followed processes of constant improvement and I reviewed the quality reports our company produced. I also added to the quality metrics our company used. They finally fired the complainers and had me rewrite their projects. Be a doer. A CEO is not responsible for software engineering quality, software engineers are.
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. 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.
-Tom
Best way to convince management is to speak in language they will understand and listen to, i.e. money.
What are the implications if there is an error in the software? e.g. for a breathalyser, it could mean false arrest/imprisonment, or for a medical device incorrect diagnosis. If the result of an incorrect reading is possible litigation, then the company needs to prove it has adequate procedures in place.
Also, its worth checking the regulations around this area, certainly in medical software there are stringent regulations for coding practises, change/version control etc etc.
reduce the quality to the subset that provides reasonnably working software.
I have some very good books about extreme programming. It strips away most of the non sense of quality to keep only what improves the quality of the produced software or reduce the workload.
Most of the principles are easy to apply and there is no cost (except for the project leader to learn the principles and the efforts to convince the management to give the freedom to apply them), only workload reduction and reliability increased.
My personnal 2c about COTS is that you know correctly a COTS only when you have used it on a project which has failed. As you are not in a software company, there is no point in using technology in the hype : try to rely on tools (and languages) that are already correctly mastered.
Talk it up with the sales shmucks so they (might) understand that a great product needs to be approved independently... no... don't drool when they believe you... let the non aprroval thing fester for a month... THEN... Suggest to your CEO that he could secure more authority (mana/clients) if he had a QA certificate from an independant source like ISO... cause (apparently) the sales guys are constantly asking for this info... 1. It removes you from the first wave of bullets. 2. It gives you the opportunity to RUN if he say's no... 3. It reveals honesty. Actually - can I have your job - easy meat : )
The CEO agrees there's an issue but doesn't fix it. Hmmm.... So maybe the CEO is a klutz - welcome to the wonderful world of work - but there's a little alarm bell ringing for me; perhaps you thought it wasn't important for a post here on /. , but in the 200 words you use to describe that you have an issue, you don't explain *at all* what the effect is on the business - how does it actually hinder what is going on? Nor do you explain how things could be better if someone did focus on software quality....
CEO's of companies change stuff if they think it will benefit the company. However they are typically generalists / or sales people who need a fair bit of help with granular issues. I've lost count of the number of times in business I've seen someone from a particular discipline explain a problem in their terms aka 'the double flange flux capacitor has under-ubered the Klutz-point interzone metapoint' which sure enough gets a nod (you've got to nod a lot when you're a CEO) but is then promptly ignored because the generalist doesn't acutally get the detrimental impact to business or possibilities for improvement. Where the specialist says 'the software is crap and the business impact is that customer complaints are high compared to the competion and 43% of clients rate it 'unintuitive' or 'difficult' compared to XYZ Competitor Co. where only 18% give the same feedback' then you'll notice the CEO sit up. If you then tell him what benefits could be got by fixing it - substantive ones, not just that the software will be better - and the cost of doing the work, then you've got a CEO that is ready to go.
Now perhaps that's what you did here already but like I say, it's a mistake I commonly see....
I would make sure I knew what was happening. They may be quietly trying to solve the problem without drawing attention to it. If they are not or it looks like their solution is going to flop I would look into starting a company that sold the software. Don't go the venture capital route you'll end up with the same mess you are in now.
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 the keys'.
Show them you can provide a better quality of software to clients than competitors.
New features will make it into your software first, then the competitor will still have to factor it into their code.
"I was in love with a beautiful blonde once, dear. She drove me to drink. It's the one thing I am indebted to her for."
cheapest bang for your buck: get source control software CVS, SVN write a coding standard document. example if{ ...
}
or
if
{ ...
}
Perform peer reviews to check for bugs and insure compliance with said standard.
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.
Actually, I wrote my thesis on life experience.
There may be software is out there already. If not then it could be a selling point that could give them a reputation.
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, or do nothing and maintain what I got. I ended up choosing the latter because the current running system works, maintaining it is just a cost of doing business. A rewrite could possibly make it better but not worth the investment in time. A great decision maker with see both sides of the issue, this is also most likely why the CEO is unconcerned.
Got Code?
I have the same problem. We are a hardware company but our hardware includes more and more embedded software. Very few people in the organization are aware of the particular requirements of software quality. I am the Director of Engineering of my division, so at least I have some level of control on processes. So, as a fix, I have tried to include software within our normal configuration control systems (we are a defense contractor, so we have pretty good configuration control). Everything is a drawing, so I have tried to modify the existing procedures such that they would cover software as well. On paper, it should work and we have been audited by customers who have found the documented processes adequate. Unfortunately, I have found (duh) that it is very hard to make people apply the rules when they are unfamiliar with the product. They understand hardware, but when it comes to software, they just drop the ball. I am not sure what else I can do at this point, until software becomes a significantly larger part of what we do.
God their software is awful
...you just discovered that "quality" is subjective, congrats!
/.ers can understand:
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 yourself what's better, vi or emacs?
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.
"In the land of the blind the one eyed man is king"
You know the problem and no one else recognized it (yet). Become the expert about every aspect of that software but don't take responsibility for it. When things start hitting the fan you'll be the hero. Let them come to you next time.
...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.
To those of us familiar with software we look at software quality a critical issue. To those of us who are not familiar all we care about is "does it work". It sounds like to date much of your ad-hoc developement has "just worked". What you need to do to convince those in your management of the importance of software quality is to show them how it will benefit the company's bottom line. I would suggest looking up different software quality processes/management systems and then putting together a sound (not exaggerated) business case that will show your management how software quality processes/management will benefit shareholders. This is not an easy thing to do as most engineers see the "obvious" benefits; but remember- these are not engineers you are working with and you need to show why a certain quality assurance process turns into $$$ at the end. It is hard work but if you can tie sound engineering principles to business benefits...you will probably end up getting a promotion ontop of just the quality control system you want. Sorry for any grammatic errors here- not enough time to proofread.
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 :)
May be, there's another (dark) side and I hope this is not your case. You may ask to yourself if there's a real desire for the company to solve this matter. I explain myself: I worked for a major reseller of a great medical products industry. There are tons of non-regular procedures (in the reseller), starting with fraud, selling outdated products, reuse of disposable surgical products, payments for doctors, nurses, administrators and others to "help for good sales". And the main managers from the industry for our region know about this. I talked with some of then and I read a lot of e-mails very explicit. Including one of then left the industry to become a happy kind of "co-proprietary" in the reseller. The result: any try to make some system work was fired, including myself (LOL). Now they got a student who do nice Excel sheets with the numbers written as they want. And until I know, the data still are exposed as anyone can find all this info in few minutes. Is a really shame. So always ask if people want to change something and see if this is something that can be attached.
Information technology means all information.
The problem is that once you have a process, it will be implemented my some person who has no idea what software is all about, and you'll end up with something that hinders you rather than helps. The best way to solve your problem is from the ground up, that way you get something that is easy to work with and solves your problems, not make new ones.
Money is the root of all evil?
I'm a QA guy turned developer. The biotech company I'm with didn't even do QA on the hardware. When I arrived and saw the situation, I just implemented standard software development procedures. I started doing documentation including requirements gathering for existing products. Did a QA pass on the hardware I was assigned to before I did any development. Turns out they like what I did and then they started following my example.
Sorry my bullshit sensor overloaded.
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.
I have the same problem with the company I am currently working for. funnily this is an online agency, but they dont seem to be able to make the step from microsite-design to systems integration based projets.
I have discussed, proposed solutions, shouted and screamed to various C-levels, and everyone agrees, but nothing changes.
I have quit now, and - as I like the company - will suggest the last option that is open to me: return with a team of external consultants and try to fix their problem for them... we ll have to see how much acceptance this will find...
The question generally is: is software delivery your core business and if not how much hunger for change does your company have?
C-level folks don't care about technical problems, only about the business consequences of those problems.
Tell them about the software defect in a GE radiation therapy machine that killed patients before it was discovered and which cost millions in compensation to GE. What would be the business consequence of a latent defect in your software?
http://courses.cs.vt.edu/~cs3604/lib/Therac_25/Therac_1.html
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 do this with ATM data and not lose a single penny, management response has been "We're the Very Large Non-Profit Organization - we're different". They finally asked the project leader to retire (God forbid they fire him for incompetence), and are valuating whether to scrap the whole thing and start fresh, a la the FAA and IRS.
And no, I haven't quit.
Yet.
"As God is my witness, I thought turkeys could fly." A. Carlson
If the company doesn't understand how to write software and the software development team/dept is run by a non-technical PM ... it will never change.
As a consultant who makes the bucks coming in and fixing disasters caused by poor software practices, I often am retained to implement better and more productive practices, in the very least, to prevent future such catastrophes.
Universally, non-technical management never quite understand 3 things:
1. This stuff is extremely difficult, esp. at an enterprise level (we all know the 'magic' paradigm) ;
2. Spending a little more at the outset to do it right saves you 10-50 times more then trying to fix it later ;
3. Some say the last one is controversial, but not to people who realize that software worth doing, should be thought about in terms of decades, not years or months:
Software development is a process, not a product.
Your better off finding a new job than trying to change a culture of 'Software as a necessary evil'.
Especially in this day and age when modern day software development practices, like those used in the open-source community, are beginning to change the way business internally communicate and function by becoming the center point of the organization/dept etc.
Software quality isn't a single thing, it emerges from a reasonable process. As a simple start, I'd recommend getting a few copies of "The Software Project Survival Guide" It's a little old, but still relevant. (http://www.microsoft.com/MSPress/books/1332.aspx)
And going through the checklist in there.
Do you have a source control system? do you have a bug tracking system? do you have a change management board?
It provides a means of incrementally improving your software process in a way that can be understood by management and will show good results. It won't fix everything immediately, that'll be a long struggle to change the culture, but it gives you a roadmap to make things incrementally better every day.
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.
There is no "-1 offended" or "-1 you don't agree with me" mod options for a reason.
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.
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 as a translator to the execs otherwise it will never happen. They would map it out in a non-confrontational time frame (say 10 - 15 years) including other drivers of the business groups in a setting that allows them to conceptualise their ideas for growth and expansion of the business. Then you work backwards from there and set markers in time that show you where you should be, until you reach the present. Only then will they have a hope of understanding.
Until the drivers of the business understand what it means to them, nothing will happen, and if you don't have a CIO that recognises this (if at all) then you are screwed. Manufacturing always has this issue and they are typically short sighed when it comes to IT so unless the stakeholders are driving it, or you can figure out how to make them, learn to live with it.
My ism, it's full of beliefs.
I work in biotech (clinical) and the problems I have observed are :-
Biotechs have to follow FDA regs (software quality in this case), which is great. But the focus tends to be on passing the regs and is seen as a burden to the business. Management need to understand that their quality system is for their business, not for passing FDA regs. A sound QA system will pass muster with the FDA. All the FDA want to know is that the software is well tested, meets requirements and the software cycle is managed (version control, change control etc)
From a clinical perspective, all the software that clinical programmers write is generally SAS reporting programs, NOT IT systems. Most people who have worked in clinical programming assume that writing an IT system is no different than writing a 100 line stand-alone reporting program. You can imaging the mess created when someone who has only written small reporting programs is asked todo real software development.
Biotechs tend to only hire (IT) people who have worked in Biotechs because of the mistaken belief that 'validation' and FDA regs are so complicated that programming is somehow more advanced and complicated than anywhere else in the software industry. Big mistake. Hiring a good IT developer with experience of using a good QA system is the only real requirement.
We are using DNA sequencing machines, electrophoresis readers, DNA microarray readers etc.. The software on average is usable but with flaws. The best software so far are from big names such as P@ckard etc.. and they do updates. Software from the new BioTech companies is very often requiring to run under Administrative permissions and they charge for updates - even to cover faults in their SW. I know no one who uses a FOSS OS for their analytical machines!
Sounds like an excellent idea - let me know how it turns out
I'm a minority race. Save your vitriol for white people.
the real world. It's obviously up to you to practice and enforce.
There was probably some 'poor performance' underlying this that was not his fault, but that could have been fixed had his reccomendations been followed. Because shit rolls downhill, he got the blame. ( It very well may be that his reccomendations implicated those who fired him in being at fault )
As for spending more time on presentations than work, he should keep it up, but only with a view to appearing in charge, and without saying anything that would actually help. Really suggesting changes that could make you enemies is not the best strategy. Just do the presentation that explains the status quo, and fill it with buzzwords. Then you will appear to be the go-to-guy. Soon you'll be manager of something.
The more time you spend on red tape the better. When that's 100% what your job is, then you'll be making the big bucks. If you spend time on doing productive labor, then that's what you will be - labor.
Spending time doing labor as opposed to composing bullshit means that while your peers are busy making powerpoint presentations, going to meetings and being visible to higher ups, solving their problems ( by sending you an email to fix something ), you are drudging away in obscurity. Nobody who matters even has a clear idea of what you do, except when something goes wrong. Then you get to explain the problem. While you're fixing it, someone else is spending the time more wisely composing a power point presentation on how to prevent this sort of problem in the future. You thank them, because if they didn't do it, you would have had to in addition to fixing the problem which already ate half your weekend.
Some of us retch at the bullshit, but we end up being the bitches of those who revel in it.
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 what is lacking in their compliance with FDA cGMP. Unfortunately, everyone from regulatory compliance down to the lowliest coder who had something to do with the products in question will share in the group spanking (been there).
I'd be shocked if they didn't already have a relationship with an auditing company--unless they're the tiniest of startups. If they do, the submitter should look through their last audit summary and see if anything has gone unaddressed, and if the scope of the audit matches the submitter's idea of the actual quality system for the product(s) in question.
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.
Just make sure you get some authority to go along with that responsibility or else you'll get royally screwed.
Here's a possible solution, but you may not like it, because it will involve quite a bit of work for you. Whether or not you do this will depend on how much you really care, and whether or not you view this as an opportunity to make an impact (which it is). I would write a point paper that discusses a comparison of doing nothing vs doing it the "right" way. Make sure you include information about best practices, increased efficiency, improved productivity, and most importantly, how it will save money. Executives really only think about one thing: money. You start throwing dollar signs around and people will pay attention. Show them how much money (real money, based on the company's actual revenue and operating costs) is spent on backtracing due to bad software development management. Then show them how much they need to invest to do it "right", along with how much more money they can save, etc, etc. Remember, everything becomes a "cost", whether its time spent by employees redoing work, faulty products returned due to bad software, along with lost opportunities because the software isn't good enough for your products to enter new markets. It's a lot of work, but armed with carefully crafted and accurate information, with a sharp recommendation, could get you noticed, might actually get the company to make the change, and you could end up a hero. If they refuse to listen, you have at least learned a ton in the process, and you have something tangible you can show to a new prospective employer about much you care about making a contribution.
Surely your company is regulated by the FDA. There are practices you should be following. Does your company not have a QA department? The FDA should be all over you about this.
I agree with 99% of your post. However I disagree that just because you are not a software dev or C level, that system software quality (or other quality issues) are not your business. If you are in HR or something like that, obviously not impacted by substandard products, then I agree stay out of it.
I can imagine many other positions in the company with a valid reason to address substandard aspects of the product. The first one I thought of is salesperson. You want features that differentiate your product to win sales, you want happy customers who will return, you don't want to be a punching bag when customers have problems with a product you sold them. You have every right to speak up about substandard system software.
There are no specs where I work. There are no written plans for the future. Devs do not know what they are doing outside of ~2 days into the future. Developers are discouraged to communicate. When changes need to be made, nobody is consulted. In other words it is a complete mess. I do not understand how anything gets done where I work, nevermind how this company makes money.
As the OP mentioned, what it comes down to is that the developer suffers quite a lot in the long term due to these practices, or lack thereof. My personal solution is to write my own specs and give them to my fellow devs. Anything that we as company should be doing for our product development I am simply doing for what I am responsible for. In fact tomorrow I have a big meeting with the powers that be along with my fellow devs. I am going to hand out my specs there in front of everyone. Hopefully it gets the ball rolling. Or at least some people thinking.
And I should mention that when I go home, I usually spend time looking for a new job.
In Italy even Software Companies don't take software quality seriously! :-)
Put together a business case showing how much money is spent on issues relating to software quality, and how much capital investment (e.g. new software and equipment) and operational expense (e.g. new staff) would be required to solve the problems. Calculate the cost savings over time, and show a positive 3-year NPV.
You might not be able to get the C-level execs to speak your language, but you can learn to speak theirs.
Basically you are screwed.
I have dealt with an extremely similar situation. If you want your company focus to move away from biotech to SQA it won't happen. What pays the bills is where the attention will stay.
Today this situation is common as more and more non-software and non-computer selling companies realize the value proposistion in moving into selling more software and more infomation as part of their core business.
The bottom line is that if you want to work in (and with) SQA you will have to work with the companies that SQA is closer to the revenue stream. It is that simple.
Follow the money!
Reasoning on IT level with non-technical folks NEVER works. What people must realize is that their action will cause them to loose money or better yet get sued and/or go to jail.
Grab a copy of Therac-25 (great articles available on the web) and drop it on desks of your bosses. If they are smart they will read it.
In case this doesn't work move to plan B; Document everything you do from now on and take hardcopies of documentation home. Inform your bosses when you need more time for testing. Give them options like: a) delivery in 5 minutes no testing b) delivery in 2 days with marginal testing c) delivery in 7 days well tested.
Sooner or later something will go terribly wrong. The moment you get slapped with subpoena these docs might be worth its weight in gold. Trust me: your bosses will have the best lawyers available and you will be sacrificed without a second tought.
I wouldn't worry. I'm sure the risk of your company ending up at the centre of a series of Therac-25-style problems is a million-to-one against.
Open source the code, provided it with your product, put up a site for it and let your users fix it for you ;)
I've been in the same boat, and I feel your pain. Here are the things that helped me: 1. Adopt a methodology, if you're doing things ad-hoc you're going to pay for it long run. Check out "Heads First Object-Oriented Analysis and Design". Their ideas are perfect for the non-software company that writes software, and it's a fast/fun read. Even if you're not working with an OO toolkit, this is still an excellent approach. 2. Learn to make accurate estimates - this is *incredibly* important. If you're not used to doing this properly, I'd reccomend "Software Estimation - Demystifying the Black Art" by Steven McConnel. If you don't have the time to read that book, grab Construx estimate and learn to use that. It's free (there may be a fee for professional use, but you can learn with it first), and while a little quirky has a pretty effective system for developing a professional/fairly accurate estimate. 3. Grab "Wiley - AntiPatterns, Refactoring Software, Architectures, and Projects in Crisis". Not only is it an interesting read, but it offers some tried and true solutions for this kind of situation. 3. When scope creep attacks, ask your boss, "What don't you want me to do?" - This little question can quite clearly illustrate the cost of pushing features on developers. It's also the reason you need accurate time estimates based on specific feature sets, so you can back it up. 4. Remember that 9 women can't make a baby in 1 month. Don't let management throw more developers at a problem unless it makes sense. Having proper abstractions helps here. 5. Remember that you and the management have the same goal, and are really on the same team. Work with them, and help them understand what's possible. So, that's my $0.02. I hope it helps, and good luck!
Sure it is! I'm having the very same problem here where i work.
;)
The questions is: How can we prove it!? If the managers are not aware of it, software quality will never be a reality.
Managers and costumers, where i work, olny care about delivery time and solution cost! So, test and inspect are two more boxes in our process. In other words: More time, more people and more cost!
We are trying to prove that it's not true! Well, it's true. But not the whole true.
Once we deliver a quality software, we'll stop spending money and time with maintenance and customer satisfaction we'll be improved (or created.. some times).
The first thing we intend to do is measure maintenance time and cost (we know that it's a lot). Once we have these numbers, we'll compare them to the cost of implementing the test software processes and show the result to our managers.
We know that it's only a small step. But it's a forward one!
Hope that works!
There is a ton of advice here, and almost all of it is good. But it all comes down to two realities -- (1) the company feels like it does not have a problem and (2) you do. So fuck 'em. If you are right, you are working on the Titanic, and they will tie you to the bow as they approach the iceberg. If you are wrong, then they will eventually fire you for it.
You may like the people and the work environment, but if either of the two points above are true, then that will change. So, use your initiative to go work for a competitor and show them how to exploit weaknesses like those at your current job. Believe me, your current employer has absolutely NO loyalty to you. They deserve no more from you. It is easier to find a job when you have a job.
I am in a nearly identical situation. My company tests products. We don't MAKE anything except data. I am in charge of collecting the data and making it available in various forms. I am also in charge of all the maintenance data for the equipment used for testing.
Basically, our only product is data.
So here's how budget meetings go:
Engineers: We need $50 MILLION this year for new testing equipment and maintenance contracts.
Management: Done.
Me: I need $30K for a couple new servers and a new drive array. I also need maybe $50K to hire a coder for 6 months to help me write software for that new $50 million in equipment.
Management: That much? I don't know if we can afford it. Can't you make do with your current servers and write the software by yourself?
Aargh.
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
Everything you've described is every "professional" software development job I've ever done. What is quality? Demming said "I can't define it but I know it when I see it" or words to that effect. IMO quality software is software that solves the problem. That includes efficiency, data integrity and maintainability (three attributes most uber-programmers I have met seemed not to be familiar with). How to solve your problem? End run management and develop your own process that works. Avoid heavy weight bureaucratic methods since they take too long and are inflexible. Avoid the waterfall. Alternately, threaten management with their exposure to liability.
putting the 'B' in LGBTQ+
...so turn it to your benefit if you can.
I've been programming and sysadmining in a large number of environments for over 20 years, and I've never worked in a place that cared about software quality in more than a perfunctory way. I've lost sleep over it, but I've never been able to make a difference in the situation.
My advice: Since it's inevitable, you may as well enjoy it. Position yourself as the knowledgeable guy that saves the day when disaster strikes. Don't point out that management caused the disaster by their dereliction--just concentrate on your rescue role.
Or, alternatively, you can seek greener pastures. Not sure there are any...
"Not an actor, but he plays one on TV."
Once bitten, twice wary.
When they finally get bitten by any lack of software control, then they will act.
This reminds me of a medical brain zapping machine that was not properly tested for all possible event problems. The problem was that when you set the machine's output power to an incorrect high setting, and then reset the setting to the proper lower setting without first going back to a zero setting, the higher setting was not actually reset. One person actually felt a burning sensation in their head and complained, but was rebuffed with assurance that it was impossible.
I used to contract to a network hardware company. The company attitude was that software folk were not engineers and didn't have a place anywhere but in the software (network management) division. I can't imagine how they kept market share with all the time lost to basic repeated errors. Every product contained a hackfest of self-taught EEs "making things work". Of course the circuitry was at least top notch. If after repeated attempts to get them to understand how valuable good software practices will be over the course of a project and into the future, maybe its time to work for a more forward-thinking company.
I have two suggestions for you:
(1) I work at a company where we have both a decently managed IT organization and business units who get to "do there own thing". A recent SQL injection attack has opened upper management's eyes that something needs to better control our software quality (in this case for external facing applications). Our tactic is now to create a security policy that is intended to force these "do there own thing" groups open the kimono and let IT review everything.
(2) If you're big enough company, you can also use your internal or external auditors to ask the right questions. If you are aware of unsafe practices like poor or missing source code control, not using a documented SDLC, un-auditable user acceptance practices, lack of DR plans, etc. - you may have audit issues to force some change.
Not the most pleasant of ways to take on the status quo, but it can be effective in getting management interested. CEO's don't like being hacked and they don't like negative audit reports going to the board either.
Jay Mumper
Simple, make it relevant. Find out where the software is failing or has failed, and translate that into dollar terms. If your company lost out on the opportunity for a discovery that they could license for $400,000 - make it known!
Spearhead an initiative to enable a culture of best practices, with the ultimate goal to be assessed as SEI CMM level 5, leveraging Digital Six Sigma to integrate continuous improvement.
<insert what="maniacal laughter">
managers, in general , view their crew as brainless peons. after all, if they had any brains, they would be managers right? so, no manager is going to listen to your 'ideas' seriously.
second of all, any attempt to fix problems is viewed as a power grab, which means you are a threat to their job security. if there was a problem, they would already have solved it or be working on it, and wouldnt have had to 'learn' about it from some peon on the staff.
third of all, nobody is going to give you a budget. you aare a 'cost center', or 'human resource', which means, you are keeping the board members from buying as many yachts as possible. dont ask for more money. do more work with the money you have already, and expect budget cuts next year. and cancel your vacation, we layed off our hr people so you need to keep track of timesheets now.
i dont know what planet you live on, but it must be nice. most of us, though, have to live on earth.
Your explanation of your product/service sounds like a medical device. Assuming that is true, your company is surely registered with the FDA and is audited by them every two years or so.
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.
to add "Dear Abbey"
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.
get the hell out of there before they blame you when something goes wrong. if all you got was lip-service from the CEO, not only will nothing be done, but you are now a "troublemaker" and a potential political target when something does go wrong.
here's what could happen: the software glitches up and causes damage/injury/death/etc. Since you were obviously aware of the potential problems and did nothing to fix them yourself, it becomes your fault.
find another job and hit the bricks brother!
Are you so sure bank ATMs have never lost a penny? I'm not. But really, as long as it's not the bank's money disappearing tracelessly it's not a major problem.
where people in the organization rise to their level of incompetence. Management, no matter how much they pay lip service to the terms open communication and employee empowerment want nothing of the sort. You went straight to the CEO about this, so where was your immediate boss while this was going on? Talking to the man upstairs might make you feel good most likely won't accomplish anything other than causing tensions in the workplace. Use this experience as a valuable lesson for another job. Learn everything you can here. Hell, take on as much responsibility and work with this as much as you can, be a highly valued employee. Don't have anyone trained to do what you can do. Then leave.
GET BACK TO WORK!
Aren't there enough bugs in your code that you shouldn't be wasting time on /.?
Or you could "accidentally" add a bug that destroys the hardware at the first run?
I just hope you aren't controlling an x-ray.
SLIDE A:
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.
I use irony whenever I can, but my shirts are still wrinkled...
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 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, then there are plenty of good options available. There is plenty of good advice here as to OSS VCS. There are various unit testing frameworks for Java, .NET, Ruby, PHP, C++, you name it. Also, check out Cruise Control for Continuous Integration.
Technology alone cannot solve quality issues, however. Changes in methodology, process, and even corporate culture may also be needed. Take a look at my site for more advice on that.
My 2005 book High-Assurance Design (website at http://www.assuredbydesign.com/haa/index.html) has a chapter (first chapter; downloadable from http://assuredbydesign.com/haa/Berg_ch01.pdf) that explains the importance of assurance in business software design.
Hi,
Congress has enacted laws required design control of biotech devices, including devices that contain software. Specifically Code of Federal Regulation 820.30 details the need for design verification (i.e. verification testing to show that the system is functioning correctly). Further any non-product software used in the company is subject to design validation per federal law as well. Without full design controls in place the FDA will (upon their next audit) discontinue your approval to sell medical devices until such a time as you have enacted design control and they have been audited to be effective.
Good luck - I'd suggest calling the whistle blower hotline if upper management won't listen. You are directly responsible for results that are used in patient treatment. If nothing else think of your end patients. An incorrect result could lead to harm or even death (depending on what your assay activity your system performs). This line of work is not a joke - if you kill someone with your device you will have to live with it for the rest of your life. The FDA is the voice of the consumer - not just some overbearing government agency sticking it's nose in other people's business. They are there for a reason and you should respect it.
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, which we'd need to do if we're part of a clinical trial.
My company recently went through something very similar. The company started out very hardware-oriented, so the management didn't understand software. They bought out the rights to some software from an independent development team and then proceeded to pay them large sums of money for contract support. The software was developed poorly to begin with (and the developers probably sold it because they knew it was buggy and wouldn't scale).
Honestly, I'm not coving the half of this WTF-worthy situation. To sum it up, management thought it was buying off-the-shelf software and had no concept of what is involved in software or how to make the transition to internal developers.
THE SOLUTION:
We hired a team of extremely tech-savvy consultants. This was looked at by some with tilted eyebrows because we where basically hiring contractors to fix our contractor problem. However, it was actually the best thing that could have happened. For one thing, something weird about management is that they trust consultants more then their own employees. These guys brought the extra skills and resources required to show why they should be paid money to fix our buggy software and why it's important to have good development practices. They helped us hire some good full-time employees and gave us a start at a real software department.
I work for a large biotech's regulatory department, and my job is to ensure we remain compliant with federal regulations vis a vis software development.
I want to underscore something that electroniceric touched upon: You work in a regulated industry, and your firm's practices are not compliant with federal regulations.
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.
So whaddaya expect for nuttin'?
From a technology perspective, a Version Control System, Test Driven Development, and Continuous Integration can go a long way towards improving quality.
Pretty much agree...
Y'know, "make world" running in a loop on a dedicated build server (or ten), the whole shebang sucked out of the revision control system and built. Configs, testing, boot on the production hardware and testing on that hardware. Queue a new build with whenever someone updates the code. Fail the build if the automated tests fail.
Then at the end of each build you have a single complete system with a version number, which either works or it doesn't. If not, it will always fail in the same way.
You're doing two things. You're taking people out of the build loop so the software production process is consistent and repeatable, and you're taking people out of the build loop, reducing costs, improving productivity, they can actually do what they are paid to do.
What's required? make, svn, while true.
Deleted
If they're publicly traded and the software is critical to their business, the independent accountants should have already taken this problem to the Audit Committee (Board of Directors) as an internal control deficiency of some sort. They should be following COSO or COBIT and have a well-documented and robust software development life cycle in place. Not doing so could mean a finding of a material weakness in their internal controls (Sarbanes-Oxley), which investors dislike. That sort of thing is chum in the water for lawyers.
To me, the interesting question is why they are continuing to ignore the problem. See if you can find out whether they've been warned already. In my experience, the companies that blow off this kind of thing tend to be small, and even though they are publicly traded, the founders or other insiders still hold large stakes in the company. If that is the case here, and the "owners" (they always tend to think of themselves that way) don't want to bother, there is no hope of getting it fixed. Keep that resume up to date.
I'm in a similar predicament at a research firm. We write software to do our research, and sell the same software to other researchers. We have one trained software developer who is relegated to a non-lead position and gets yanked on and off tasks constantly trying to clean up mistakes made by a bunch of ######## who were all "taught" to program by another ######## who "taught" himself to program in Turbo Pascal over 20 years ago. Any problems can never be attributed to his work, even if it is obvious that his changes caused the problems. So we play a constant blame game. Programmers meetings consist of Mr. Big explaining his vision at great length and in language beyond the understanding of most mortals (really), followed by a short intense period of blamethrowing and public ridicule.
To make things worse, large sections of our codebase were written by ex-employees, and the proper use of comments was never a high priority. Copy and Paste has been the leading technique rather than encapsulation and inheritance.
Our code is so twisted that much of it no one understands, but "it has to be left alone because we don't want to break anything" (else). "If it works, I don't care how, as long as it doesn't break anything."
We use VSS (unfortunately) in the most bizarre and pointlessly complex ways that our "source control" is similar to running around in the middle of a busy highway with a flyswatter expecting to live a long and healthy life.
Even a simple rule like: "Don't set a release date before reviewing requirements and specifications" is wasted on these people.
Some days I want to kill.
(I'm not a "trained" developer either, but I've been doing it right (or trying to) for almost 30 years. =)
Not to be flip, but why do you care? Are you worried about covering your ass (legitimate concern) or are you just whining because no one will recognize how smart you are (if so, grow up). What is the nature of the risk that the 'bad software' is introducing? There are 2 possibilities:
1) You're afraid that it will break and you'll get blamed, even though the fault lies with the overall testing policy. This is a legitimate worry. I would recommend documenting your concerns and making it clear that the risk exists and that it's company's responsibility for not addressing it.
2) You're afraid that a software bug will hurt your company's competitiveness enough to depress the value of your options. You need to really think about this and decide if that's a reasonable fear - if it is, a competent management team will take appropriate action. If they don't then that means you're not working for a competent company - leave and get a better job if you can. If you can't, then accept the fact that you're at your level.
If, on the other hand, you're simply bucking for promotion because you're the only one smart enough to see the mess - well, that's a different issue. That's a corporate political issue, and no one here can advise you on that without knowing your company.
I worked as a software engineer for one of Alcan Aluminum's hot mills for about 5 years. Our little group of 4 software engineers built systems for internal use, just like you do. We were heavily involved in process control, data collection/dissemination, and adaptive tuning. This stuff is the heart and soul of your competitive advantage - it differentiates you from your competitors. Doing it better (higher quality) usually translates into superior competitive advantage. That would be my sales pitch, were it mine to make.
Sadly, our boss turned to the dark side, eventually saying things like "We're an aluminum company, not a software company". If this happens, leave. Alcan subsequently when on a packaged software buying spree. The result? Anyone who can pay the price of admission can buy packaged software, and that levels the playing field. Say goodbye to competitive advantage.
- The Kessel run is for nerf herders. I can circumnavigate the entire Central Finite Curve in a lot less than 12 parse
So you've spotted a critical part of what makes the business tick. They want you!
My definition of a Software-Intensive Business is one that
Many otherwise-competent managers and executives of SIBs just don't appreciate that software is different. How could they?
There's been a lot of good advice. If I had to summarize, it would be:
Most managers and executives I've met are trying to do a good job (even if it is only to get that next promotion). But without a good software background, they just might not even know that things could be different than they are now.
Good luck. This is the main emphasis of my consulting business, uFunctional LLC, and it can be frustrating.
Robert T. Merrill, Madison, WI. Trustworthy, competent help with your software-intensive business.
I've noticed in almost every industry that I've worked in that it always has to get worse before it gets better. I'll use the example of washing dishes (which I've done). When working with another person in the dish room both people need to do their part. If either one fails to do this it pressures the other person to work harder to keep up. This has the effect of driving the hard worker to the breaking point. But if said hard worker begins to slow down and work at the pace of the slacker this will make the situation worse (in the minds of the manager). At this point the manager would usually come back and bust chops about going faster or whatever. Thus the situation had to get worse before it got better. For my part my manager knew I was a hard worker and could probably run the dish room by myself (which I had done on a football Saturday) so he didn't particularly blame me. Had he been more aware of the situation I wouldn't have had to slow down the process until someone noticed. My point is until it is clear that the system is broken to people who are not aware they won't move to change it in any hurry. Your best bet is to make clear and concise documentation of the failure of the process and your reasoning for it. Suggest a feasible alternative with justification for the cost. In your case shipping your product with a serious defect in the software could be catastrophe that could easily cost your company 3 times the amount the out side developer with commercial experience would have. This comes down to your presentation, you are basically trying to sell your idea to someone higher up. If you can get them on your side, then you can move higher up the chain with their support. Starting at the top of the chain may not have been the best approach. The other approach that you could take is intentionally breaking the system in the same way that I "broke" the dish room. This would likely get you fired, but the reaction time and solution would be much faster. Also by documenting all of this and passing in on to your supervisor you put the burden on their shoulders should this problem ever come to light and they come looking for someone to blame.
IMAGE VERIFICATION IS EVIL!
Yeah. Fighting for correct testing and quality controls in a company that does nothing BUT release software is hard enough. If your boss is convinced that they sell hardware -- or worse, "complete systems" -- good luck trying to convince them that the little daemon of software is actually the one controlling the show.
Sorry to discourage you, but if you do push for quality, and not just follow the leader, expect to get fired at least a few times before you see any benefit.
I'm speaking an engineer at a software company that has no release process, no Q/A, and releases binaries directly to clients through network back-doors every day. Its not good, but unfortunately, its not rare. Buck up.
-dave
6th Street Radio @ddombrowsky
Quit, buy some shares and speak up at a stockholder meeting.
Actually, since this is a Biotech company, QA definitely needs to keep tight controls, since they will need to ensure that it stays within its "validated" state. If it doesn't and the product is used or sold, there are some very serious reprocusions from the FDA. Take a look at the ISPE web site for software development and validation. Good luck...
Look into something like Team Foundation Server with ScrumForTeamSystems. This assumes a lot, but it's what we do at my work and it does nicely. :)
For over five years, I worked for an international biotech company that has been around for over 150 years. My title was "Senior X Engineer", where X varied from Software to Bioinformatics. I had specializations in genetics and statistics. I have been where you are. And I was not able to get my company to wake up, either. You have already talked with the CEO. The CEO has listened, and he told you that he has bigger things to worry about. That is the final answer. Things will not change at your company. I strongly advise you: update your resume, and find another place that cares about quality. Because poor quality software will be discovered. The managers will actively seek someone to blame. And because you complained, those same managers are likely to blame you for the bad quality. No, it's not fair. It happens anyway. I'm serious: you are on a sinking ship, and you will be the first one blamed. Update your resume, find a new job while you're getting your current paycheck, and switch. Good luck.
Never play leapfrog with a unicorn. Or a juggernaut.
I agree with the previous commenters that it's important to have a solution or plan before raising the alarm. Having said that, once you raise the alarm and you're not being heard to your satisfication, there are several options available: * First, clear your mind of what you think you know about software development and what SHOULD be and try to see the situation from an open-minded perspective. Are the issues you're seeing really an indicator of poor quality or are they an indicator of a system that's different from what you know/like? As a quality/regulatory person myself, I've seen many unnecessary projects and alarm bells simply because of a lack of understanding/perspective on a given topic. I'm not saying that's the case with you, just that this is the kind of issue that's good to be absolutely clear with yourself about. * Once you're clear that there is in fact an issue, go to QA and request an internal audit on your software development/quality systems. If your QA team doesn't have a procedure by which you can request an audit, then you should find a QA partner who can work with you on this. It's good to have a QA partner anyway so building the bridge on this project won't be a waste of time regardless of the outcome. * If auditing isn't an option, or if you need ammo to sell the audit idea, another approach is to analyze deviation and/or CAPA trends on your software development process, as well as your validation process. For example, try to find out how many validation deviations are being generated when new/updated software is released from your development team. Working with QA, you could develop an estimated cost-per-deviation, which would be a huge pile of ammo for your management presentation. Also, pretty charts and graphs will help too. * Find other tangible evidence of the issue. Without specific examples it will be difficult to be clear about the problem and/or the solution(s). * If you find evidence and QA and/or management still won't listen, it's time to consider your options. You can either stay, knowing that a ticking time-bomb exists, or you should carefully plan and execute your exit from the company. My litmus test for working at a company is to regularly ask myself whether I'd give my company's medicine to a family-member [a family member I love :P ]. If the answer is no, I don't stick around. So far, I've only had to do that once in 10 years and it was absolutely the right choice. Good luck!
If the company can't afford to hire a full-time to work on the software, hire some graduate interns to work on it over the summer. Find those who had done programming work before.
Better still, find those who already had one degree in CS / Bio and is working toward the other. Be sure to ask for the Prof's phone number or email, and be d___ sure give the Prof a call ... (1) a phone call is free (2) you can advertise to the Prof (3) If the applying intern dares to give you the Prof's contact I guess it'd be okay
Even better, open source it.
Gotcha. CEOs don't like open-source. Why? Competitive Advantage (or at least that's how they think). If our competitors got hold of our software, we lose our competitive advantage. Once the CEO buys into this idea, explain that competitive advantage doesn't come free. It takes money to maintain. If not, one day it will become a competitive dis-advantage.
If it's not possible to spend a buck on software, then - KISS (keep it simple, ______). Matlab, Python, Labview, etc. Find something simple enough that a dozen of your coworkers at least can understand, and still powerful enough to run your instruments.
Just don't use MS-DOS 8)
There are several little things I will say that will assist you to solve this problem.
1.At this point, there is no compelling reason for the company to add software quality testing to their product development process. This sort of thing will remain unimportant to the company until something bad happens. At that point, they will do something about it or face potentially huge problems.
2.A slightly different perspective is that this scenario is just like the sales process. If there is no compelling event, then there is no reason to buy what you are selling. You need to understand the motivations of the company and what might make him buy. You then need to present this as a problem that you can solve, and why it needs to be solved. You create the compelling event.
3.Part of the problem you have is that there is no understanding of what software quality is and why it needs to be done (risk mitigation). Your boss need educating.
4. Ask a simple question... what happens if something bad happens whilst using your products (hardware and software) and the result is related to bugs or errors in the software?
The impact is to....
-a company
-individual/s
-whoever uses (directly or indirectly) your products
-whoever is indirectly or directly associated with your company
Usually the shrinkwrap licenses on most commercial software cover these kinds of problems by saying (roughly put) "although we do our best to make sure this product works correctly, when you open this package anything that happens is your own problem". Again, this is really risk mitigation, however, you need to be seen to at least make the effort to ensure your product does exactly what it is supposed to do, and testing it would provide that assurance.
If you didnt test it, then your license contract may not work in a court of law.
Its all about risk mitigation. You might find you have a risk department. Go talk to them about it. It might help your cause.
Bloomy! (been in the software testing world for 10 years.)
You are discribing the usual problem customers of non-software companys forced to use this software have to deal with. We've been through this many times in our lab.
If there is a eternal bad-software-is-written-by-list it should start like this (worst to best)
1. manufacturer of scientific devices (esp. software needed to gather the results from such devices. or even better: real-time. or best: controlling said devices, too)
2. school book publisher releasing learning software (even if it is usable, even if it has the potential to explain $science to the kids, from a sysadmin's view this software will be hell)
3. your ordinary scientist, who feels he is called to write that crumpy piece of software that from now on will be the CMS of you department, producing not only your ordinary security hole, but your ordinary general purpose r/w interface to the department's IT infrastructure.
4. hardware manufacturer producing integrated controllers for the automotive industry. If they'd at least know how to spell 'secure' or 'tamper resistant'. But well, I enjoy my car being hackable
The MOST important department (money makers) must ask for it, an it will be implemented very fast with big budget. So work on those people, and if they get to need it very badly .....
If the cost of your software development is low
and can be easily tested, i.e. no end-user creativity is allowed, then software quality really does not mean much. Software assurance is the big player here.
i.e.
A poorly designed but well documented and well tested system can easily be more desirable than
an (expensive) well designed project. I have yet to see an inexpensive well designed project.
The answer is, if management really could not care then there is little you can do unless you become boss and either save the company a lot or cost them a lot.
Tell the company you can save them "X" dollars per year by doing "Y".
Then follow through. The proof will be in the
puddle.
Great post,
There are numerous advantages of commercial software in your home based business. This is especially true if you experiment with trial ware, demo ware, and even shareware. When you own and operate a home based business, every single minute counts. It is important to find resources that can assist you in time management, preserving energy, and increasing your overall productivity and efficiency. It may take several tries before you are able to find a shareware or other type of software program that you like, but once you find it, you are sure to be glad that you did! Here, you will learn about some of the advantages of commercial software in your home based business.
Free Software Directory