...and in addition, Sauron is really a phenomenally talented and intelligent captain of industry, but all evil and woe is his responsibility in the eyes of those less-intelligent plebes who hate anyone or anything aspiring to individual greatness. In response, he has withdrawn himself to the land of Mordor, wilfully refusing to support the less worthy with his own talents. Untroubled by other cares, he is working on an even more powerful and effective ring of power; the one he used before was just a prototype. He awaits the inevitable collapse of a society rooted in self-delusion and will return after this, along with those other individuals capable of returning Middle Earth to it's rightful greatness.
In reality, LOTR is a hack job by some guy named Toohey. Got it all wrong, he did.
One other thing I forgot to mention, per your post...
It will be a rare day indeed when anyone (coder, manager, stockboy, whoever) will, of their own initiative, approach you and ask for help, particularly in the context of "Oh my God, I'm running behind and need some guidance!". You'll need to ride herd on your teams progress and be prepared to point out to a team memberthat help may be needed, and be responsible for organizing that help, even if you yourself aren't the source of it. More work for you, unfortunately, but if you depend on others to self-identify, you will be regularly burned.
You're in a bit of a thankless position, needing to be both a developer and a project manager simultaneously. It's a tough slog and I can't think of any easy advice to give you.
A couple things to hopefully help your future projects:
You will need to define expectations to your co-workers in advance and in as much detail as feasible. Simply saying "we need to be done on day [x]" obviously ain't going to cut it. This involves a couple responsibilities: a) identifying appropriately detailed descriptions of expectations for each team member, and b) constructing a task list at a level of detail allowing concise definition of each task and being frequently reviewable in a meaningful way.
My personal experience is that any task with a duration of more than 2 days or so is too high level to track meaningfully--you'll have to subdivide these tasks into smaller units of time so that you can reach a meaningful agreement with your developers on what exactly is to be done and when it needs to happen. You may feel comfortable with longer or shorter ceilings. Just remember: you'll be reviewing every task frequently--make sure what's on the list is meaningfully reviewable by you.
More painfully, you will need to budget time into your daily routine to ensure the "pebbles" (like milestones, only smaller --not my term, unfortunately, but I can't remember who I first heard coin it) are being met on a daily basis. A basic rule of project management--surprises are bad things. The earlier you're aware of slippage, the more leeway you have to do something about it.
Since you'll need time to monitor and review progress your own task timelines will need to reflect this. Never forget to do this, and make sure the project owner is aware of why your tasks seem to require more calendar time than other developers. You are not a 100% coding resource!
You will need to be willing to address developers who are lagging. More specifically, you need to address them as soon as you notice tasks lagging. This isn't the easiest or most enjoyable part of the job. Note that ( "address" != rip a new anterior orifice ) What is does mean is that you will need to take the initiative to: a) identify lagging tasks, b) contact the developer or developers responsible for the task, c) determine why the slip occurred, d) identify a solution and e) follow up to ensure the solution was implemented.
None of the above is rocket science, of course. But all of it involves behavior modifications for most people. Addressing developers who are lagging in particular is sticky, since you have to be prepared for pretty much anything and any reaction and you need a lot of self-confidence to not feel nervous about initiating this contact. And, in addition, you yourself will have to change your daily work habits to some degree and be willing to commit to those changes--and this can be the hardest part of all.
AOL, MSN, et al realize Gartner's claims of 50% per-annum growth are typical Gartner "pick-a-number" crap.
AOL, MSN, et al bail out of IM market like rats from a sinking ship after realizing there's no "competitive advantage" to be realized from setting the Joe Sixpack IM standard. Move onto Next Big Thing technology. Joe Sixpack moves with them. No one cares about IM anymore. Everyone realizes the phone wasn't such a lousy idea after all.
Unification? Who needs unification? Does anybody actually use this stuff anymore?
Re:Just because you _can_ doesn't mean you _wanna_
on
Managing Einsteins
·
· Score: 1
Management needs to do a better job of understanding why programmers and techies often seem to resentful when being assigned projects
I would respond that programmers and techies who feel this way need to do a better job of understanding why something which may seem boring/trivial to them may hold value for the business as a whole.
Not saying that all projects are good simply because someone thinks they are--Lord knows there are plenty of DOA projects spawned out of ego gratification or politics (and I've worked/managed my share of them). But I see a amazing number of developers who have no interest in even trying to evaluate the business rationale of a decision if they sense the decision consequences pushing them out of their personal comfort zones.
You might be right--the project might be stupid, meaningless, doomed to fail and a waste of time and resources. But it isn't guaranteed to be these things simply because it doesn't interest you.
it is a sign of bad management that ignores those types of hesitations and flies on the basis of what is 'techically possible' alone.
Don't know what employers you've worked for, but my experience is the opposite. Little seems to be done simply because it can be done. Lots is not done because the risks (real or falsely perceived) of doing so seems disportionate measured against the gains (real or falsely perceived) of a successful outcome.
I'd say a more useful tactic would be for tech types who agree with your sentiments to learn how to convince their company chiefs: a) technical choice 'X' is a good|bad decision for the company and b) why is is so, in quantifiable terms that the chief can understand. This is not a simple or singular skill, of course--it involves lots of peoplework, negotiations, occasionally losing battles to win wars, and learning to explain your opinion in a seemingly foreign language of finance and management. But, IMHO, that seems a lot less stressful than sitting around all day resenting the stupidity of your management.
Or, you can run your own company and do whatever you want. Just remember: the onus is on you to convince someone that what you're doing is interesting/useful enough to warrant your getting paid for it. See above discussion on negotiation,peoplework, etc.
Gifts don't come with the same implied warranty that purchases do.
Money doesn't imply a warranty. Nor does any other form of consideration. The claims of the provider are the basis for any warranty. If I expressly claim that my product does "x", I have potentially set an expectation of performance in the mind of any potential user. My willingness to allow the product to be used without requiring monetary consideration does nothing to change that expectation.
The only exception I'd see to this would be in you intended to hurt someone. At this point I think you could be charged with fraud. You desired an outcome and deceived someone to those ends. Cash doesn't necessarily have to change hands for this charge to stick.
But we're not just talking fraud in this discussion, we're talking about liability in general. One can be perfectly straightforward in advertising a product's capabilities, honest to the best of one's understanding and still be liable for the product's failure to perform to those capabilities. Fraud is a very small portion of the legal exposure iceberg.
I really don't see why this doesn't make sense... To believe otherwise seems similar to supporting the family who sued the volunteer search & rescue team who failed to find their son. The volunteers offered to help, they didn't guarantee results. If their help is useless, it's worth what you paid.
I've never heard about this case, but in any event, your post answers itself:
The volunteers offered to help, they didn't guarantee results
It is the disclaimer of performance which should insulate the volunteers, not the fact that they volunteered to look. Sure, their willingness to do so reflects well on them as human beings. But had they told the family "we WILL find your son and, furthermore, we guarantee that we will", they've set up a expectation of performance and could (theoretically) expect exposure.
This is why terms of use licenses in software go into such mind-numbing detail stating that their products are NOT warranted fit for almost any task. This disclaimer provides an affirmative defense in the case of liability proceedings.
Yet, US law supports this shit, so likely your interpretation would pass, especially since the big companies love it.
Actually it is this inability to hide behind blanket protection clauses that keeps most corporate legal departments in steady employment, as opposed to doing something really useful with their time. Joe Sixpack may file a negligence/liability suit against a product provider at any time if he feels the product/service has set an expectation of performance and failed to deliver. Whether or not he's right is a question for the courts. But he always has recourse to legal evaluation of his claim. And the possibility of lawsuits coming from any one of thousands or millions of product users drives most businesses absolutely nuts.
Contrary to your assertion, I would say it is your proposed blanket protection that most business would welcome. I can just envision the hoops most companies would jump through to escape costly negligence trials by claiming that "no consideration" was received for use of their product.
And as for not being able to sue just because you didn't pay... Why should you be able to sue if you got something for free? If I give you a stereo and it breaks, should you be able to sue me for a working stereo?
The consideration (or lack of it) exchanged between obtainer and supplier of a component is irrelevant, IMO. What is of interest is the discrepancy between what it's claimed and actual functionality.
Put more simply: why should my expectations of your hypothetical network code be different based on whether or not I'm paying for it? What magical quality does money provide such that the lack of a purchase price provides it's developers blanket insulation from negligence/fraud proceedings?
A scenario for you:
I, out of the goodness of my heart, design and implement, say, an embedded system for use in medical equipment.
I release the code under one of the various open source licenses. I also claim, in my description of the system, that it is tested and ready for use in a piece of hardware (true, to the best of my knowledge).
An equipment manufacturer uses the system code in one of their monitors.
I have limited knowledge of the various margin conditions such devices need to be aware of on their stream inputs. Due to this, the error checking is not as robust as it needs to be for use in such a system. I've done the best job I was capable of doing, but it isn't enough.
Hooked up to one of these manufacturer's devices, a patient dies because a systemic failure is not properly detected.
Am I as the developer off the hook for a potential negligence tort, even despite my claim of the software's readiness, simply because no money changed hands between myself and the equipment manufacturer?
If they paid someone else for a component which is shown to be defective, then they sue that person/company themselves.
...who sues the person/entity that they paid for access to the component...Repeat ad nauseam
Also, since ultimately someone will have written/obtained the component without a financial transation taken place, wouldn't this system ultimately collapse when people run out of targets to "pass the buck" to?
Dunno--this sounds more like the full employment act for the legal profession than a useful protection for an end user. Not that the legal profession needs that much more help...
If you didn't pay for it, you don't get to sue.
So someone who didn't pay for something has no recourse in the event of damages related to negligence in the development of the component? And someone who did pay does? Why would you allow/deny legal protection based on whether or not a checkbook was involved?
Er, just which individual(s) do you name as defendant on a tort involving an open source system? The original author(s)? The current change control administrator? The change control administrator responsible for the supposedly negligent version? The developer who last patched a negligent module? Everyone who ever had contact with the system? None of the above?
Congrats Taco; fondest hopes for many happy years together.
One concern: if everyone thinks the/. spelling/grammar is bad now, just wait a few years until a bunch of little Tacos (taquitos?) are helping out with the site editing chores...
If I'm interpreting this correctly (and IANAL), seems that the judge agrees that the statute requiring open access to the depositions doesn't apply in this circumstance. In fact, the judge seems to be requiring MS to do the heavy lifting demonstrating why the media should be excluded from a particular deposition. My guess would be that MS's legal team will concentrate on sealing any depositions of the big guns (pretty much anybody above product manager level, or whatever the equivalent is at MS), so that they don't experience a repeat of the Gates video debacle. The small fry will be left open, but they probably won't offer anything we haven't already heard.
In any event, I'm not sure what the flap is about even if some/all depositions are closed. The judge can only consider what is actually presented to her as formal evidence (which will end up being a subset of the deposition material IMHO). Deposition transcripts entered as evidence will be available to the public.
Besides, it's not like the technical/media community is suffering from a shortage of "Two-fisted MS business strategy" stories right now anyway...
Slashdot Mirror
http://www.postgresql.org
...and in addition, Sauron is really a phenomenally talented and intelligent captain of industry, but all evil and woe is his responsibility in the eyes of those less-intelligent plebes who hate anyone or anything aspiring to individual greatness. In response, he has withdrawn himself to the land of Mordor, wilfully refusing to support the less worthy with his own talents. Untroubled by other cares, he is working on an even more powerful and effective ring of power; the one he used before was just a prototype. He awaits the inevitable collapse of a society rooted in self-delusion and will return after this, along with those other individuals capable of returning Middle Earth to it's rightful greatness.
In reality, LOTR is a hack job by some guy named Toohey. Got it all wrong, he did.
Accurate so far?
Could 20K well-armed Libertarians take out Saddam's Republican guard?
Anyone else see the possibilities here?
It will be a rare day indeed when anyone (coder, manager, stockboy, whoever) will, of their own initiative, approach you and ask for help, particularly in the context of "Oh my God, I'm running behind and need some guidance!". You'll need to ride herd on your teams progress and be prepared to point out to a team memberthat help may be needed, and be responsible for organizing that help, even if you yourself aren't the source of it. More work for you, unfortunately, but if you depend on others to self-identify, you will be regularly burned.
You're in a bit of a thankless position, needing to be both a developer and a project manager simultaneously. It's a tough slog and I can't think of any easy advice to give you.
A couple things to hopefully help your future projects:
- You will need to define expectations to your co-workers in advance and in as much detail as feasible. Simply saying "we need to be done on day [x]" obviously ain't going to cut it. This involves a couple responsibilities: a) identifying appropriately detailed descriptions of expectations for each team member, and b) constructing a task list at a level of detail allowing concise definition of each task and being frequently reviewable in a meaningful way.
- More painfully, you will need to budget time into your daily routine to ensure the "pebbles" (like milestones, only smaller --not my term, unfortunately, but I can't remember who I first heard coin it) are being met on a daily basis. A basic rule of project management--surprises are bad things. The earlier you're aware of slippage, the more leeway you have to do something about it.
- Since you'll need time to monitor and review progress your own task timelines will need to reflect this. Never forget to do this, and make sure the project owner is aware of why your tasks seem to require more calendar time than other developers. You are not a 100% coding resource!
- You will need to be willing to address developers who are lagging. More specifically, you need to address them as soon as you notice tasks lagging. This isn't the easiest or most enjoyable part of the job. Note that ( "address" != rip a new anterior orifice ) What is does mean is that you will need to take the initiative to: a) identify lagging tasks, b) contact the developer or developers responsible for the task, c) determine why the slip occurred, d) identify a solution and e) follow up to ensure the solution was implemented.
None of the above is rocket science, of course. But all of it involves behavior modifications for most people. Addressing developers who are lagging in particular is sticky, since you have to be prepared for pretty much anything and any reaction and you need a lot of self-confidence to not feel nervous about initiating this contact. And, in addition, you yourself will have to change your daily work habits to some degree and be willing to commit to those changes--and this can be the hardest part of all.My personal experience is that any task with a duration of more than 2 days or so is too high level to track meaningfully--you'll have to subdivide these tasks into smaller units of time so that you can reach a meaningful agreement with your developers on what exactly is to be done and when it needs to happen. You may feel comfortable with longer or shorter ceilings. Just remember: you'll be reviewing every task frequently--make sure what's on the list is meaningfully reviewable by you.
Best of luck to you...
Management needs to do a better job of understanding why programmers and techies often seem to resentful when being assigned projects
I would respond that programmers and techies who feel this way need to do a better job of understanding why something which may seem boring/trivial to them may hold value for the business as a whole.
Not saying that all projects are good simply because someone thinks they are--Lord knows there are plenty of DOA projects spawned out of ego gratification or politics (and I've worked/managed my share of them). But I see a amazing number of developers who have no interest in even trying to evaluate the business rationale of a decision if they sense the decision consequences pushing them out of their personal comfort zones.
You might be right--the project might be stupid, meaningless, doomed to fail and a waste of time and resources. But it isn't guaranteed to be these things simply because it doesn't interest you.
it is a sign of bad management that ignores those types of hesitations and flies on the basis of what is 'techically possible' alone.
Don't know what employers you've worked for, but my experience is the opposite. Little seems to be done simply because it can be done. Lots is not done because the risks (real or falsely perceived) of doing so seems disportionate measured against the gains (real or falsely perceived) of a successful outcome.
I'd say a more useful tactic would be for tech types who agree with your sentiments to learn how to convince their company chiefs: a) technical choice 'X' is a good|bad decision for the company and b) why is is so, in quantifiable terms that the chief can understand. This is not a simple or singular skill, of course--it involves lots of peoplework, negotiations, occasionally losing battles to win wars, and learning to explain your opinion in a seemingly foreign language of finance and management. But, IMHO, that seems a lot less stressful than sitting around all day resenting the stupidity of your management.
Or, you can run your own company and do whatever you want. Just remember: the onus is on you to convince someone that what you're doing is interesting/useful enough to warrant your getting paid for it. See above discussion on negotiation,peoplework, etc.
They should be liable.
Who is "they"?
Gifts don't come with the same implied warranty that purchases do.
Money doesn't imply a warranty. Nor does any other form of consideration. The claims of the provider are the basis for any warranty. If I expressly claim that my product does "x", I have potentially set an expectation of performance in the mind of any potential user. My willingness to allow the product to be used without requiring monetary consideration does nothing to change that expectation.
The only exception I'd see to this would be in you intended to hurt someone. At this point I think you could be charged with fraud. You desired an outcome and deceived someone to those ends. Cash doesn't necessarily have to change hands for this charge to stick.
But we're not just talking fraud in this discussion, we're talking about liability in general. One can be perfectly straightforward in advertising a product's capabilities, honest to the best of one's understanding and still be liable for the product's failure to perform to those capabilities. Fraud is a very small portion of the legal exposure iceberg.
I really don't see why this doesn't make sense... To believe otherwise seems similar to supporting the family who sued the volunteer search & rescue team who failed to find their son. The volunteers offered to help, they didn't guarantee results. If their help is useless, it's worth what you paid.
I've never heard about this case, but in any event, your post answers itself:
The volunteers offered to help, they didn't guarantee results
It is the disclaimer of performance which should insulate the volunteers, not the fact that they volunteered to look. Sure, their willingness to do so reflects well on them as human beings. But had they told the family "we WILL find your son and, furthermore, we guarantee that we will", they've set up a expectation of performance and could (theoretically) expect exposure.
This is why terms of use licenses in software go into such mind-numbing detail stating that their products are NOT warranted fit for almost any task. This disclaimer provides an affirmative defense in the case of liability proceedings.
Yet, US law supports this shit, so likely your interpretation would pass, especially since the big companies love it.
Actually it is this inability to hide behind blanket protection clauses that keeps most corporate legal departments in steady employment, as opposed to doing something really useful with their time. Joe Sixpack may file a negligence/liability suit against a product provider at any time if he feels the product/service has set an expectation of performance and failed to deliver. Whether or not he's right is a question for the courts. But he always has recourse to legal evaluation of his claim. And the possibility of lawsuits coming from any one of thousands or millions of product users drives most businesses absolutely nuts.
Contrary to your assertion, I would say it is your proposed blanket protection that most business would welcome. I can just envision the hoops most companies would jump through to escape costly negligence trials by claiming that "no consideration" was received for use of their product.
And as for not being able to sue just because you didn't pay... Why should you be able to sue if you got something for free? If I give you a stereo and it breaks, should you be able to sue me for a working stereo?
The consideration (or lack of it) exchanged between obtainer and supplier of a component is irrelevant, IMO. What is of interest is the discrepancy between what it's claimed and actual functionality.
Put more simply: why should my expectations of your hypothetical network code be different based on whether or not I'm paying for it? What magical quality does money provide such that the lack of a purchase price provides it's developers blanket insulation from negligence/fraud proceedings?
A scenario for you:
Am I as the developer off the hook for a potential negligence tort, even despite my claim of the software's readiness, simply because no money changed hands between myself and the equipment manufacturer?
And if so, why?
If they paid someone else for a component which is shown to be defective, then they sue that person/company themselves.
...who sues the person/entity that they paid for access to the component...Repeat ad nauseam
Also, since ultimately someone will have written/obtained the component without a financial transation taken place, wouldn't this system ultimately collapse when people run out of targets to "pass the buck" to?
Dunno--this sounds more like the full employment act for the legal profession than a useful protection for an end user. Not that the legal profession needs that much more help...
If you didn't pay for it, you don't get to sue.
So someone who didn't pay for something has no recourse in the event of damages related to negligence in the development of the component? And someone who did pay does? Why would you allow/deny legal protection based on whether or not a checkbook was involved?
Er, just which individual(s) do you name as defendant on a tort involving an open source system? The original author(s)? The current change control administrator? The change control administrator responsible for the supposedly negligent version? The developer who last patched a negligent module? Everyone who ever had contact with the system? None of the above?
Congrats Taco; fondest hopes for many happy years together.
/. spelling/grammar is bad now, just wait a few years until a bunch of little Tacos (taquitos?) are helping out with the site editing chores...
One concern: if everyone thinks the
Again, best to you both and happy V-day.
(AP newswire article)
If I'm interpreting this correctly (and IANAL), seems that the judge agrees that the statute requiring open access to the depositions doesn't apply in this circumstance. In fact, the judge seems to be requiring MS to do the heavy lifting demonstrating why the media should be excluded from a particular deposition. My guess would be that MS's legal team will concentrate on sealing any depositions of the big guns (pretty much anybody above product manager level, or whatever the equivalent is at MS), so that they don't experience a repeat of the Gates video debacle. The small fry will be left open, but they probably won't offer anything we haven't already heard.
In any event, I'm not sure what the flap is about even if some/all depositions are closed. The judge can only consider what is actually presented to her as formal evidence (which will end up being a subset of the deposition material IMHO). Deposition transcripts entered as evidence will be available to the public.
Besides, it's not like the technical/media community is suffering from a shortage of "Two-fisted MS business strategy" stories right now anyway...