I think you should find an existing manager who you trust and respect (preferably not now in line above you) and ask them to mentor you. You get to talk about problems and issues, and they advise you about how to tackle them. Most good employers will already have a mentoring and management training programme in place, so you should be able to do this easily. If not then push for it: you need it, and probably a lot of other people in your workplace need it too.
Failing that, make it plain to your immediate boss that you are learning on the job and will need lots of support, especially in the early days.
Much as I'd like to see them put on the spot on this, I don't think you'll succeed:
If you say "How do you reconcile with your belief that the earth is only 6,000 years old?" they may say that they are not scientists so they're not qualified to comment on such a detailed question, or they may say that it could be more than 6,000 but God certainly created it, or they may just say "maybe the scientists are wrong about that".
If you say "How can you seriously claim the earth is only 6,000 years old when every real scientist disagrees with you?" they will say that not all scientists agree with evolution, and often today's heresy turns into tomorrow's orthodoxy.
Either way they will then add that science works by the free and open exchange of ideas, and so they support the right of both sides in the debate to put forwards their views. They may also add something about the bible being right about so many other things, it seems odd that it should be wrong just about this.
These debates may have been the place where ideas were put forwards once, but these days they are more like a boxing match in which each candidate tries to land knockout punches on the others, and a panel of pundits awards them points for style. Fact and logic don't stand a chance.
This is a false comparison. What management really want is support (i.e. someone on the end of the phone who knows how to fix it). And there are lots of paid-for support options for Linux. The point of "free" software is not "free of cost" its "free market". All of the support services are available on the free market instead of being tied to the original vendor. If you don't like the service you are getting then you can change supplier without having to change software as well. That gives you options and bargaining power that you don't have with proprietary offerings, and avoids exposure to commercial risk if the vendor goes under or stops supplying or supporting a package you need. Compare this with the sorry story of the people to locked themselves into VB6 and are now having to manually port all their software to VB.Net.
And yes, if someone trots out the "someone to sue" you can quote the MS EULA: its software is "guaranteed to work *substantially* in accordance with the documentation for 3 months" (my emphasis).
Why assume that the owners of the domains are behind this? Isn't it more likely that their computers are pwned by bot-herders and these are probes coming from botnets seeking to spread?
There are roughly two categories of MS patent that GNU/Linux distributions are likely to infringe.
The first is on fundamental algorithms and data structures. I say "fundamental" in the sense that these are a natural way to solve particular problems. So it might turn out that Linux is using a schedular or a VM indexing system that happens to have been patented by MS. But this kind of thing is generally possible to work around. The truly fundamental algorithms here are in the prior art and have been for years, so anything patented by MS can only be construed very narrowly if it is to be upheld at all. But if it is construed narrowly then you don't need to make many changes to avoid it. So this is nuisance value only.
The second is on particular compatibility features, such as the precise protocols used by SMB. It might well be that the only way to inter-operate with MS file servers or Active Directory domains is to use a protocol that MS has patented. If so then in theory MS can issue a Cease & Desist letter and force the Samba team to go off the net, or at least stop Samba shipping in commercial distributrions.
But suppose they actually do this. The US competition authorities are likely to stay supine, at least until the next presidential election. But the EU is very much in activist mode, and those patents probably don't apply in the EU (getting world wide coverage on patents is an order of magnitude more expensive than just getting a US patent, and most EU countries make software patents a lot harder anyway). So far the EU has held off requiring MS to open up its IPR completely, because the Samba project has been able to work around it anyway. But if they see MS using interface patents to block interoperability they might well change their minds.
So one way and another I don't reckon that MS has much leverage.
I worked in a similar company, and had similar issues. The thing to understand is that the FDA inspectors are not (usually) software literate. Therefore they have to follow a "tick in the box" attitude to the CFR 820 (which if IIRC is the relevant regulation). This is very frustrating because it completely ignores all the real quality issues, and yet if you don't tick the right boxes then you can wind up in court or have your company closed down.
Don't blame the individual inspectors, BTW. They are just doing the job handed to them.
The trick here is to find a way to satisfy the regulations. Get your quality department on side here, because they are the ones who actually have to justify it to the inspector, and its their jobs on the line if they don't succeed.
As for open source, you need to get it considered under the same rules as other "COTS" software. I don't recall the details, but basically you have to come up with convincing evidence that some kind of process is properly followed. ISO9000 is the cheat sheet for proprietary software because its evidence that something of the right sort is done and audited. Open source doesn't have that, so you have to do it yourself.
Start by writing down what a good open source project looks like. Take as much as you can from ISO 9000 here. Do they have coding standards? Show they are adhered to. Configuration management? CVS. Code review? Contribution policy. Defect tracking? Bugzilla, and cite statistics showing that reported defects get fixed. Most large successful open source projects can ace this stuff anyway: if they couldn't they wouldn't be any good.
For requirements you have to get a bit more creative. Is it documented at the user level (e.g. API)? If so then you can call that documentation the requirements document and show that the source complies with it. The fact that this documentation was written after the software is irrelevant from your point of view because you only need to demonstrate that the software is fit for purpose, and that the documentation shows this. Write this argument down and it pretty much covers you.
You might also run a code review of a sample of the software to demonstrate that it meets your normal quality criteria.
Obviously this costs more than simply saying "supplier has ISO9000". But if its cheaper than buying ISO9000 then its still the right thing.
Incidentally, when I was doing this (a couple of years ago) some FDA staffer talked to our Quality Dept saying that open source was random, uncontrolled stuff that should never be allowed near real software. Basically they regurgitated a load of MS FUD. Be ready for this, and be ready for your QA dept to recite it back to you.
Too right. I turned on encryption first thing, but I kept getting weak signals from another wireless net where I used to live, and they were unencrypted. So I took an iPAQ with a wireless card and walked down the street watching signal strength. After a few minutes I was pretty sure where the signal was strongest, so I knocked on the nearest door. I told the guy who opened it what his SSID was, which got his attention, and then explained how someone could riffle through his computer, or maybe just bring a search warrant down on his head. The guy secured his network that day, and then asked me back to check he had done it right.
Like, don't warn us that the linked story tries to run ActiveX controls that "improve" my computer. I suppose most/.ers either run Firefox or have security turned up high, but hey, thats no excuse.
"Distributed" in this context means "no central server", or more precisely, "no master repository". Instead everyone has their own repository. When you change your repository you publish the diffs and they are then integrated into everybody elses repositories.
This is a much more flexible model. Depending on how you move the diffs around you can designate one repository as "master", and thereby emulate the master repository system, or you can have a number of subsidiary masters for partial integration, or you can have a master for each version of the product while still being able to migrate common changes around the entire set. These can be difficult or impossible with conventional systems.
For the purest thinking along these lines check out Darcs (although it doesn't scale to large projects yet).
I've just been reading Clayton Christensen's book "The Innovator's Dilemma" about disruptive technologies. Actually "technology" is a bit of a misnomer: it ought to have been called "disruptive marketing". While technology is often a key part of the story, the real driver is generally the discovery of some small niche that is either not served at all by the incumbents, or that is over-served because the incumbents are always releasing bigger, better and more expensive versions and something simple, small and cheap isn't on the market.
So it seems to be with office productivity. Microsoft says that ODF lacks the features of its higher end product, and "the majority" of its users would not find this acceptable. Even if this is true (a big "if") there is still a substantial minority of users who do not want to pay hundreds of dollars for all the bells and whistles. These people will rapidly migrate to ODF, especially once they can be certain of sending it to an Office user and have it look the same. From there ODF will rapidly migrate up-market.
Yeah, Lisp is pretty cool and I can understand why Paul Graham is so fond of it. But try Haskell. Its higher level than Lisp, and ought to be the First Language for University courses.
Try using something like QuickCheck . The original version was for Haskell, but you could easily adapt it to work with C++.
The idea is simply to define the "space" of legal inputs for each module and the correctness criterion for each input, and then generate random inputs based on the spec. This is far more effective than traditional hand-coded test data at both unit and system test levels, and as an added bonus the test spec doubles as a formal specification of the correct behavour that coders can actually work from. This is similar to the XP practice of "test-driven development".
Monads look wierd, its true. Why go to all that trouble just to do something that any normal language does naturally?
The answer is that I/O is actually a special case. Monads provide a context for sequential execution of actions. I/O is only one of those contexts. Other contexts include stateful computations, non-determinism, exception handling and parsing. These contexts can be combined, providing clean separation of concerns. Conventional languages only give you the one context.
Functional programming greatly simplifies the task of the programmer by removing execution order from the things that programmers have to keep track of. Just as garbage collection in Java got rid of the need to recycle memory manually, so in Haskell the execution order is a matter for the compiler to optimise rather than for the programmer to worry about.
Historically functional programming has had problems doing IO: languages have had to admit impure side effects to do IO. Haskell has a wonderful solution to this problem, which unfortunately this post is too small to contain (really: go see!).
Some people are recommending that you treat the modules as "black boxes" and write the tests according to their specs. Problem is (as others have pointed out) the specs are not detailed enough. So you will inevitably wind up looking at the code and then writing tests that prove the code does what it says it does.
And this is actually OK, because it simply means that the "Unit test creation" process is actually a detailed code review process. Expect to find far more bugs from looking at the code than from running your tests. But this doesn't matter: the bugs have been found.
Don't expect to be able to reuse the tests after modifying the code because any change to the code will generally break the test.
You might have a look at QuickCheck though. It was written as a unit test system for Haskell functions: you write a formal spec of the properties of the module and it generates random tests according to that spec. The latest prototype (see the website pointed to by www.haskell.org) also handles modules with state, and there is no reason why it couldn't be used for general software test. By organising your test around formally specified properties of modules instead of individual procedures you should get more reusable tests.
I was at GEC when it was turned into Marconi. At the time it was being run by George Simpson. His previous job was at Lucas, the car and aircraft parts maker, so we all referred to him as George Lucas.
Simpson was bought in as a deal maker. He took GEC, sold off the defence business to BAe, renamed the rump of the company Marconi and turned it into a telecom company. So far so good, and the share prices soared. Unfortunately neither he nor any of the team he bought over from Lucas knew anything about telecoms. You had to go about three levels down from Simpson before you found anyone who could stand up at an industry meeting and not look like a fool.
The next big deal was for Marconi to buy a big ATM equipment manufacturer in the US named FORE Systems. They had shares inflated by the bubble. We also had shares inflated by the bubble. But we had to pay cash because our shares could not be traded in the US at that time. Oops. The deal meant that the four founders, who had most of the intellectual capital, now had FU Money as well. So they said FU. Eventually Simpson managed to promote someone else from Fore to be CTO of Marconi. But he wasn't one of the guys who got FU Money, and there was a reason for that. His idea of a technical strategy was to get the engineers to build a bigger, faster box than the last one.
Orders dried up. The company almost went bust. I got laid off with a whole bunch of others, and Marconi is now a shadow of its previous self.
Managers don't need to be technical wizards, but they do need to have a decent understanding of what the engineers are talking about. Middle PHBs can sometimes get by, especially if they are not directly managing techies. But if the guys in charge of strategy cannot tell which way the wind is blowing in your industry then get out while the getting is good.
Try Lego Mindstorms. One thing that gets every kid is wanting to build a robot, and with Mindstorms you actually can, and then you can program it using the simple kit that comes with it. And once you have outgrown that you can go to the Mindstorms hacking sites and get the more advanced stuff. It will grow with a child.
I loved Meccano and Lego when I was a kid, but the most advanced automation stuff in those days was a photo sensor and relay.
These patents (5,206,951, 5,421,012 and 5,226,161) are so basic, they cover large amounts of OO software. According to this decision, Kodak now owns CORBA, COM, large parts of Linux, Apache, and pretty much every other large piece of software ever written.
According to the Groklaw discussion, the jury trial came from a town where Kodak is one of the two main employers. One can only suspect that this may have swayed the jury.
This is definitely a case for PubPat to tackle. There has got to be significant prior art on these patents.
To anyone thinking of looking, prior art must fulfil the following requirements (IANAL):
It must precede the submission of the patent.
It must be published. Open source should do fine. So should any kind of academic textbook or paper. Closed source doesn't count unless the technique was specifically described in the documentation or some similar published work.
It must be specific. Saying "Unix had this in 1980" doesn't count. Saying "This was described in section 3.4 of Programming Objects in FOO by J Random Academic in 1980" does count.
It must cover the same ground as the claims. Suppose that the candidate prior art had been published today. Would it infringe the patent? If so, then its prior art that invalidates the patent. Otherwise its irrelevant.
Why bother? I can't take it on an airplane in my laptop bag. And even when I'm not flying I'd be scared that next time I do fly I'd forget to take it out before heading for the airport.
Having read both, I believe that most people would find the "anti" letter more persuasive than the RIAA one. The RIAA is long, verbose, addresses the concerns of a narrow industry sector, and drags in irrelevant and emotive arguments (Is this the kind of software you would want your wife or servants to be using?). The anti letter is short, to the point, and addresses legitimate concerns of a wide range of industries.
Of course that doesn't mean that the RIAA will lose this one: money talks louder than words. But to the extent that words matter, I think that sanity has won this round.
Slashdot Mirror
I think you should find an existing manager who you trust and respect (preferably not now in line above you) and ask them to mentor you. You get to talk about problems and issues, and they advise you about how to tackle them. Most good employers will already have a mentoring and management training programme in place, so you should be able to do this easily. If not then push for it: you need it, and probably a lot of other people in your workplace need it too.
Failing that, make it plain to your immediate boss that you are learning on the job and will need lots of support, especially in the early days.
Good luck,
Paul.
And it doesn't work even in "Plain old text" mode when I used angle brackets.
I meant to say "How do you reconcile (random scientific fact) with your belief that the earth is only 6,000 years old?"
I meant to say
"How do you reconcile with your belief that the earth is only 6,000 years old?"
But then I turned on HTML to get bullets, and of course that broke it.
- If you say "How do you reconcile with your belief that the earth is only 6,000 years old?" they may say that they are not scientists so they're not qualified to comment on such a detailed question, or they may say that it could be more than 6,000 but God certainly created it, or they may just say "maybe the scientists are wrong about that".
- If you say "How can you seriously claim the earth is only 6,000 years old when every real scientist disagrees with you?" they will say that not all scientists agree with evolution, and often today's heresy turns into tomorrow's orthodoxy.
Either way they will then add that science works by the free and open exchange of ideas, and so they support the right of both sides in the debate to put forwards their views. They may also add something about the bible being right about so many other things, it seems odd that it should be wrong just about this.These debates may have been the place where ideas were put forwards once, but these days they are more like a boxing match in which each candidate tries to land knockout punches on the others, and a panel of pundits awards them points for style. Fact and logic don't stand a chance.
Paul.
This is a false comparison. What management really want is support (i.e. someone on the end of the phone who knows how to fix it). And there are lots of paid-for support options for Linux. The point of "free" software is not "free of cost" its "free market". All of the support services are available on the free market instead of being tied to the original vendor. If you don't like the service you are getting then you can change supplier without having to change software as well. That gives you options and bargaining power that you don't have with proprietary offerings, and avoids exposure to commercial risk if the vendor goes under or stops supplying or supporting a package you need. Compare this with the sorry story of the people to locked themselves into VB6 and are now having to manually port all their software to VB.Net.
And yes, if someone trots out the "someone to sue" you can quote the MS EULA: its software is "guaranteed to work *substantially* in accordance with the documentation for 3 months" (my emphasis).
Paul.
Why assume that the owners of the domains are behind this? Isn't it more likely that their computers are pwned by bot-herders and these are probes coming from botnets seeking to spread?
Paul.
- The first is on fundamental algorithms and data structures. I say "fundamental" in the sense that these are a natural way to solve particular problems. So it might turn out that Linux is using a schedular or a VM indexing system that happens to have been patented by MS. But this kind of thing is generally possible to work around. The truly fundamental algorithms here are in the prior art and have been for years, so anything patented by MS can only be construed very narrowly if it is to be upheld at all. But if it is construed narrowly then you don't need to make many changes to avoid it. So this is nuisance value only.
- The second is on particular compatibility features, such as the precise protocols used by SMB. It might well be that the only way to inter-operate with MS file servers or Active Directory domains is to use a protocol that MS has patented. If so then in theory MS can issue a Cease & Desist letter and force the Samba team to go off the net, or at least stop Samba shipping in commercial distributrions.
So one way and another I don't reckon that MS has much leverage.But suppose they actually do this. The US competition authorities are likely to stay supine, at least until the next presidential election. But the EU is very much in activist mode, and those patents probably don't apply in the EU (getting world wide coverage on patents is an order of magnitude more expensive than just getting a US patent, and most EU countries make software patents a lot harder anyway). So far the EU has held off requiring MS to open up its IPR completely, because the Samba project has been able to work around it anyway. But if they see MS using interface patents to block interoperability they might well change their minds.
Paul.
I worked in a similar company, and had similar issues. The thing to understand is that the FDA inspectors are not (usually) software literate. Therefore they have to follow a "tick in the box" attitude to the CFR 820 (which if IIRC is the relevant regulation). This is very frustrating because it completely ignores all the real quality issues, and yet if you don't tick the right boxes then you can wind up in court or have your company closed down.
Don't blame the individual inspectors, BTW. They are just doing the job handed to them.
The trick here is to find a way to satisfy the regulations. Get your quality department on side here, because they are the ones who actually have to justify it to the inspector, and its their jobs on the line if they don't succeed.
As for open source, you need to get it considered under the same rules as other "COTS" software. I don't recall the details, but basically you have to come up with convincing evidence that some kind of process is properly followed. ISO9000 is the cheat sheet for proprietary software because its evidence that something of the right sort is done and audited. Open source doesn't have that, so you have to do it yourself.
Start by writing down what a good open source project looks like. Take as much as you can from ISO 9000 here. Do they have coding standards? Show they are adhered to. Configuration management? CVS. Code review? Contribution policy. Defect tracking? Bugzilla, and cite statistics showing that reported defects get fixed. Most large successful open source projects can ace this stuff anyway: if they couldn't they wouldn't be any good.
For requirements you have to get a bit more creative. Is it documented at the user level (e.g. API)? If so then you can call that documentation the requirements document and show that the source complies with it. The fact that this documentation was written after the software is irrelevant from your point of view because you only need to demonstrate that the software is fit for purpose, and that the documentation shows this. Write this argument down and it pretty much covers you.
You might also run a code review of a sample of the software to demonstrate that it meets your normal quality criteria.
Obviously this costs more than simply saying "supplier has ISO9000". But if its cheaper than buying ISO9000 then its still the right thing.
Incidentally, when I was doing this (a couple of years ago) some FDA staffer talked to our Quality Dept saying that open source was random, uncontrolled stuff that should never be allowed near real software. Basically they regurgitated a load of MS FUD. Be ready for this, and be ready for your QA dept to recite it back to you.
Paul.
Too right. I turned on encryption first thing, but I kept getting weak signals from another wireless net where I used to live, and they were unencrypted. So I took an iPAQ with a wireless card and walked down the street watching signal strength. After a few minutes I was pretty sure where the signal was strongest, so I knocked on the nearest door. I told the guy who opened it what his SSID was, which got his attention, and then explained how someone could riffle through his computer, or maybe just bring a search warrant down on his head. The guy secured his network that day, and then asked me back to check he had done it right.
Paul.
Like, don't warn us that the linked story tries to run ActiveX controls that "improve" my computer. I suppose most /.ers either run Firefox or have security turned up high, but hey, thats no excuse.
This is a much more flexible model. Depending on how you move the diffs around you can designate one repository as "master", and thereby emulate the master repository system, or you can have a number of subsidiary masters for partial integration, or you can have a master for each version of the product while still being able to migrate common changes around the entire set. These can be difficult or impossible with conventional systems.
For the purest thinking along these lines check out Darcs (although it doesn't scale to large projects yet).
Paul.
So it seems to be with office productivity. Microsoft says that ODF lacks the features of its higher end product, and "the majority" of its users would not find this acceptable. Even if this is true (a big "if") there is still a substantial minority of users who do not want to pay hundreds of dollars for all the bells and whistles. These people will rapidly migrate to ODF, especially once they can be certain of sending it to an Office user and have it look the same. From there ODF will rapidly migrate up-market.
Paul.
The idea is simply to define the "space" of legal inputs for each module and the correctness criterion for each input, and then generate random inputs based on the spec. This is far more effective than traditional hand-coded test data at both unit and system test levels, and as an added bonus the test spec doubles as a formal specification of the correct behavour that coders can actually work from. This is similar to the XP practice of "test-driven development".
Paul.
Monads look wierd, its true. Why go to all that trouble just to do something that any normal language does naturally?
The answer is that I/O is actually a special case. Monads provide a context for sequential execution of actions. I/O is only one of those contexts. Other contexts include stateful computations, non-determinism, exception handling and parsing. These contexts can be combined, providing clean separation of concerns. Conventional languages only give you the one context.
Paul.
Functional programming greatly simplifies the task of the programmer by removing execution order from the things that programmers have to keep track of. Just as garbage collection in Java got rid of the need to recycle memory manually, so in Haskell the execution order is a matter for the compiler to optimise rather than for the programmer to worry about.
Historically functional programming has had problems doing IO: languages have had to admit impure side effects to do IO. Haskell has a wonderful solution to this problem, which unfortunately this post is too small to contain (really: go see!).
Paul.
Paul.
Some people are recommending that you treat the modules as "black boxes" and write the tests according to their specs. Problem is (as others have pointed out) the specs are not detailed enough. So you will inevitably wind up looking at the code and then writing tests that prove the code does what it says it does.
And this is actually OK, because it simply means that the "Unit test creation" process is actually a detailed code review process. Expect to find far more bugs from looking at the code than from running your tests. But this doesn't matter: the bugs have been found.
Don't expect to be able to reuse the tests after modifying the code because any change to the code will generally break the test.
You might have a look at QuickCheck though. It was written as a unit test system for Haskell functions: you write a formal spec of the properties of the module and it generates random tests according to that spec. The latest prototype (see the website pointed to by www.haskell.org) also handles modules with state, and there is no reason why it couldn't be used for general software test. By organising your test around formally specified properties of modules instead of individual procedures you should get more reusable tests.
Paul.
Simpson was bought in as a deal maker. He took GEC, sold off the defence business to BAe, renamed the rump of the company Marconi and turned it into a telecom company. So far so good, and the share prices soared. Unfortunately neither he nor any of the team he bought over from Lucas knew anything about telecoms. You had to go about three levels down from Simpson before you found anyone who could stand up at an industry meeting and not look like a fool.
The next big deal was for Marconi to buy a big ATM equipment manufacturer in the US named FORE Systems. They had shares inflated by the bubble. We also had shares inflated by the bubble. But we had to pay cash because our shares could not be traded in the US at that time. Oops. The deal meant that the four founders, who had most of the intellectual capital, now had FU Money as well. So they said FU. Eventually Simpson managed to promote someone else from Fore to be CTO of Marconi. But he wasn't one of the guys who got FU Money, and there was a reason for that. His idea of a technical strategy was to get the engineers to build a bigger, faster box than the last one.
Orders dried up. The company almost went bust. I got laid off with a whole bunch of others, and Marconi is now a shadow of its previous self.
Managers don't need to be technical wizards, but they do need to have a decent understanding of what the engineers are talking about. Middle PHBs can sometimes get by, especially if they are not directly managing techies. But if the guys in charge of strategy cannot tell which way the wind is blowing in your industry then get out while the getting is good.
Paul.
Try Lego Mindstorms. One thing that gets every kid is wanting to build a robot, and with Mindstorms you actually can, and then you can program it using the simple kit that comes with it. And once you have outgrown that you can go to the Mindstorms hacking sites and get the more advanced stuff. It will grow with a child.
I loved Meccano and Lego when I was a kid, but the most advanced automation stuff in those days was a photo sensor and relay.
Paul.
According to the Groklaw discussion, the jury trial came from a town where Kodak is one of the two main employers. One can only suspect that this may have swayed the jury.
This is definitely a case for PubPat to tackle. There has got to be significant prior art on these patents.
To anyone thinking of looking, prior art must fulfil the following requirements (IANAL):
Paul.
Paul.
Why bother? I can't take it on an airplane in my laptop bag. And even when I'm not flying I'd be scared that next time I do fly I'd forget to take it out before heading for the airport.
Paul.
Film at 11!
Of course that doesn't mean that the RIAA will lose this one: money talks louder than words. But to the extent that words matter, I think that sanity has won this round.
Paul.