Maximum PC

Mostly to waste time and money. =)

In my experience, automated unit testing is the only kind of testing that has proven to be extremely worthwhile. I've worked on some large projects with 300+ page test plans (of course, none of them have unit tests since they're all years behind schedule by that point -- at least what the computer industry calls a unit test) and they are all just full of bugs. Huge failures because the basic building blocks of the systems are full of bugs. It doesn't really matter though -- Boeing sat systems appears to have gone over the point of no return. I wouldn't be very surprised if that division of the company was still around in 3 years.

Granted, some types of programs are harder to unit test than others... web/database, real-time systems, etc.



How on earth... I never said that Lisp was the be-all-end-all system. In fact, I actually said that "I didn't bring it up; It just happened to be on my resume." Anyways, I would posit that a computer scientist that hasn't heard of Lisp (I'm not saying used... just heard of) is probably about as competent as a physicist that hasn't heard of Newton. Of coarse, this group hadn't heard of Python either (also on my resume), so I'm pretty sure they're probably about as competent as a physicist that hadn't heard of either Newton or Einstein. Just my opinion... maybe you know plenty of excellent CS/programmers that haven't heard of Lisp. That was the first time that I had met someone that hadn't heard of Lisp. Normally, I would have been surprised to meet someone that hadn't heard of Lisp. In this case, it happened to be an entire software team, and I was shocked.

"It is ridiculous to think that it would be a deal breaker."
They were totally incompetent; I would never have worked with them, and thankfully, Gates cut the program. Unfortunately, after $80 billion down the drain.... </me shakes head> ... what a waste.

What you don't think that the guys at research labs or in phd programs are paid for their work? Did you go to a college or a uni? JK... =)

The starting pay for a research programmer at USC ISI is $30 to $35 an hour which is basically the same starting pay at all of the aerospace companies in the LA area. Or course, you'll have to get used to making due with only one boss giving you assignments. Of course, the assignments won't be something retarded either. You'll also have to forgo all of the joy involved with formatting hundreds of pages of Word docs.


Good idea. It's starting to get really nice out now. I'm getting quite a bit of pressure from one of my buds in LA to put together a touring bike. We might be heading your way this Summer.

Hey, watch it.

I had missed Jip's post from last month.

.. bitch. I went to three different unis .. and I thought I was making decent money .. until I saw what you can make on the open market.



Sure .. but you're comparing the income of the best in the academic research sphere with the average salary of everyone else in industry.

$30 - $35 an hour is about half what I charge for consulting .. and I'm 'only' a writer.



Ok, the first two sound good to me .. but Word docs? Really? No. That is for interns. I'm all about DITA, XML and structured authoring.



Nice! Let me know in advance and I'll ensure that you see all the best things that SW BC has to offer.

Unit tests can ONLY verify if the functions return properly. Compare that to sensors in cars. You could have an oxygen sensor reporting the wrong O2 levels, but since it was reporting the correct type of value in the correct "range" (passing the 'unit test') you don't see a check engine light for the O2 sensor failure. To say that unit tests are the only worth while testing is really short sighted. Just because it is a long test plan doesn't mean it is correct, tests the right conditions in the right ways. No SINGLE form of testing will find 100% of bugs.

You can't possibly unit test for every conceivable input and output. I have seen code that works perfectly for a set of values, but fails horribly for others. Unit testing is great but it can't do it all.

Are you certain of their qualifications? It just sounds like you described a bunch of managers. FWIW, they don't need to know the technology, although they SHOULD... a managers job isn't to design the system, he just has to recognize talent and then put the right people in the right place.

I know you weren't saying that, but that was what I got out of your comments. It was like "They haven't heard of LISP, so they must automatically be idiots".

I am willing to put money on it that my Dad (not in CS at all, but an Engineer, and a damn good one at that) could manage a group of people responsible for that, be able to hire well qualified people, and get the project going in the right direction without knowing what I know about CS, languages, and systems, etc.

