"Philosophy? Practically useless in the real world."
Sadly you are just too true. Because philosophy's only value is making a gullible consummerist meat bag into a self-concious critical-thinking human being and surely no modern society would want too many of them poking around.
"Or are you skeptical of accepting the results of science"
Well, I think that's part of Feyerabend rant. That there is no such thing as "results of science" but "results of experiments made by people called themselves scientists" and what you call "results of science" is nothing but a common agreement among some individuals (the scientists) that, being humans, are as opened to self-deception or group-thinking as any other one.
But I have to dissent with Feyerabend: science is not vodoo because while I could admit if even for the sake of the discussion scientific proposals being produced basically in the same manner as vodoo, there's the difference that vodoo has nothing more than that while science has its scientific method which allow, if even post-facto, to loosen the chaff from the grain with regards of what really holds explicative value about Nature and what not and why there's a difference.
"If voodoo is true, we should ban dolls. If science is false, DNA evidence shouldn't be allowed in courts."
Uhhh... I think this is more ammunition to Feyerabend than the other way around. What is accepted or not in court is much more a matter of group-thinking than the result of any scientific approach mainly because courts are matters of people, not of theories (Feyerabend thinking that science is a matter of people, not of theories too).
"The conception of "objective truth" is implicit in the conception of "usefully predictive models"."
Don't think so. "usefully predictive models" points to "operative truth" which as different beast. Just "feel" how different "mathematical truth" and "physical truth" resounds. We feel maths to hold objective truth while Physics "only" leads to operative truth. The fact that Euclid can't be disproved while Newton can certainly helps to that.
"Scientists do not relish the idea of wasting their time and effort on things that manifestly don't foster objective understanding."
True. But the fact that there's the scientific expectancy that Nature can be objectively understood doesn't equate to any given theory to be thought as objectively true. If a scientific theory could be deemed as objectively true then it couldn't be disproved (unless Nature changed its behaviour all of a sudden), therefore it wouldn't be a scientific theory.
"No, not really. Since you can only fire someone AFTER they've done something wrong."
True. But if that someone can do something not simply wrong but utterly wrong it's again a management failure because it means a lack of checks and ballances that they should know better to put them there.
"Under AC's dumb plan, they're already liable for millions in fines"
When things go well they're "liable" for millions in bonuses despite of the fact that the "good" comes from a lot of people they neither directly know nor manage. Again, "no pain, no gain": do you want the millionaire bonuses? Expose yourself to millionaire damages.
Current situation is that great benefits and great damages are an emergent property of the system (aka "the company") but senior management want to recall the great benefits for themselves while at the same time deriving the great damages to the system. That's not only unjust but the very reason of things like BP oil spill or last financial crisis happening.
"Exactly; the private sector cannot be trusted to do things safer/more efficiently/better."
Quite on the contrary, you can expect the private sector to do things certainly more efficiently and better, once you understand what's the proper definition of "better" within context. In fact, that's all you can trust the private sector to come with.
Regarding "safer", just apply my previous paragraph: to which extent can "safer" be derived of, or translated into, "more efficiently and better within context"? That's the safety level you can expect, no less no more.
"Excuses that there were too many false positives just means that people needed to fix the false positives instead of ignoring or disabling them!"
While I'm with your overall message, you seem to forget that for this to work, bonuses and penalties need to be aligned; when they are not, things like this are expected to happen.
I.E: I certainly should care about each and every rised alarm, and I'm even told to do so. *But* I'm not payed to take care of rising alarms as soon as I can but to accomplish a different task (like bring up to production an oil rig) by the earliest date, while taking care of rising alarms gets in the middle. Since they both tasks are ireconcillable which one do you think a sensible person (or even a manager) should expect to suffer?
Of course, or there wouldn't be bussiness around it.
"Always triggering the right alarm - and only the right alarm - amounts to creating a system that somehow knows exactly how to handle any situation, no matter how complex."
Wrong. It amounts to getting rid of false asumptions or trying to sell a solution as the magic snake oil that will end all and every problem. Triggering the right alarm and only the right alarm is as easy as:
1) Known situation: manage automatically 2) Unknown situation: rise "human needed" alarm 3) Gather information among the "human needed" risen alarms to extract patterns so more and more situations can be managed by 1).
It only needs the guts from some manager to say "no, sir, we don't know that much about managing this kinds of situations, so it will need a lot of clever, well paid engineers that you will need to listen to as God Himself speech" instead of "Of course it'll be done, sir, in order for you to collect the bonuses".
""You'll have to manage it at the "ego" level, not the tool." You're only addressing a justification for the actual problem which is experimental code paths."
Don't think so. You are either aproved to dive into an experimental code path, in which case you can do it on a branch on a centralized SCM or you are not, in which case you shouldn't hide the fact you are working on it by means of a distributed SCM.
""You give them access to a ACLed branch or you give then a different repo and you use the "vendor branch" pattern to merge it back to your trunk." Are you serious? You want to grant firewall, VPN, internal login-names to an outside firm? You want to maintain customer support of their development environment?"
Did you miss the *or*? If you have problems opening your internal SCM to a partner of you, you use the vendor branch approach (which conceptually, by the way, is exactly what you do when using a distributed SCM).
"In this case, the point is that they go and do their own thing - you require that they use SOME DVCS."
No you don't. *You* need an SCM and the other party needs an SCM. Since you are explicitly firewalling from their process and you are only interested on their results, you don't need to pick up into their developing process but just gain access to the development results (their final/milestone versions).
"svn branch merging can be made to work"
Now you are moving from centralized SCM versus distributed SCM to some tool (subversion) versus some other (git). That's not what we were talking about.
""And you do it just the same with a central than with a distributed source code management system."
Well, not really. The use case of linux is that there are several co-maintained forks."
And now, by ill-quoting you are missrepresenting me. Please notice that in my last paragraph I stated that "What I see once and again is that distributed SCM make sense for community-based open source" so you are saying "not really" to what I already agreed with you.
"Try forking your own company's product. Why would you do such a horrible thing, you might ask?"
I do it day in-day out (while I in fact do ask myself why should I do such a horrible thing. I nod to your arguments and then some more).
"At a minimum, to maintain reconciliation, the CVCS server needs to be common between the two forks"
Not needed while usually benefitial: the "vendor branch" pattern again.
"And just in general, it's nice to have a dedicated VCS per project"
Not. It's just the first idea somebody comes with. And given that most people hasn't the slightest idea about how to properly manage source code (both at the level of programmer and technical project lead) that's what you usually get. And I already stated that one of the biggest benefit that distributed SCMs like git bring to the table is that they have rised concern about the benefits of proper source code management (or even just *some* source code management, whatever).
"once you decide the fork gets it's own CVCS, you're stuck with diff -C5 / patch. "
No, you aren't. Again, have a look at the Cederqvist and its "vendor branch" pattern.
By letting them think that if the win, they win when the reality is that if they loss, they loss but if they win they should return the winnins and face federal charges.
"If you have above a room temperature IQ, you should have some idea that the odds are stacked against you from the very start."
So what? What if you in fact have an above room temperature IQ and you find a within the specs way to leverage those odds that were stacked against you in your favour? I.e.: seeing that a roulette is biased towards some numbers, counting the cards in jackpot, finding a glitch in the slots machines, etc?
The casino already has a fair advantage to start with and simply methods to lessen damage (they patch the bug on the slot machine, they change the failing roulette, they use more card decks, etc.) so why they need federal protection and tax money to rise their odds even more?
"I was hired as R&D manager and I was absolutely terrified when I saw how things were done."
What did you expect? They don't need to advance and they don't need to compete since they are protected by law. They don't need to be careful either, since any mistake is covered for them by law too. It would be idiotic to expend even one uneeded dollar to do things any way better!
"But meanings change and *in this case* there is no valid reason to have that word a part of the story."
Except the "little fact" that that was the way Mark Twain wrote it down.
Remember that a book, or any work of art for that matter is much more than what was conceived by its author and its enrichened by those that get to access it. Maybe Mark Twain didn't mean "nigger" as an offensive word, maybe it could be the case that if Mark Twain wrote it today he would avoid it even, but the fact that now the book can be seen with new eyes and that new lessons can be extracted from its read does nothing but increment its value.
USA is a country that a day not so long ago treated some of its fellow countrymen like beasts and fortunately does it no more. This book gives the chance to learn it and learn out of it: don't disallow your new generations of this treasure.
And that's exactly the problem, my friend. Too many people round here seem to imply that "deferred it maintenance" means not replacing servers when the guarantee period ends up. But maintenance means having two sysadmins when you formerly had three or maintaining the three sysadmins when capacity has grown 50%. Lowering maintenance costs means that it has been a year that nobody has the time for a test restore so nobody has noticed that the backups are failing since six months ago because a minor glitch in the tape reader. Lowering maintenance means that your sysadmins have no time to "play" with new agile or devops concepts and tools that would allow for safer and more effective practices and that their knowledge is rusting with time so you are more dependant on external consultors that will squeeze money out your nose.
"The point of using "the cloud" (a hollow buzzword, I admit) is that you can offload the servers, software, and maintenance to a firm that specializes in such things."
Yes, because it's a demonstrated hard fact that those companies providing infrastructure for the cloud can't lower their operational costs by neglecting maintenance; of course they wouldn't do that anyway since it's those infrastructure companies' very valuable data what is at risk if maintenance is neglected instead of their customers'.
"The fact of the matter is, if you REALLY wanted to change something, you would have to do the work yourself. You may have to do it in your own time at times. Anything else is...well...just complaining."
So when my boss comes to my place and tells me what should I do, or why should I do something this way instead of this other he is just... well... complaining because he won't do it by himself?
I get news for you:
1) Teamwork is about getting others doing things you can't or won't do by yourself to achieve a greater goal. That's not complanining.
2) When somebody is hired for a 40 hours/week worth of work and such somebody is already properly fulfilling his 40 hours/week out of designated work, pointing out how things could be rationalized even if there's no time to do it oneself, that's not complaining.
"You probably don't know the whole story so all your great ideas are not as helpful as you think."
The "we are not Einsteins nor we know everything" goes both ways.
How can a person that "offered ideas, constructively and logically, on why Item X is flawed, and how following Strategy Y we could fix Item X to no detriment to Company_Standing Z" be not helpful, even if he is utterly wrong?
How can be the proper behaviour from management "It was ignored. Not discussed and dissected and rejected, not tried and failed, not anything but pure "la la la we can't hear you" bullshit.", again, even if he was utterly wrong?
Provided he is in fact intelligent, how could it be any worse to enlighten him so he could see by himself why his ideas wouldn't work so he either shuts up or next time he comes with better ideas -or if he persists in his behaviour you will know he is not an Heretic, he is not even clever but just a kneejerk so you can fire him without hesitation.
"False. Very false. It's human nature to think, "Everybody else is a moron and I could do better." The fact of the matter is that EVERYBODY thinks that and you are everybody else to everybody else."
He could be right or wrong, but since your arguments have nothing to do with Hatta's argument you get immediately included in the "not so smart group".
The a priori was INTELLIGENT people making a CONVINCING case about the company being HOPELESSLY mismanaged by a bunch of MORONS (emphasys mine).
It is not about ranting; it is not about minor flaws; it is not about not seeing 360 degrees around; it is not about doing nothing about it.
I'm with Ben Horowitz that this kind of "Heretic" can be demoralizing but certainly the way to deal with him is much more about fixing management than fixing him.
"the Heretic only THINKS they can do a better job on their own."
On one hand, by Horowitz's definition, the Heretic is not about knowing (or think to know) how to do a better job but pointing out how and why management is doing such a bad job; in the other, again by Horowitz's definition, it's not only that the Herectic "thinks this or that" but that being intelligent thinks this or that and he is able to articulate his ideas in such a way that manages to convince others that he is right.
Being such a clever person, he will know he doesn't know all and when even then, he can make a convincing case, bets are that the horrible problems he foresees (remember, the Heretic is not about minor inefficencies but about the company being hopelessly run by a bunch of morons) are for real. Of course, if management is indeed a bunch of hopeless morons they either won't listen or won't act properly to resolve the situation.
And, of course too, being the Heretic such an intelligent person, he will be ranting if he can't stand the situation but, at the same time he will be looking for an exit, so the problem tends to correct itself (the Heretic either goes away or is fired -even once out of a million, he will be listened, the situation corrected and he will stop being Heretic).
"Well I'm glad they officially fixed the kernel lock. Out of curiosity, how long until Ubuntu or Debian sees this integrated into their line?"
Don't know about Ubuntu but since Debian is already "frozen" towards its next release (codename "squeeze") you can bet it will be about two years from now, more or less.
Of course, you will see it much sooner on their development lines, "Testing", "Unstable" and/or "Experimental".
"There's something to be said for 'bad' use of DVCS in a private company. But here are the good usage patterns IHMO"
Maybe. But all you provided are good usage patterns for *any* source code manager, distributed or not. And even then you are pushing for some bad practices as if they were good. In example:
"I want to experiment with an alternate code path (but don't want to deal with the politics - remeber coders have egos"
You'll have to manage it at the "ego" level, not the tool. You are either allowed to "wander" your ideas, and then you do it within the central repository (for the manager to know what are you doing and for other members of the team to know why it failed when needed -if it was worth it, it eventually would have been merged to main line), or you are not allowed, in which case you don't do it.
"Let's say we suck at graphics, so we outsource to a 3rd party company. How the hell does this happen with central version control."
You give them access to a ACLed branch or you give then a different repo and you use the "vendor branch" pattern to merge it back to your trunk.
"ok, these feature-branches should all be thrown away - lets 'rebase' to produce a pristine trunk and quite literally throw away all the branches by flattening them."
Read the user manual for, say, Subversion. You probably will be surprised.
"central 'owner'/'maintainer' of a given project."
That's why you want a promotion manager (usually near to or the same person than the project's technical lead). You want the authorized/knowledgeable one to be the one "building" your master/production builds and that's easier with a central repo than with distributed ones.
"as with linux, for larger projects development-teams, you can have lieutenants that perform step 7 for sub-sections of the larger project."
And you do it just the same with a central than with a distributed source code management system.
What I see once and again is that distributed SCM make sense for community-based open source projects and they have raised a feeling for best practices on developers but still, central SCM tools are better suited for "usual" corporate development.
Slashdot Mirror
"Maybe they're longing to be real pirates."
Maybe they were just sitting in the dock of the bay wasting time.
"Philosophy? Practically useless in the real world."
Sadly you are just too true. Because philosophy's only value is making a gullible consummerist meat bag into a self-concious critical-thinking human being and surely no modern society would want too many of them poking around.
"Or are you skeptical of accepting the results of science"
Well, I think that's part of Feyerabend rant. That there is no such thing as "results of science" but "results of experiments made by people called themselves scientists" and what you call "results of science" is nothing but a common agreement among some individuals (the scientists) that, being humans, are as opened to self-deception or group-thinking as any other one.
But I have to dissent with Feyerabend: science is not vodoo because while I could admit if even for the sake of the discussion scientific proposals being produced basically in the same manner as vodoo, there's the difference that vodoo has nothing more than that while science has its scientific method which allow, if even post-facto, to loosen the chaff from the grain with regards of what really holds explicative value about Nature and what not and why there's a difference.
"If voodoo is true, we should ban dolls. If science is false, DNA evidence shouldn't be allowed in courts."
Uhhh... I think this is more ammunition to Feyerabend than the other way around. What is accepted or not in court is much more a matter of group-thinking than the result of any scientific approach mainly because courts are matters of people, not of theories (Feyerabend thinking that science is a matter of people, not of theories too).
"The conception of "objective truth" is implicit in the conception of "usefully predictive models"."
Don't think so. "usefully predictive models" points to "operative truth" which as different beast. Just "feel" how different "mathematical truth" and "physical truth" resounds. We feel maths to hold objective truth while Physics "only" leads to operative truth. The fact that Euclid can't be disproved while Newton can certainly helps to that.
"Scientists do not relish the idea of wasting their time and effort on things that manifestly don't foster objective understanding."
True. But the fact that there's the scientific expectancy that Nature can be objectively understood doesn't equate to any given theory to be thought as objectively true. If a scientific theory could be deemed as objectively true then it couldn't be disproved (unless Nature changed its behaviour all of a sudden), therefore it wouldn't be a scientific theory.
"No, not really. Since you can only fire someone AFTER they've done something wrong."
True. But if that someone can do something not simply wrong but utterly wrong it's again a management failure because it means a lack of checks and ballances that they should know better to put them there.
"Under AC's dumb plan, they're already liable for millions in fines"
When things go well they're "liable" for millions in bonuses despite of the fact that the "good" comes from a lot of people they neither directly know nor manage. Again, "no pain, no gain": do you want the millionaire bonuses? Expose yourself to millionaire damages.
Current situation is that great benefits and great damages are an emergent property of the system (aka "the company") but senior management want to recall the great benefits for themselves while at the same time deriving the great damages to the system. That's not only unjust but the very reason of things like BP oil spill or last financial crisis happening.
"I know this is not a popular opinion here, but sometimes the "peon" implementing the system actually is lazy and useless."
Still his manager's fault for not firing him on the spot.
"You're advocating making senior management pay for the actions of an employee they probably never met."
Senior management advocate they should get bonuses for the actions of all those employees they probably never meet so it's just tit-for-tat.
Does it seem a little wrong to call it an 'IT system'? Control system, SCADA, or embedded system maybe, but "IT?"
Was not Information moving around? Was not that Information moving around by Technical means?
Automatic control systems are IT, Supervisory Control And Data Acquisition systems are IT, signaling embedded systems are IT.
" We dont want to replace anyone but we -do- want to add more barriers!"
Who is "we"? For all that matters, the manager is not part of "we": all he wants is his bonuses.
"Exactly; the private sector cannot be trusted to do things safer/more efficiently/better."
Quite on the contrary, you can expect the private sector to do things certainly more efficiently and better, once you understand what's the proper definition of "better" within context. In fact, that's all you can trust the private sector to come with.
Regarding "safer", just apply my previous paragraph: to which extent can "safer" be derived of, or translated into, "more efficiently and better within context"? That's the safety level you can expect, no less no more.
"Excuses that there were too many false positives just means that people needed to fix the false positives instead of ignoring or disabling them!"
While I'm with your overall message, you seem to forget that for this to work, bonuses and penalties need to be aligned; when they are not, things like this are expected to happen.
I.E: I certainly should care about each and every rised alarm, and I'm even told to do so. *But* I'm not payed to take care of rising alarms as soon as I can but to accomplish a different task (like bring up to production an oil rig) by the earliest date, while taking care of rising alarms gets in the middle. Since they both tasks are ireconcillable which one do you think a sensible person (or even a manager) should expect to suffer?
"Easier said than done."
Of course, or there wouldn't be bussiness around it.
"Always triggering the right alarm - and only the right alarm - amounts to creating a system that somehow knows exactly how to handle any situation, no matter how complex."
Wrong. It amounts to getting rid of false asumptions or trying to sell a solution as the magic snake oil that will end all and every problem. Triggering the right alarm and only the right alarm is as easy as:
1) Known situation: manage automatically
2) Unknown situation: rise "human needed" alarm
3) Gather information among the "human needed" risen alarms to extract patterns so more and more situations can be managed by 1).
It only needs the guts from some manager to say "no, sir, we don't know that much about managing this kinds of situations, so it will need a lot of clever, well paid engineers that you will need to listen to as God Himself speech" instead of "Of course it'll be done, sir, in order for you to collect the bonuses".
'No-one apart from JRA and our supplier knows which intersections have that system.'
That's their defense regarding how they managed this not to happen? Security through obscurity? Really? Does people never learn?
""You'll have to manage it at the "ego" level, not the tool."
You're only addressing a justification for the actual problem which is experimental code paths."
Don't think so. You are either aproved to dive into an experimental code path, in which case you can do it on a branch on a centralized SCM or you are not, in which case you shouldn't hide the fact you are working on it by means of a distributed SCM.
""You give them access to a ACLed branch or you give then a different repo and you use the "vendor branch" pattern to merge it back to your trunk."
Are you serious? You want to grant firewall, VPN, internal login-names to an outside firm? You want to maintain customer support of their development environment?"
Did you miss the *or*? If you have problems opening your internal SCM to a partner of you, you use the vendor branch approach (which conceptually, by the way, is exactly what you do when using a distributed SCM).
"In this case, the point is that they go and do their own thing - you require that they use SOME DVCS."
No you don't. *You* need an SCM and the other party needs an SCM. Since you are explicitly firewalling from their process and you are only interested on their results, you don't need to pick up into their developing process but just gain access to the development results (their final/milestone versions).
"svn branch merging can be made to work"
Now you are moving from centralized SCM versus distributed SCM to some tool (subversion) versus some other (git). That's not what we were talking about.
""And you do it just the same with a central than with a distributed source code management system."
Well, not really. The use case of linux is that there are several co-maintained forks."
And now, by ill-quoting you are missrepresenting me. Please notice that in my last paragraph I stated that "What I see once and again is that distributed SCM make sense for community-based open source" so you are saying "not really" to what I already agreed with you.
"Try forking your own company's product. Why would you do such a horrible thing, you might ask?"
I do it day in-day out (while I in fact do ask myself why should I do such a horrible thing. I nod to your arguments and then some more).
"At a minimum, to maintain reconciliation, the CVCS server needs to be common between the two forks"
Not needed while usually benefitial: the "vendor branch" pattern again.
"And just in general, it's nice to have a dedicated VCS per project"
Not. It's just the first idea somebody comes with. And given that most people hasn't the slightest idea about how to properly manage source code (both at the level of programmer and technical project lead) that's what you usually get. And I already stated that one of the biggest benefit that distributed SCMs like git bring to the table is that they have rised concern about the benefits of proper source code management (or even just *some* source code management, whatever).
"once you decide the fork gets it's own CVCS, you're stuck with diff -C5 / patch. "
No, you aren't. Again, have a look at the Cederqvist and its "vendor branch" pattern.
"no insurrection is not refusal to obey federal government"
No, it isn't. But refusal to obbey federal government to the last consequences *is* insurrection.
"The real definition of insurrection: A violent uprising against an authority or government"
QED.
"How have casinos been stealing from people?"
By letting them think that if the win, they win when the reality is that if they loss, they loss but if they win they should return the winnins and face federal charges.
"If you have above a room temperature IQ, you should have some idea that the odds are stacked against you from the very start."
So what? What if you in fact have an above room temperature IQ and you find a within the specs way to leverage those odds that were stacked against you in your favour? I.e.: seeing that a roulette is biased towards some numbers, counting the cards in jackpot, finding a glitch in the slots machines, etc?
The casino already has a fair advantage to start with and simply methods to lessen damage (they patch the bug on the slot machine, they change the failing roulette, they use more card decks, etc.) so why they need federal protection and tax money to rise their odds even more?
"If you knew that a roulette table hit a particular number commonly enough to make the odds worth it, you'd play that table."
And then the casino would press federal charges against you so they can stay in bussiness without the inconvenience of having to use proper tools.
Which is exactly what this news is about.
"I was hired as R&D manager and I was absolutely terrified when I saw how things were done."
What did you expect? They don't need to advance and they don't need to compete since they are protected by law. They don't need to be careful either, since any mistake is covered for them by law too. It would be idiotic to expend even one uneeded dollar to do things any way better!
"But meanings change and *in this case* there is no valid reason to have that word a part of the story."
Except the "little fact" that that was the way Mark Twain wrote it down.
Remember that a book, or any work of art for that matter is much more than what was conceived by its author and its enrichened by those that get to access it. Maybe Mark Twain didn't mean "nigger" as an offensive word, maybe it could be the case that if Mark Twain wrote it today he would avoid it even, but the fact that now the book can be seen with new eyes and that new lessons can be extracted from its read does nothing but increment its value.
USA is a country that a day not so long ago treated some of its fellow countrymen like beasts and fortunately does it no more. This book gives the chance to learn it and learn out of it: don't disallow your new generations of this treasure.
"Assuming you are doing backups"
And that's exactly the problem, my friend. Too many people round here seem to imply that "deferred it maintenance" means not replacing servers when the guarantee period ends up. But maintenance means having two sysadmins when you formerly had three or maintaining the three sysadmins when capacity has grown 50%.
Lowering maintenance costs means that it has been a year that nobody has the time for a test restore so nobody has noticed that the backups are failing since six months ago because a minor glitch in the tape reader. Lowering maintenance means that your sysadmins have no time to "play" with new agile or devops concepts and tools that would allow for safer and more effective practices and that their knowledge is rusting with time so you are more dependant on external consultors that will squeeze money out your nose.
"The point of using "the cloud" (a hollow buzzword, I admit) is that you can offload the servers, software, and maintenance to a firm that specializes in such things."
Yes, because it's a demonstrated hard fact that those companies providing infrastructure for the cloud can't lower their operational costs by neglecting maintenance; of course they wouldn't do that anyway since it's those infrastructure companies' very valuable data what is at risk if maintenance is neglected instead of their customers'.
Oh, wait!
"The fact of the matter is, if you REALLY wanted to change something, you would have to do the work yourself. You may have to do it in your own time at times. Anything else is...well...just complaining."
So when my boss comes to my place and tells me what should I do, or why should I do something this way instead of this other he is just... well... complaining because he won't do it by himself?
I get news for you:
1) Teamwork is about getting others doing things you can't or won't do by yourself to achieve a greater goal. That's not complanining.
2) When somebody is hired for a 40 hours/week worth of work and such somebody is already properly fulfilling his 40 hours/week out of designated work, pointing out how things could be rationalized even if there's no time to do it oneself, that's not complaining.
"You probably don't know the whole story so all your great ideas are not as helpful as you think."
The "we are not Einsteins nor we know everything" goes both ways.
How can a person that "offered ideas, constructively and logically, on why Item X is flawed, and how following Strategy Y we could fix Item X to no detriment to Company_Standing Z" be not helpful, even if he is utterly wrong?
How can be the proper behaviour from management "It was ignored. Not discussed and dissected and rejected, not tried and failed, not anything but pure "la la la we can't hear you" bullshit.", again, even if he was utterly wrong?
Provided he is in fact intelligent, how could it be any worse to enlighten him so he could see by himself why his ideas wouldn't work so he either shuts up or next time he comes with better ideas -or if he persists in his behaviour you will know he is not an Heretic, he is not even clever but just a kneejerk so you can fire him without hesitation.
"False. Very false. It's human nature to think, "Everybody else is a moron and I could do better." The fact of the matter is that EVERYBODY thinks that and you are everybody else to everybody else."
He could be right or wrong, but since your arguments have nothing to do with Hatta's argument you get immediately included in the "not so smart group".
The a priori was INTELLIGENT people making a CONVINCING case about the company being HOPELESSLY mismanaged by a bunch of MORONS (emphasys mine).
It is not about ranting; it is not about minor flaws; it is not about not seeing 360 degrees around; it is not about doing nothing about it.
I'm with Ben Horowitz that this kind of "Heretic" can be demoralizing but certainly the way to deal with him is much more about fixing management than fixing him.
"the Heretic only THINKS they can do a better job on their own."
On one hand, by Horowitz's definition, the Heretic is not about knowing (or think to know) how to do a better job but pointing out how and why management is doing such a bad job; in the other, again by Horowitz's definition, it's not only that the Herectic "thinks this or that" but that being intelligent thinks this or that and he is able to articulate his ideas in such a way that manages to convince others that he is right.
Being such a clever person, he will know he doesn't know all and when even then, he can make a convincing case, bets are that the horrible problems he foresees (remember, the Heretic is not about minor inefficencies but about the company being hopelessly run by a bunch of morons) are for real. Of course, if management is indeed a bunch of hopeless morons they either won't listen or won't act properly to resolve the situation.
And, of course too, being the Heretic such an intelligent person, he will be ranting if he can't stand the situation but, at the same time he will be looking for an exit, so the problem tends to correct itself (the Heretic either goes away or is fired -even once out of a million, he will be listened, the situation corrected and he will stop being Heretic).
"Well I'm glad they officially fixed the kernel lock. Out of curiosity, how long until Ubuntu or Debian sees this integrated into their line?"
Don't know about Ubuntu but since Debian is already "frozen" towards its next release (codename "squeeze") you can bet it will be about two years from now, more or less.
Of course, you will see it much sooner on their development lines, "Testing", "Unstable" and/or "Experimental".
"There's something to be said for 'bad' use of DVCS in a private company. But here are the good usage patterns IHMO"
Maybe. But all you provided are good usage patterns for *any* source code manager, distributed or not. And even then you are pushing for some bad practices as if they were good. In example:
"I want to experiment with an alternate code path (but don't want to deal with the politics - remeber coders have egos"
You'll have to manage it at the "ego" level, not the tool. You are either allowed to "wander" your ideas, and then you do it within the central repository (for the manager to know what are you doing and for other members of the team to know why it failed when needed -if it was worth it, it eventually would have been merged to main line), or you are not allowed, in which case you don't do it.
"Let's say we suck at graphics, so we outsource to a 3rd party company. How the hell does this happen with central version control."
You give them access to a ACLed branch or you give then a different repo and you use the "vendor branch" pattern to merge it back to your trunk.
"ok, these feature-branches should all be thrown away - lets 'rebase' to produce a pristine trunk and quite literally throw away all the branches by flattening them."
Read the user manual for, say, Subversion. You probably will be surprised.
"central 'owner'/'maintainer' of a given project."
That's why you want a promotion manager (usually near to or the same person than the project's technical lead). You want the authorized/knowledgeable one to be the one "building" your master/production builds and that's easier with a central repo than with distributed ones.
"as with linux, for larger projects development-teams, you can have lieutenants that perform step 7 for sub-sections of the larger project."
And you do it just the same with a central than with a distributed source code management system.
What I see once and again is that distributed SCM make sense for community-based open source projects and they have raised a feeling for best practices on developers but still, central SCM tools are better suited for "usual" corporate development.