Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Software Quality In a Non-Software Company?

kdawson posted about 6 years ago | from the tail-that-wags-the-dog dept.

Software 308

Nicros writes "I work for a publicly traded biotech company that happens to write software that is, in fact, kind of critical for the business — without it no data would ever be read from our instruments, and no analyses would be performed on that data. The problem is that as a 'biotech' company, we are not taking software quality seriously. We have no senior management with any history of commercial software development — our C level has really no clue whatsoever what software really is, much less what is going on in software development. All of our quality processes are related to manufacturing our system (not software), so we are constantly forced into ad-hoc development since there is no real process for our development. Repeated requests to hire someone with some real commercial software development experience have gone unanswered. I have been to the CEO directly one-on-one and although he agreed this was an issue, thanked me, and said he would look into it, that was the end of it. He has bigger things to worry about. So the question: Is this just a fact of life and I need to deal the best I can? What else can I do to get some attention on software quality in the company?"

cancel ×


Sorry! There are no comments related to the filter you selected.

Practice What You Preach (5, Insightful)

ilovegeorgebush (923173) | about 6 years ago | (#24748971)

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?

Re:Practice What You Preach (-1, Troll)

Anonymous Coward | about 6 years ago | (#24749403)

Last night I had a dream about fucking one of my coworkers. However, she's married (no problem) and 7-8 months preggo. (PILF?) Is it better to get some of that ass now or wait a couple months?

Re:Practice What You Preach (3, Informative)

Z00L00K (682162) | about 6 years ago | (#24749599)

A version control system is critical to have, and to document what your processes are when developing software is the second part of the process.

Impose a coding standard where some outlines for coding style is provided, but more for the sake of how to maintain the code quality. Compiler warnings shall be at an absolute minimum, utilization of compiler safeguards shall be used whenever possible. Enforcing "Option Explicit" in VB for example.

For version control - go for a simple solution like CVS or SVN. SourceSafe isn't really safe... It has a tendency to drop files if the area where you check in files on suffers from a full disk.

But there is no support at all from management when it comes to safe software development it may be time to drop the issue and say that "we need to buy some software here" and hire a consultant company for that. Then it starts to get expensive and wrong unless you get the right people...

Last option is to leave ship and leave the sources in an unstructured order without any useful documentation. Then wait and see if someone comes back asking you politely for help. If you aren't alone bring your coworkers with you too. There are always companies looking for people with skills.

Re:Practice What You Preach (1)

Dr_Barnowl (709838) | about 6 years ago | (#24749717)

I'd not adopt CVS these days, or SVN.

I'd advocate Bazaar ; it's faster than SVN and supports more workflows, and it's branch/merge support is a full generation beyond SVN. Feature and bugfix branches are a "good practice" that is far more costly to use when your tooling doesn't support it adequately.

If your language has one, get a *Unit testing framework and start to write tests for it. When you encounter a bug, write a test that exposes it before you fix it. When you need a new feature, write the tests for it first ; they can really clarify what the requirements are.

When you have tests, you can change things with less fear of breakage, because you have the tests to verify whether you did or not.

Re:Practice What You Preach (5, Informative)

Syberz (1170343) | about 6 years ago | (#24749673)

I also work for a biotech but we're lucky enough to have a CEO who's a computer scientist so he knew the importance of IT. As such we have a rather larger IT dept which includes a software development team.

In order to show the bossesses that proper software maintenance/creation/validation procedures are important just explain what would the FDA or some other regulatory agency do to your collective bung holes if they were to probe deeper into your practices.

Mission critical data being handled by non-validated/non-documented software is just like having untrained people working with samples in the lab, it's a big no-no.

You need paperwork that supports your claim, start with all the areas where un-validated software is used, then add to that a second section explaining the cost of poorly planned development iterations. We work using monthly iterations and when we told the people responsible for the software in the field that an iteration cost about 30 000$ just in labor costs they started paying attention and making the lists of demands count, i.e. removing the superflueous demands (ex: "it would look nicer in blue" was replaced with "The standard deviation calculation should be done with X+1, not just X.")

Anarchy is an opportunity (5, Insightful)

Hal_Porter (817932) | about 6 years ago | (#24748979)

It sounds like in your company there is no one doing this job. You've talked to the CEO. Get him to make you VP of software and tell him you'll solve the problem if he gives you responsibility.

Anarchy is an opportunity for the ambitious and unprincipled. Take it and make yourself software Czar.

Re:Anarchy is an opportunity (5, Insightful)

pieterh (196118) | about 6 years ago | (#24749087)

Agreed. Don't raise issues for other people to solve, you are just labeling yourself a trouble maker. Raise issues, attach costs to them, and then present yourself as the person with solutions, and ask for budget to solve them. Make a proposal with figures, planning, clear savings, and get approval. Then hire and build a competent team and/or find a good subcontractor. Use open source where possible to save costs. Report your progress and ensure you get budget every year.

Think of ways to turn a profit from the software. Maybe it can be licensed to other firms? If you can earn revenue you will suddenly become much more valuable.

Problem is: you will stop coding and become a manager. But if you do a good job, you can get power in the firm.

If you present a good plan that will solve real problems for the company, and you are not given the green light, then look for another job. If/when things go bad, they won't thank you for it.

Re:Anarchy is an opportunity (0, Redundant)

zwei2stein (782480) | about 6 years ago | (#24749337)


Define problem (your product is useless brick without software), show where it would cost your company dearly (someone using your equipment suing your ass off when they make critical business decidion based obn results from your faulty equipment), come up with two alternative solutions. (good internal practices, opensourcing, hirinig third party company)

Make power point presentation, call everyone you can on meeting and present it. Scare higherups to action. Make sure you don't blame anyone for this problem. Make sure you don't threaten anyone's position with solutions.

Re:Anarchy is an opportunity (3, Insightful)

houghi (78078) | about 6 years ago | (#24749465)

Also do not forget to get some customer input. It will be extremely hard to change anything if your customers are perfectly happy with what you have. For you it might be bad, but perhaps for the customer it is 'good enough'.

Doing the manager thing and figuring out the numbers might even lead you to the fact that changing things would cost more, while not gaining extra income or saving anything.

So it could be that it is just a 'nice to have' and not a 'need'. You will need to prove it makes money, otherwise they will not do it.

'Making money' can also mean that your customers will be happier, or they will call you less, saving money, because you can do other things. It can also happier customers, which might be important if you measure customer satisfaction.

Basically you need to sell the idea and the company needs to buy the idea. If you can agree on a price where both parties gain in the deal, then it is good. If one of the parties does not gain anything, then it is a no-go.

This is true for every change in whatever it is you want to change. From the color of the toilet paper to the closing of a factory.

Re:Anarchy is an opportunity (4, Informative)

antifoidulus (807088) | about 6 years ago | (#24749671)

Going to the customers would be a huge mistake in this case, it seems the software is supposed to be "invisible" to the end user, so going to the end user and saying, "Hey, you know that software that runs on the expensive piece of equipment we sold you, well underneath the covers its crap and I need to convince the CEO of that" is probably a bad idea. Plus, the customer probably doesn't care as long as the stuff works. You can get poorly written code to work, but the huge amount of manpower it takes to maintain bad code will come back to bit the company in the ass.

Re:Anarchy is an opportunity (1)

houghi (78078) | about 6 years ago | (#24749797)

If you do it that way, you are indeed an idiot. If however you happen to ask whether people are happy with what they have or have mails that say otherwise, then you can use that. If you know that the customer has no clue (although some might) then don't go there.

Possible you can have a track record of bugs reported by customers. It does not even have to be bugs. It could be that they were unhappy that they needed to wait for an update. It all depends on what needs to be improved. Does the badly written code cause crashes and customer frustration and people not buying the product or is it that one coder uses 3 spaces as standard indent and the other 4 and that makes it 'look ugly'. Or is it just that they only hear in the last minute that a change needs to be done and that thus not so much the coding is a problem, but the chain of command and they should be put in the loop instead of outside it.

What you need to do is use what you have available. If you have relevant customer information available, use it. It is whom they want to get money from and that is whom they will be listening to. The main point is to understand that customers can be a great leverage tool to get things done.

Almost every manager gets a woody when they hear 'customer satisfaction will increase' without you needing them to tell how much it will cost or gain.

Re:Anarchy is an opportunity (5, Insightful)

southpolesammy (150094) | about 6 years ago | (#24749311)

Careful what you wish for though....

The flip side of becoming a point of authority in an environment as this is that if/when code defects bubble to the surface on your watch that result in a major hit to the company's bottom line, you may need to have a thick layer of asbestos underwear on in order to prevent the blame game from claiming you as a victim.

Right now, you've identified the problem for your mgmt and have suggested solutions, but you're not yet responsible for the implementation of those solutions. Becoming the VP of such an org not only makes you responsible for the fixes, but also directly accountable, possibly including from a legal standpoint. In other words, you'd better hope that the bugs in your software don't have the potential to cause medical or financial harm to your customers.

Re:Anarchy is an opportunity (4, Insightful)

kitgerrits (1034262) | about 6 years ago | (#24749583)

If you want to keep yourself safe, document and report all 'blind spots' in your method.
Make sure you present an overview of what you can control and what you cannot control.

If management does not agree with a certain blind spot, show them the resources required to cover that blind spot.

You cannot have bug-free code without strict rules and a literally astronomical budget. (and even NASA has had a few bugs)
What you can do is prevent embarassing/dangerous bug from making it into 'production software'.

Re:Anarchy is an opportunity (3, Interesting)

nahdude812 (88157) | about 6 years ago | (#24749609)

Excellent point, if you present yourself as the man with the solutions, and especially if they promote you as such, you're going to be taking the heat when things do not go perfectly.

The thing about rigid development and testing processes is that they delay releases. You can do featureful but buggy from-the-hip releases rapidly, or you can do rock solid heavily tested releases very slowly.

It's the old speed, quality, cost diumverate. Sounds like today they're choosing speed and cost, and quality is there only because your product isn't yet so mature that regression bugs aren't common.

Companies starting a development methodology need time to adjust to the reduced agility that these require. It's best to work your way into it.

Start with introducing source control and some formal testing, along with build releases. It's not very likely that they're going to reject you on these things as their benefits are fairly clear and they shouldn't have that much impact on your bottom line. Create a branch per release, and suggest that the software not be released to manufacturing until that release passes formal testing.

Later you can introduce things like regression testing and a proper software development lifecycle.

You have to be careful how you present it. Make sure they're aware that you're easing the company into a larger methodology, and until fully implemented there's still going to be gaps for bugs to fit through. Explain that during this process you'll be performing gap analysis on each bug that does appear, identifying how it got through testing, and adjusting the process as necessary to ensure that such a thing is less likely in the future.

You don't want to present it as a silver bullet out the gate, you want to be sure to explain that it's iterative and the objective isn't immediate perfection but continual quality increase. Even if you have 30 years of software development lifecycle managerial experience, you can't convert a company to a full-blown lifecycle overnight, and depending on how a company works and what its needs are, lifecycles will in fact differ a bit from company to company. Even if a perfect lifecycle existed, you still need to give people time to get accustomed to it, so you can't just throw the switch over night or everything comes to a halt.

Re:Anarchy is an opportunity (0)

Anonymous Coward | about 6 years ago | (#24749779)

Diumverate? What's that? I think you mean this [] .

Re:Anarchy is an opportunity (2, Insightful)

Hal_Porter (817932) | about 6 years ago | (#24749725)

Careful what you wish for though....

The flip side of becoming a point of authority in an environment as this is that if/when code defects bubble to the surface on your watch that result in a major hit to the company's bottom line, you may need to have a thick layer of asbestos underwear on in order to prevent the blame game from claiming you as a victim.

I am not familiar with your capitalist system.

I was thinking of Stalin, a great Russian leader. Stalin saw several problems in Russia and approached Lenin (like a CEO). Stalin amassed political power while Lenin was alive and then replaced him once he died.

If people start to blame you, I would recommend (based on Stalin's methods) that you conduct a witch hunt for saboteurs and spies. Also make sure everyone is too busy imposing the new working methods to stir up much trouble.

Additionally make sure the CEO gives you control of building security and announce a period of special measures. During this rather than a disciplinary process followed by dismissal, enemies of the new working methods will be summarily shot by security and buried outside under the flowerbeds.

I would recommend ordering building security to uncover several plots against CEO and then put them down brutally as an excuse for Special Measures to be announced.

Re:Anarchy is an opportunity (2, Interesting)

Adam Hazzlebank (970369) | about 6 years ago | (#24749351)

It sounds like in your company there is no one doing this job. You've talked to the CEO. Get him to make you VP of software and tell him you'll solve the problem if he gives you responsibility.

Management may be doing its job perfectly well! This could quite possibly be R&D code that was hacked together by scientists with no formal training in programming (most likely Biologists). The R&D code then found it's way in to production (because they needed to get something out the door).

The software is good enough to get the device working, and it's the performance of the device that makes the company money, the software just has to work ``well enough'' the device is where the money is made.

Management maybe planning to hire a new development team to develop production software. Or they may realise that the current device isn't going to be in market long enough to warrant developing production style software. As I've mentioned in my other comment, I think the best solution here is to open source the software, it's the way to biotech industry is moving anyway and it will help you with you're software engineering problems.

Re:Anarchy is an opportunity (1)

umghhh (965931) | about 6 years ago | (#24749549)

I am not advocating fully blown production system and project management, however chaos and lack of documentation 'because this is one off tool we will not be using anywhere else' is likely to be costly if things go wrong, author is sick or left company and deadline is pressing.

Then again this all depends on the size and importance of particular software. You need not document every software fart people write to get some one-off calculation/result fast.
For drivers and such I would keep a copy and care for documentation. This does not cost too much and any brain owner would do it for bigger pieces of software anyway. If you need more you can then easily expand your system. You can expand chaos too of course. Choice is yours.

Re:Anarchy is an opportunity (1)

YeeHaW_Jelte (451855) | about 6 years ago | (#24749447)

This is a good idea, but ... ... make damn sure you have all the decision making power to be able to take on the task you're making yourself responsible for.

E.g. you can blabber all you like about code quality and procedures, but if your department is understaffed you will not be able to do anything about it.

Also, if someone dictates deadlines for the completion of parts of the software, and you have no influence on these deadlines, you're f**cked too.

Make sure you're not setting yourself up for failure ... really, I've been there and it's not a pretty place to be.

learn to let go (1, Insightful)

Anonymous Coward | about 6 years ago | (#24748989)

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!

Hey, I used to work for a place like that, it was (0)

Anonymous Coward | about 6 years ago | (#24748991)

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.

Opinion from the outside? (5, Insightful)

DerCed (155038) | about 6 years ago | (#24749003)

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?

What does management has to do with it? (-1, Troll)

Anonymous Coward | about 6 years ago | (#24749005)

I don't get it, do you need management to get yourself to do a better job (produce higher quality programmes)? Or is it perhaps that you want management to get the other lousy programmers to follow you into higher quality?

I have the same problem (4, Insightful)

_Shad0w_ (127912) | about 6 years ago | (#24749009)

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.

Re:I have the same problem (1)

Timothy Brownawell (627747) | about 6 years ago | (#24749781)

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.

Was the source control something you pushed for? If so, would presenting it as something like "worked to define development standards" help?

Throw the ball (1)

tandiond (1134803) | about 6 years ago | (#24749027)

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??

As a C-Level for a Software company (5, Informative)

thegrassyknowl (762218) | about 6 years ago | (#24749045)

Prepare a brief for the management-level at your company. Show them basic tools for managing software quality. Dig up documents that show different ways of improving software quality. Talk about development methods (agile, etc).

Tools like Redmine are very pretty and manager-friendly (and free). Show them how easy it is to add tickets, approve and deny work, track changes to the software as it evolves and isolate changes until they are tested properly.

Point out that there is a potential legal minefield if they get something wrong and it's proved to be the software at fault. Show them that tracking each and every change along with who authorised it, who did the work, who approved the changed software to run, etc will help lift some of that liability.

Managers aren't all clueless, and all ones that I know are genuinely willing to do things better. Often they are too caught up in doing things to appease the board that they don't have time to look at things that seem menial to them.

If you don't prepare a brief and suggest a really good solution or two they'll eventuall get a contractor in who will charge a fortune, tell them that everything sucks and then leave. Then you'll be stuck with a half-arsed process based on some pie in the sky ideas from a contractor who really can't know the day to day ins and outs of what you do.

At the end of the day what you need to demonstrate is that by putting a process in place and then tools/staff to support it you'll be able to achieve better results.

If he does this ... (2, Informative)

Skapare (16644) | about 6 years ago | (#24749097)

... his C-level management may end up promoting him to be the software development manager. It might even include a raise.

Re:If he does this ... (1)

allcar (1111567) | about 6 years ago | (#24749533)

Be careful. Before you know it, you'll be quality manager, configuration manager and development manager and pretty soon you'll have no time to cut any code at all.
It's all very well getting a raise, but not if it takes you out of a job you enjoy to a job you loath.

Re:As a C-Level for a Software company (4, Informative)

grey1 (103890) | about 6 years ago | (#24749611)

All the folks who have suggested coming up with solutions not problems have got at least part of the answer.

I've spent a few years working with a team that has moved from being a bunch of individuals who just make changes to the code ("highly skilled desperados"), to a team where there is:

  • a clear defect/issue/bug tracking system (was ClearQuest, now it's bugzilla - "no changes without a defect" was the mantra)
  • a clear and strong change control mechanism/board
  • good source code control (was ClearCase, now it's svn)
  • an automated build process (instead of the hand-tagged, oops, missed a vital file, let's try it again, process of the past)
  • clear regression tests and good testing of new features or bug fixes
  • good visibility of strategy and the reasons for change

All of this has helped improve software "quality".

And it's in an R&D environment, i.e. it's internally written software to support teams of research scientists and their data and instruments.

We now feel we have reasonable control of changes we make - we know why we want them, and what they are likely to impact. It's much better than when we started - 3 months of firefighting, just trying to keep the software system afloat.

Suggest some or all of the above. Try to quantify the costs, or at least the risks, associated with leaving things as they are. Talk to whoever is the CIO or equivalent. Find the highest-ranking person in the company who understands software and sell the problem and solution to them.

Other angles to try - see who you could get to give a talk at your site on software quality etc. Can you tap into a professional body - like the BCS in the UK?

Good luck!

Email everyone (-1, Troll)

Anonymous Coward | about 6 years ago | (#24749053)

A picture of goatse [] .

Re:Email everyone (0)

Anonymous Coward | about 6 years ago | (#24749119)

I must admit, I agree with this idea.

Re:Email everyone (1)

Vectronic (1221470) | about 6 years ago | (#24749443)

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...

Dont worry.. It will solve itself. (0)

Anonymous Coward | about 6 years ago | (#24749063)

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.


Steal all the computers and skip the country... (0, Troll)

apathy maybe (922212) | about 6 years ago | (#24749067)

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.

Re:Steal all the computers and skip the country... (1)

BotnetZombie (1174935) | about 6 years ago | (#24749115)

Don't listen to that, strike and sabotage may very well result in you being fired.
I'd much rather take the advice seen above - there is clearly a void in the company, with no-one taking good care of software development. Step up, and make yourself an obvious choice for that role.

Re:Steal all the computers and skip the country... (1)

apathy maybe (922212) | about 6 years ago | (#24749181)

Keep your CV up to date and have decent savings.

My reading was that the person isn't so happy with the situation, they want to improve it some what.

Well, they've tried, they even talked to the CEO. They aren't interested.

Besides, if you are scared of getting fired, nothing will even happen. How do you think most workers rights were brought about? They weren't brought about by bowed heads, there were strikes, and sabotage, and police shooting protesters.

So, don't be scared, step up to the plate and swing the bat.

(Another option that didn't occur to me just now, skip the CEO, go the shareholders. Or alternatively the board. Publicly traded company.)

That is terrible advice (1)

bigsteve@dstc (140392) | about 6 years ago | (#24749165)

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.

Typical (0)

Anonymous Coward | about 6 years ago | (#24749089)

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.

A suggestion on how to handle this (2, Interesting)

broothal (186066) | about 6 years ago | (#24749125)

Very interesting question. I see two things that might help. First, don't go to the CEO. You and him clearly speaks different languages. Go to your nearest manager instead and explain to him the consequences of not having procedures. I am sure you can convince him of this, and after the discussion do not settle for a "I'll look into that and get back to you". Always end your meetings with a list of action items with _who_ does _what_ and _when_. This way, you will have clearly defined dates you can follow up on. Have him commit to a date when he will do X (for instance - talk to the Director) and set a date for a follow up meeting with you where he will explain the outcome of said meeting. Should the meeting be canceled, be sure to get a replacement date and set follow up meeting accordingly.

Use We instead of I (4, Informative)

RuBLed (995686) | about 6 years ago | (#24749131)

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..

Re:Use We instead of I (0)

Anonymous Coward | about 6 years ago | (#24749247)

is that like the royal We?

Mixing of two mindsets (3, Insightful)

slipnfall (472801) | about 6 years ago | (#24749137)

Hi OP,

I'm a developer/Engineer for two biotech companies: one a small startup, with me being the only part-time employee. The other is a large DOD-backed institution. I can tell you that in the short time that I've been there, it has been a frustrating uphill battle to instill an Engineering/Developer mindset. While I firmly believe Scientists and Engineers seems to have a similar approach to work, it's interesting to see how passive the science-minded folks are towards hardware/software advancements. They are only concerned about how many protein cells it can accurately count, or whatever. There is no interest in what goes on 'behind the scenes', and consequently, what goes on to get there.

There are absolutely no Engineering controls in place at either Employer, and software development is as you said: made for the moment. Personally since I am the one-and-only, I find that I just have to do the best with what I have. I comment and doccument well, keep a code revision repository, and do my best(within reason) to make sure someone else can pick up where I left off.

It won't be my problem if/when the day comes I leave, but at least I'll be able to sleep at night.

Re:Mixing of two mindsets (2, Interesting)

Bert64 (520050) | about 6 years ago | (#24749393)

I had a family member who used to work with these kind of measuring machines...
He would often complain about how the old but functional machines would be replaced with fancy computer controlled ones, where the software would be extremely limited and often horrendously buggy.

Plant a bug (0, Flamebait)

Swizec (978239) | about 6 years ago | (#24749153)

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.

Re:Plant a bug (3, Informative)

ilovegeorgebush (923173) | about 6 years ago | (#24749287)

That's called sabotage and it's a silly idea.

Re:Plant a bug (1)

Bert64 (520050) | about 6 years ago | (#24749397)

Very few people will complain about bugs anymore, microsoft has convinced them that bugs are normal and to be expected, and that you have to try and work around them...
People used to complain, but years of getting no sensible response has worn them down.

Re:Plant a bug (0, Troll)

apathy maybe (922212) | about 6 years ago | (#24749437)

That's called sabotage, and if you are going to do this, make sure it can't be traced back to anyone, let alone you.

And because that is hard, maybe try my idea of trashing back ups (above), it's easier to hide your tracks...

Concentrate on data output. Analysis can wait (1)

GetAssista (1130195) | about 6 years ago | (#24749161)

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 :)

Re:Concentrate on data output. Analysis can wait (1)

Bert64 (520050) | about 6 years ago | (#24749455)

Document the hardware, provide details of how it works, how to control it and how to read data from it..
Provide a few small programs that acquire data and output them in standard formats (as you pointed out, text).

Don't try to be too fancy, provide good functional and open tools that other people can build on. Depending how niche your product is, third parties may write software to work with it, or the customers may have especially custom requirements that aren't served by the bundled software anyway.

Go back to the CEO (1)

Peter (Professor) Fo (956906) | about 6 years ago | (#24749167)

In your mind you're going to try to get the CEO to say either "OK we do something" or "Forget it" so you know where you stand. The best result is "OK then what do you think we should do about it?"

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!

Here's a revolutionary idea (0)

Anonymous Coward | about 6 years ago | (#24749169)

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.

Re:Here's a revolutionary idea (4, Insightful)

indifferent children (842621) | about 6 years ago | (#24749709)

How much combined experience does the management team and board of this company have?

This argument is also known as "The Enron Gambit": those wildly successful guys who are raking it in hand-over-fist must know better than those of us who think that their business model makes no sense. They sure showed us.

Quality? (1)

rengolin (975639) | about 6 years ago | (#24749179)

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!

When quality looks like a waste of money (1)

e70838 (976799) | about 6 years ago | (#24749695)

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.

Tailor processes (0)

Anonymous Coward | about 6 years ago | (#24749183)

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 (1)

DoofusOfDeath (636671) | about 6 years ago | (#24749185)

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.)

Reminds me of Ariane 5 (5, Interesting)

Planar (126167) | about 6 years ago | (#24749203)

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.

Open source it (5, Interesting)

Adam Hazzlebank (970369) | about 6 years ago | (#24749207)

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!" []

Re:Open source it (3, Informative)

Sparky McGruff (747313) | about 6 years ago | (#24749563)

That's kind of funny; I was thinking about a bug ridden piece of ABI software (the control software for their 7500 real-time PCR machines) as I was reading the original post. I've lost a whole lot of sample runs when the software craps out mid-run. Then again, it could have been the control software for the $500K confocal microscope that renders the hardware largely unusable. Or it could be any number of other software packages that run plate readers, scintillation counters, or anything else. The quality of software on the control systems for even the most expensive hardware is abysmal; they love to produce poor software that loves to crash, and writes proprietary files that can't be readily imported into more powerful software. It's gotten somewhat better over the past 5 years, but as the hardware lives for 20 years, we end users get to enjoy the crappy software long after the company has moved on. It certainly does color my decision about which hardware I will buy in the future, though.

Re:Open source it (2, Interesting)

Adam Hazzlebank (970369) | about 6 years ago | (#24749593)

It's gotten somewhat better over the past 5 years, but as the hardware lives for 20 years, we end users get to enjoy the crappy software long after the company has moved on. It certainly does color my decision about which hardware I will buy in the future, though.

Yea I wouldn't argue that ABI software sucks, but it's a useful stick to beat management with. I'm not sure it's got much better... They've not open sourced the primary data analysis or device control software for the SOLiD sequencers (which suck hard). From what I could see a lot of the device stuff uses messy perl scripts.

I really wish they, and Illumina the current next-gen leader, would open source their software (both device control and primary data analysis). If that were the case I'd be refactoring it, adding unit tests etc. right now.

Re:Open source it (4, Informative)

Sparky McGruff (747313) | about 6 years ago | (#24749743)

If the primary device control software for the SOLiD sequencers is as reliable as their QPCR software, then you'll probably lose about 10% of your runs due to software failure. Of course, that means you get to spend 10% extra on ABI consumables, and if it was a particularly valuable sample, well, tough. It's nice that they're opening up the analysis package, but the true "mission critical" software is the control package. I've yet to find a vendor of (rather expensive) hardware that seems to think the control software is anything other than an afterthought.

Been There - Don't Burn Yourself Out (3, Interesting)

sce7mjm (558058) | about 6 years ago | (#24749211)

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.

It depends on if you are a dev yourself. (2, Interesting)

amn108 (1231606) | about 6 years ago | (#24749221)

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.

take it into your hands (0)

Anonymous Coward | about 6 years ago | (#24749249)

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.

software critical? (0)

Anonymous Coward | about 6 years ago | (#24749263)

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?

Software Quality in a Software Company (0)

Anonymous Coward | about 6 years ago | (#24749283)

If the Software Company that I work for doesn't care about Software Quality, what hope does a Non-Software Company have?

Some hints for your situation (5, Insightful)

Apogee (134480) | about 6 years ago | (#24749317)

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: [] ... These are also good points to whisper into management's ears.

Quality Software development is hard (4, Informative)

wrook (134116) | about 6 years ago | (#24749347)

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 risks. (1)

Standard User 79 (1209050) | about 6 years ago | (#24749355)

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).

you're pressing the wrong buttons (4, Informative)

petes_PoV (912422) | about 6 years ago | (#24749361)

There's no point talking about intangibles to a CEO, or C?? anything else.

Have you quantified the benefits of improving software quality?

Have you laid out the risks (both personal, to the directors and to the share-price) of low software quality

Did you make the guy aware of the legal implications and liabilities?

Did you describe what the competition does?

Did you actually propose a planned and costed solution - or were you just moaning at him?

But most importantly, did you wear a tie?

Re:you're pressing the wrong buttons (1)

phagstrom (451510) | about 6 years ago | (#24749513)

But most importantly, did you wear a tie?

You calling him a liar?

Re:you're pressing the wrong buttons (1)

petes_PoV (912422) | about 6 years ago | (#24749567)

If you're talking to a director, who is not conversant with your work, a decent suit and tie is instantly worth more than a masters degree. The CEO will make up his mind about YOU as you enter the room - before you get to say anything. By the time you sit down, he/she has decided whether to ignore your arguments or whether to take them seriously.

Invoke the FDA (0)

Anonymous Coward | about 6 years ago | (#24749373)

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.

What exactly means "Non-Software Company"? (4, Insightful)

Tanuki64 (989726) | about 6 years ago | (#24749377)

I have worked in enough software companies to know that they are not necessarily better.

Don't raise a problem.. (1)

marcushnk (90744) | about 6 years ago | (#24749399)

Turn up with a solution...

What cand you do to get some attention? (-1, Flamebait)

Anonymous Coward | about 6 years ago | (#24749415)

How about going in front of the CEO and slit your fucking wrists fucktard. It may not change software quality but it will give the CEO a good show as he will be applauding at the end, especially when he sees your dead corpse.


business is about money (0)

Anonymous Coward | about 6 years ago | (#24749449)

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.

What the Hell are you talking about? (1)

Alex Belits (437) | about 6 years ago | (#24749473)

No one has any "quality control procedures" in software. At best a company has someone responsible for testing, and some product-specific set of tests that products pass through before being released or placed into production environment. If you are a developer, just make those things and write a deployment procedure that includes them.

Re:What the Hell are you talking about? (4, Insightful)

SpinyNorman (33776) | about 6 years ago | (#24749663)

Go read up on the Capability Maturity Model (CMM) or ISO 9000 and come back when you have a clue.

You don't even need to formalize the process to that extent to make leaps and bound improvements on the hack-it-together and test it approach you are suggesting... At a minimal a decent software development process should have:

Requirements specifications & reviews
Design specifications & reviews
Test specificiations & reviews
Codng standards
Code reviews
Source control
Regression tests
Functional tests
Load tests

"good enough" is good enough (2, Interesting)

alizard (107678) | about 6 years ago | (#24749491)

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.

Its pretty common don't you think? (2)

methuselah (31331) | about 6 years ago | (#24749505)

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...

FDA will be a problem for you / Heard of GxP? (1)

fredr1k (946815) | about 6 years ago | (#24749509)

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?

Open source (3, Insightful)

Confused (34234) | about 6 years ago | (#24749521)

  • Your software doesn't make money for the company, it's just producing costs.
  • Your customer need the software to use your stuff.
  • From your description, your customers might include quite a few very clever ones that constantly try to push the limit of your systems and thus damning your software to eternal hell for its shortcomings.
  • Any help you can get to develop it would be welcome, although don't expect your development costs to go down.

This sounds like the perfect scenario for open sourcing your software with you as the main developers maintaining it.

For the regular users, nothing much will change.

For the power users, those most likely to complain, this will be a tremendous benefit. If they don't like it, they have the possibility to improve it. This often reduce the number of problem reports and increase the good problem reports from your knowledgeable customers. Sometime you might even get useful patches, that save you some work. If you're really lucky, you might get a few users who start to code enhancements.

It also might generate some good-will towards your company and ease the integration of your bricks with other solutions.

What has this all to do with software quality? With your software out in the open, quality problems tend to be treated more like bugs that will be fixed as fast as necessary and possible and you get a better feedback where work is important. Making the software and drivers open source won't save your company any money, it won't cost more either, but it will improve what you get for your effort.

About Open Sourcing (2, Insightful)

kitgerrits (1034262) | about 6 years ago | (#24749775)

I'm a big fan of open source.
Most of the hardware at home has had its OS/firmware replaced with open-source variants.
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.

Contract IT Consultant(s). (2, Insightful)

jellomizer (103300) | about 6 years ago | (#24749529)

No they are not as evil as the Democrats says. Most of them want to do a good job so you will call them back in the future.
Why contract except for hire.
1. They can be paid for out of your department budget not the general budget. So it requires less steps up to get approval.
2. They work outside of HR. So you can hire them and fire them if you feel they are not doing the job correctly
3. Use a Multi-level support system. Get some Jr. Consultants to do the grudge work for cheap for 3 days on 2 days with a Sr. Consultant to insure the Jr.s are on track and solve larger issues deal with your department give any bad news and estimates etc...
4. More experience for less years. Especially if you get a good mix. You can get a specialist in X and Y and Z because you can use a consultat for their strong points.
5. If you give them motivation that there may be more work down the line they will focus on getting the project done. Yes they want to stay there but if there is a chance of a new project further down the chances of them milking you is a lot less.

Certification (5, Interesting)

tombeard (126886) | about 6 years ago | (#24749555)

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.

Been there, done that, got fired (4, Informative)

Ancient_Hacker (751168) | about 6 years ago | (#24749585)

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.

Missed the obvious solution (3, Insightful)

johannesg (664142) | about 6 years ago | (#24749601)

Make it fail. Make it fail spectacularly, to the tune of millions of dollars. That will certainly get the CEO's attention, and he will be sure to take measures that will stop such failure in the future. Of course, I can pretty much guarantee that you will not like his solution, but software development will be much more professional afterward.

If this is not what you want, ask yourself what you actually want to change. You do know what you want to change, right? Discuss those things with colleagues and managers, then formally propose doing them.

I'm guessing you probably want a more structured development process, with better-organized change requests, and at least some semblance of formal testing. That is very, very hard to set up, because it also requires the help of your users, and they don't care about software, they just want to have their problem solved. If this is the case, always remember that you are there to solve their problems, but they are not there to solve your problems. In other words, don't force them into a process they don't like. You might do better if you can show an advantage other than "it makes my life a little easier".

If all you want is a bugtracker and a version control tool, just request a budget of about $2000, then buy a Dell PC with Linux and install Bugzilla and SVN on it. That will set you back $400 or so, the rest of the $2000 is to show that you are a business thinker and did not forget to include installation time ;-)

If you want to institute Methodologies (like extreme programming or similar), good luck with that. It will probably end in your colleagues defenestrating you...

Re:Missed the obvious solution (1)

barzok (26681) | about 6 years ago | (#24749751)

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

You're going to put something as important as your source code repository on the quality of hardware that comes with at $400 PC?

You're right, that will make it fail, and spectacularly.

FDA Regulations Should Help (0)

Anonymous Coward | about 6 years ago | (#24749603)

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.

Anonymous Coward (0)

Anonymous Coward | about 6 years ago | (#24749629)

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.

Look in the Mirror (0)

Anonymous Coward | about 6 years ago | (#24749641)

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.

proactive synergy and high positive visibility (2, Interesting)

caudron (466327) | about 6 years ago | (#24749651)

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.

Simple... (1)

CyberKrb (774549) | about 6 years ago | (#24749655)

... just introduce a bio-engineered bug. That'll teach them

implications of software failures? (0)

Anonymous Coward | about 6 years ago | (#24749665)

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.

ISO â" the ultimate 'ad-hoc' enima (1)

robsta (949871) | about 6 years ago | (#24749697)

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 : )

But what exactly is the problem? (1)

EEDAm (808004) | about 6 years ago | (#24749705)

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....

Depends (1)

WATist (902972) | about 6 years ago | (#24749741)

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.

cheapest bang for your buck: (1)

spicydragonz (837027) | about 6 years ago | (#24749831)

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.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>