TITP! Also, consider what kind of benefits come with those research jobs. I really doubt that a University could compensate me as well as I am being compensated for now.

Sounds to me like Gadget has had some really shitty jobs and thinks the entire industry is that way

I don't write or format word docs in any stretch of the imagination that large. Even at my entry level position, I am not doing that. I don't even make my co-ops/interns do that. It is a waste of time usually. Focus on the design documents, those are more important.

I haven't had a single "retarded" assignment. I might have had ones that I wasn't super interested in, but not retarded. We can't afford to waste a whole lot of time on really "retarded" assignments. If there is zero business value then it doesn't happen.

You can't really compare Boeing et al. to the majority of private industry. There is bureaucracy everywhere. If you don't think it happens at the University then you have managed to shelter yourself well. In my experience, it is worth in Academia than anywhere else. Especially because most researchers only claim to fame is their research projects. I am quite happy bringing home a paycheck and having nice toys at home. Getting published isn't all that big of a deal. Not that it isn't a worthwhile effort... and I am sure it is very rewarding to some. There isn't a perfect world, sure. But I like the higher pay that the private industry provides me.

And you call yourself punk rock?! SELLOUT!!!


Yeah, that is mostly true...


Sure. But you're probably not getting the same kind of benefits package. Also, I'm not familiar with how taxation in Canada works, but I imagine doubling your gross income doesn't translate into doubling your net income. I know it doesn't work that way here! =)



Your XML comment triggered a repressed memory deep in my subconscious. I have a perfect example of how bad it is at times. Initially, I worked for the "database" group. In a nutshell, they collect data and make XML "deliveries" of the data. The delivery is almost like an ISA for a processor. Then I worked for a satellite test group, they use the XML delivery to test the spacecraft. There has always been interface related problems between the two groups (this goes way back before the use of XML and extends to every group receiving XML deliveries... sigh). Anyways, my buddy Andrew (a very good CS student and programmer) and myself were given the task of improving this situation. Since we were always having trouble tracking down issues with the XML, I went ahead and wrote an XML Schema for each of the different kinds of deliveries. The next day, we sat down and tested the deliveries and fought over some issues due to crappy database design (ie I'm staunchly a "right thing" guy and he is more of a "wrong is better" type). Anyways, we came to an agreement, found the source of our problems, and even uncovered about twenty other issues just waiting for us. We thought that we were basically done. The XML Schemas would serve as an INTERFACE document. Certainly, neither one of use was going to write an interface document in Word.

Yeah, right!!! The managers from both teams rejected our XML Schemas. Why?

1) We uncovered additional errors. Despite LEAN supposedly having something to do with being proactive and improving things (and it was ironically enough LEAN money that paid for our work), our dumbass managers decided that the prudent thing to do was pretend that the errors didn't exist. The database manager fully acknowledged that we had uncovered important errors in the XML and data. However, fixing the errors would make them look like idiots, and they were already under attack from leaders of larger projects questioning the need for a database group. Dinosaurs don't adapt well to change...

2) As I mentioned previously, the test team had stupidly written their own half-ass XML parser. The problem with XML schema is that if it says the schema is valid, then you can't very well go to the other group and say that the XML files are borked when they know you have a broken parser. Even the regional manager could figure that one out.

3) The database group was already doing verification using DTDs. Now keep in mind that the DTDs were literally two to five lines that made sure the very first element was correct (ie basically that the table name and fields were correct). Of course, one of the nitwits tried to peg our work as redundant.

To make a long story short, after a couple of weeks of meetings between various key parties in each group, it was decided that the database group would write an interface document for each of the groups to which they make deliveries (despite every group receiving the same files). The test group would need to verify the interface described in the document. If they agreed it was correct, we'd all sign it (like a f'ing contract). Of course, it doesn't work.

