anthonyb

eg. on p25 McConnell lists project outcomes by project size:

   1000 LOC -> 81% on time, 4% late, 2% cancelled
   10,000,000 LOC -> 14% on time, 21% late, 65% cancelled

Also notice that McConnell uses terms like "Approved Product Definition" and "Requirements Complete". It's a rare project, particularly in the consulting world, that can nail down requirements to the degree that you get really accurate estimates. For packaged software products it's doable, for other things, not so much.

Plus other people have already made (bad) decisions and started working on stuff that (negatively) affects you because you were busy "head-down working".

These are the problems that stand ups are supposed to help fix.

If you're leaving a paper trail that management can go back through (even in theory), then it will get sanitised, and people will try and make themselves look good. The further you get from reality, the more value your "stand ups" will lose.

There's a good reason for the "pigs and chickens" analogy.

Even just a heads up that something important is coming down the line can save you hours or days of work "Oh, I thought you were cc'ed in on that email..."

> If some one is good, they will win anyway. If they are not, they can't and won't.

The conclusion from that is that the lack of women in tech is because they're not very good at it. If women were good at tech, then from his statement there would be more of them (they would "win anyway").

This is clearly absurd - hence he's wrong, or at least needs to support/make his argument a little better.

Do I really need to stick </sarcasm> tags on everything?

"Reservations" or whatever you want to call them are lowering the bar to the same level as other people, but of course the "B"s are going to scream blue murder because they now have to work instead of cruising.

http://braythwayt.com/2013/04/01/quote-metritocracy-unquote....

http://www.timeshighereducation.co.uk/comment/columnists/eli...

Say that you put out a call for conference papers, but due to a bug in your mailing list software, only every other email is sent - 50% of potential participants are excluded. What do you think will happen to the quality of your conference?

Now let's say you find the bug after you've decided on your talk schedule. Should you should fix the bug and include the 50% of papers that you've missed? Isn't that unfair to the people who've already been selected?

The basic answer to that is that they're not - if you know someone who stutters, I would like to think that you'd encourage them to present at a conference if they had something valuable to present.

However, imagine that that conference is a brofest - they're not going to feel very included, are they? Bros are assholes after all, and they probably won't want to participate if they feel that they're going to be mocked or not listened to.

Well spotted. The point is that the status quo is a choice, just as being more inclusive is a choice. Which is the better choice?

And your post has a couple of assumptions that I feel compelled to point out:

1. That including people from a more diverse background will lead to inferior talks.

2. That conferences include talks based on some absolute value of merit.

3. That conferences are so amazing that everyone wants to go to them.

> What would qualify as "more than a lip service effort", exactly?

Something more than "We didn't get lots of women applicants for talks, so we have 100% white males."

That's the context of the article - some speakers are exercising their right not to participate on panels or give talks unless the conference makes more than a lip service effort to include people who aren't 30 year old white males.

There's not much controversy there, and like it or not, most people feel the same way.

> did the person believe they had the skills and expertise to submit?

These reasons are exactly why quota systems are used.

If there isn't anyone from your particular group at a highly demanding conference panel, or visible in your industry, you're much less likely to become a part of it... even though you're more than capable of performing at that level if you put the time in.

Fixing existing code after it's already in the code base is a losing battle (particularly since it usually has to be re-tested), and you'll get pulled off onto "more important work".

And it's not a kludge, it's a very good way of improving code quality (possibly up to the union of your better programmers' skills) and preventing dodgy crap from seeing the light of day.

> Anything that prevents me from doing my job (shipping code) is going to cost the company money.

I think you meant "working code" there - where "working" means "solves business problems" as wells as "not buggy" ;)

Just because they're learning to code, doesn't mean that you should put artificial hurdles in front of them.

For accounting purposes though, it's $10.

If I have a car to drive to work, then I should be able to claim some proportion of it as a deduction. Currently that's not allowed (at least in Australia, where I'm from).

Also, I don't know many professional programmers who type everything in by hand. It'll be something copied from a previous project, or cribbed from the documentation / somewhere online, then hacked into shape.

Of course, in order to do any of that you need to understand what's going on, but there might be easier ways to do that than manually typing in code.

I'm not saying "I have this message from a recruiter, therefore all recruiters are scum." It's a reminder.