Just got a whole lot better!

You are severely underestimating an organization's ability to apply band-aids when needed.

I'm in the middle (well towards then end) of just such a legacy replacement project. I can, without any hesitation, say this project is a success but the head aches we've dealt with are pretty severe and it took a great, well managed team, a solid couple years to get to a 95% point. The problem with legacy systems is not necessarily the errors in the code (of which there are plenty... can we say type UN-safe languages??) but the layers upon layers of process and paperwork and siloed domain knowledge that have been built up around the system to cover those bugs for *decades.

Requirements gathering is a fuzzy mess:
You start with the business and you better interview just about *everyone if you expect to get all of the edge cases the system will expect. Gather every tiny little requirement you can because at the end of the day *all of these little Easter eggs will be important.
You look to the original source code (assuming you still have access to it) to see what *it thought the business rules were and line that up with what the business thinks those rules should be. They will *not agree with one another.
You have lots of meetings to try to hash out what the rules really *should be and hopefully end up with an answer that everyone is happy with (including regulators if you're in a government office).
Than you develop the system and assuming you're being at least somewhat agile prepare for exhaustive labors every time the outputs of your system don't exactly match the outputs of the old system because even if the old system was wrong (which it was if you're doing your job right) you have to prove beyond a doubt that is the case before you can get past QA.
That pile of 500 reports the old system cranked out? Those are band-aids for bugs the old system had that the people "fixed" by reporting on the data. You will have to code the generation of a LOT of these only to throw most of them away when your code eliminates their need.
That convoluted process they want you to replicate? It is band-aid on band-aid on band-aid on band-aid on a system flaw that was never really diagnosed which you have now fixed in your reimplementation but still have to wade through how much of that process is no longer needed and convincing the stakeholders they really don't need to do it anymore because the problem is "fixed".

This is 1 system and you can guarantee all 207 will have the same headaches.

This is all "doable" but he really sounds like he has no clue about what it will take to "do" it. The mention of "cloud-based, common data platform, that's "ideally open source." also makes me want to shoot him and get started working on finding his replacement. Fuck your buzzwords and do your job. None of those concepts says *anything about the hard part of getting this done.

I agree that this is not a great usage for biometrics... maybe if you were adding security to the whole lab not just a step verification.

BUT if you were to go Biometric then you should use Iris (Not Retina or Face). It is the easiest, fastest and most accurate for 1-1 Verification (Assuming you get your tech from Morpho... they have a patent on the only good tech right now)

Retina is just too invasive and doesn't give you any more (maybe even less) accuracy than Iris.. not really used much any more.

Face is great these days (NOT Facebook/Apple's tech... "real" matching tech) but is not ergonomic for your use-case.

I for one am really looking forward to my brand new Enter The Dragon solar panels!

No sir it is you that lack understanding... To quote: "The ugly truth about NYC is that it would be ungovernable without a very large and powerful police force"

That is you claiming not an observation but an absolute truth that this is the case. In your world view we require a police state of sorts to make NYC (and other places) workable. Whether you like it or not that is not an absolute truth and ergo an argument to be disputed by those who disagree with your point.

"The lady doth protest too much, methinks"

I believe this as much as I believe every friend of mine who's virus ridden computer I end up cleaning who says "Honestly I didn't click on anything"

There's a lot to not like about Facebook if you so choose to concern yourself with such things but this lady's pants are on fire (in more ways than one) Someone should call the fire department.

This.

Also, as I recall, the whole point of the singularity is that machine intelligence gets to the point of being able to improve upon itself thus starting the improvement loop that goes exponential. This capability only requires a certain kind of "intelligence". Emotions for example are completely unnecessary for building a better engineer :-)

On a related note: Humans are only barely getting to the point of truly being able to build ourselves better so it's hardly strange that we haven't gotten our creations to that point yet. I would like to see the whole philosophy of the singularity applied to these organic machines of ours and see where that goes.

That's why you don't really say "No".

Assuming your boss isn't asking you to do something unethical or illegal, your job is to provide as much information so the best possible decision can be made. SO in this case you will be telling your boss (customer/$$$/etc) everything wrong with what they are telling you to do. If after all of that their decision doesn't agree with your data then it is their liability. You did your due diligence and should document it thoroughly and documentation means you're getting paid either way. If you can sneak in a few tweaks along the way to make the project succeed anyway then good for you... work ethic and all.

If you find yourself in continually failing projects because the person in charge is a dimwit then you start looking for a better employer / customer OR you get really good at justifying how at fault the customer is and you get to keep billing more and more hours for their failed project... that's how government contractors make the big bucks... only suckers settle for the original contract amount ;-)

We don't import ALL of our bridges...

http://en.wikipedia.org/wiki/I...

You're ignoring the quality of the product being sold. There are not enough job titles in our business for me to apply for "X" job and have my salary exactly set on that. Salary bands are too wide and levels too few. I am fully aware of the benefit I provide as an employee and I am going to fight to be compensated as such. I don't work in a field where a shoe is a shoe (as you analogized) and I'm *very happy with that.

...or even more to the point "Tech Support" as support makes *severely less $ than Dev. Every company I've worked at had a severe over balance F/M on the support team.

If the people in the phone pool are included in those numbers then no wonder they look like that.

My current office being an exception... all of the female developers are white but I do live in MN so that's not that rare here.

That being said all of my prior jobs have been as you describe. Specifically Indian (dot not feather) Women seem to dominate the field around here which is statistically strange given the fact Asian Indians are 0.4% of the population (severely on the rise but points of a percent being what they are...)

Honestly it's hard for me to feel bad about the gender mix in our field. From the hiring side I've never seen any preferential treatment for men in hire or pay. If anything we've given women the nod. The problem is there are SO few women in the hiring pool in the first place. If I receive 300 applications for a job and 10 of them are women statistically how likely is it that a woman will get the position? Hell I'll even be explicitly sexist about it: I don't want to work in a sausage factory! I'd personally rather have better scenery in the office but I'm not going to hire a girl who's a bad programmer just because she's the only girl who applied.

Had to pay the price on that one in my last job... boss hired a girl who I did the initial interview with and I told him outright she was not qualified (*Very junior developer being hired for a Senior/Principal position) he hired her anyway and I got the wonderful job of fixing all of her work and in one case completely re-coding an entire failed project of hers. That one example isn't the point more it's not worth it to hire someone based on anything but their ability to get the job done. I like the angle the big tech cos are championing these days: Get more women in the field in general. You give me a 50/50 mix of engineers entering the field and then we can complain if the hiring blend is still 75/25!

I do believe a while ago there was another article that went through here talking about just this issue. Specifically about women's ability to negotiate their salary. An employer is going to try to pay *anyone (regardless of gender or race) as little as possible. If the prospective employee is not going to fight for their salary then they are going to get the least the employer puts on the table.

Here's a loosely related article posted on Dice because hey... it's posted on Dice ;-)

http://news.dice.com/2014/02/0...

Ditto here... I've been getting better at it but she has WAY more control than I do.

Combination of ears skills (hearing your "filter" to know how to adjust it) tongue control (most people don't think that hard about the shape of their tongue at any given point in time... it's a really complex muscle that can do all sorts of interesting precision movements) and breath control (many of the harmonics don't sound right if you don't have the right air pressure behind them too much OR too little)

My last car had interesting acoustics that the front wind shield reflected back my voice exceptionally well so I could really hear what was coming out of my mouth and the harmonics came through really well. Made honing the tones easier. (Good practice sessions on the commute :-)

Generally right.

There's a bit of benefit on the "I don't want to have to do that crap" or "I don't know the right person to talk to but they do" side but when it comes down to it in our field there's a pretty fine line between an Agent and a Recruiter. The big difference being that technically the Recruiter is working for the employer (they get paid from that side not from you) whereas an agent is technically working for you (ergo the skim) but the benefits they provide should balance out to the same in a perfect world.

Honestly I think this is just another company trying to get $ out of the other side of the equation. Not a bad business model since plenty of people will buy into it BUT I honestly don't believe they will do any better at the job so negligible benefit to the person taking 85% of their paycheck.