Another funny mentionable is that half of the database group (the system engineers, not the software engineers) believes that the M in XML stands for magical. They fervently believed that switching to XML was magically going to make all of the problems with the data go away. They're still in denial over all of this four years later.

For better or worse, Word is one of the "standard tools" at Boeing and used for most software engineering documents (eg. requirement docs, test plans, etc). Most of the SEs don't even know basic features in their IDEs, but they sure as hell know how to create an index in Word!

In theory, (nearly) all programming languages are Turing complete, so we may as well write... you know the argument. I would submit that unit tests can do far more than just verify input/output. To quote the XP school of thought, writing unit tests prior to code often results in better, more general, code. It certainly helps you to get past any design related "writers block". By using an "automated" unit test environment, I also have a decent form of regression testing (not to mentioned acceptance). Being a bit clever, unit tests can verify side-effects... is your scheduler really fair? Define "fair" in a unit test and find out. You can also verify that an algorithm is efficient and finishes execution in a certain amount of time (assuming you can figure out the worst case scenario).

Pragmatically, unit tests are extremely cheap compared to "test plans" and catch the vast majority of errors. It is actually pretty hard to get bugs in the interfaces between modules. Generally, if you can't effectively unit test a module, it is because the module is a tangled bunch of noodles. Refactor it.


It is certainly going to be hard to unit test hardware sensors with a software unit testing framework; However, I would bet that companies like Intel find a lot more hardware errors in their sims than they do by physically testing their hardware. I know this is true for satellites at Boeing (ie the virtual hardware sims vs the physical hardware tests).


I don't believe that is what I said, but I do tend to agree with the sentiment. =) No form of testing will find 100% of bugs in non-trivial systems. NASA does testing that extends far beyond what any company would ever consider performing, and they still have catastrophic errors.


I know that three were software developers and two of them were managers. I'm not sure about one of the team members. I believe that one of the managers had been a software engineer. The program was a horrible mess. In fact, it should have never been funded (long story... you can read McCain's comments on FCS if you're interested).

What makes this interview kind of funny is that the job req looked like a Microsoft marketing brochure... .NET this, SQL server that... There must have been eight or nine MS products listed in the req. During the interview, they asked me questions like "do you know linux", "do you know MySQL", "do you know C and Perl". I asked them about the obvious contradiction between the questions they were asking me and the job req. The manager replied that he should probably "update" the req. I felt like being a smart-ass and asking why they had switched from MS to Linux. He had obviously simply copied some other job req and pasted it in the form.


Well, they aren't very good at that either... =)


Do you really believe that your dad could lead a team to create a compiler, operating system or database? Short of hiring Ullman or Tanenbaum to actually lead the project, no, I don't think so. However, your father shouldn't feel bad because I don't think that either of us could lead a team to create a nuclear reactor or a rocket propulsion system either. I'd be curious to ask what your going to ask someone regarding nuclear reactor design. Aside, from doing the obvious thing and hiring the Michael Jordan of the field, you really don't have too many options.

History is also tangentially on my side. The early Apollo missions were staffed and managed by aerospace personnel, and it was believed that it would be easier to train aerospace engineers to write software than other way around. The result was a smashing failure. If software engineering has taught us anything, it is that software is extremely hard to get right.

Software can be very subtle and misleading. No human could possibly beat a decent Othello program, but no Go program performs worth a snit. It doesn't seem rational to people not familiar with computational issues. If someone tells your father to create a billion watt stereo amplifier, despite being theoretically possible, it is easy to rattle off practical reasons for rejecting such a proposal. It is obvious. However, if someone suggests that you develop a program that determines whether another program "halts", it is pretty easy to convince yourself of the benefits of such a program ("We'll make MILLIONS!") and possibly make a snap decision heading straight down the road to theoretical impossibility. It's happened a thousand times on a variety of problems to the best of the best in the field. How could we expect someone outside of the field to know any better?!

* Assuming NP != P