Yes, software manufacturers have so far gotten away with that. For most physical products, you can put a similar statement on the item, but unless you are selling a specifically discounted, reused, or remaindered item at a significant discount, you can't dodge the basic warranty of fitness.
>...in general: > > * We trust all hand tools like wrenches and sockets to be exactly the size on the label > * We trust all of our doctor's opinions whether or not a second opinion is recommended > * We trust our math applications to do math properly > * We trust our spell checkers to check properly > > In general, we trust the things we by to work as expected... as advertised.
These links refer to the concept you're talking about. The second refers to the UK Consumer Protection Act, but the concept is general and fairly well accepted. From the first link:
"...any product that is sold comes with an implied warranty of merchantability and fitness for a particular purpose; and, just by selling a product, a seller is implicitly promising that: (1) the product is merchantable, i.e., fit for the ordinary purposes for which such products are to be used, provided that the seller is in the business of selling products of that kind; and (2) the product is fit for a particular purpose, provided that the seller, at the time of sale, knew the particular purpose for which the product was required, and the buyer relied upon the seller's skill or judgment in selecting a suitable product for that purpose."
This hasn't been successfully applied to software cases like this, but the issue hasn't be ruled out either. But it's hardly a stretch to expect that software such as a spreadsheet comes with an implied warranty that ordinary financial and statistical calculations are properly performed.
> I'm guessing the majority of the applications written to target Linux are server > applications. It would be interesting to see if this can be explained by a result > only in the server application space, or if more client applications are also > being targeted at Linux.
It might also be affected by a higher percentage of server-side code being developed in general. I develop a lot on Windows, and probably the majority of the code I've written over the last few years is server-side.
Especially as more corporate apps move to web-based interfaces.
> Typically recording people in public areas is OK without permission,
Presumably the teacher was unaware that there was a camera. Recording people in a public place -as part of recording the place- or an event held there or other neutral things in and about the place is perfectly acceptable.
Surreptitiously recording someone specific in a public place often violates laws against voyeurism and is classified as an invasion of privacy.
> In this case, they are in a public institution, and although it was not a public > space, there is really no expectation of privacy.
IIRC, the criteria isn't reasonable expectation of privacy, it would be reasonable expectation that you would not be recorded, which would be a somewhat higher standard. Privacy would imply that you could expect no one could overhear or perhaps see you. Not recorded would simply mean that you would expect that while someone might see, you, it isn't being recorded for posterity.
IIRC, the 'filming in a public place' protection for photographers and videographers only applies to their more or less accidentally encountering something someone might not want filmed in the course of a non-targeted filming in a public place; not a deliberate attempt to film one specific person in an embarassing light without their knowledge and consent.
And, as you pointed out, a public school is a public institution, but not truly a public place.
> Standing up in front of a class of people is exactly the kind of step that can > remove the "expectation of privacy".
Privacy, yes. But covert -filming- is more than invading privacy. The situation could be slightly recast with different participants and intent, and then the situation would border on stalking. As it is, I'd have to call it less serious, but still unacceptable, possibly illegal, violation of the teacher's rights.
Sorry, I think this one calls out for some sort of punishment. If the school didn't, the teacher might be able to sue the school as well.
> As a rule, companies refer all questions about former employees to HR. HR, as a rule, > will only confirm stated dates of employment, title, maybe salary.
As a rule, yes. As a requirement, no. They are free to speak any truth about your employment that they wish, and many employers offer much more information, depending on the unwritten rule that no one will inform the person interviewing exactly what was said.
If the poster is being made a fall guy by one or two not-too-senior people, it may be a safe bet that the company will not say damaging things. However, if the person who picked him as the fall guy is senior staff, they may also deliberately target the poster.
I've known a few managers who have done that to people they didn't like.
The safest thing would be to have a trusted friend pose as an interviewer seeking to verify references.
> Also, again, firing black people isn't that easy. Anyone who's been a manager knows > it can be a real bitch to get rid of an employee in any protected class - race, gender, > or (in some states) sexual orientation.
Actually, there are a -lot- of clueless managers. I once worked for a manager who tried to fire a female employee who got pregnant. This was less than a year after congress passed that family leave legislation.
One of his subordinates had to practically -beg- him to check with the lawyers first; he didn't want to bother. He was stunned when the lawyers told him he not only couldn't fire her, but in spite of the fact that she was the least senior staff member, she was now safe from seasonal layoffs or other cuts to hours.
> Within the first couple years we had fixed the network and made it into something useful. > The consequence was more use by upper management and as you might expect, more management > from upper management. Every time we met another goal, the more visibility we received. > The more visibility we received, the more layers of management they installed above us. > Every layer of management installed made it harder and harder to actually get anything > done, basically because each new layer of management knew less about IT but more about > "managing.". > > I guess mostly I'm just whining here, but eventually most of us who had built the network > quit. They 'managed' us right out the door.
Rambling follows. Cogent or indicative of caffiene deprivation?
There's a certain point of view among many sysadmins and developers that an ideal worth striving for is to avoid needless rework and busywork. If a task needs repeated, automate it. The lazy sysadmin / developer is the best. See Robert Heinlein's 'The Man Who Was Too Lazy To Fail" in "Time Enough For Love."
Among many managers, there is a point of view that says a constant hum of visible activity is a goal to strive for. It a task needs repeated, this indicates the importance of the task and means that it must be MANAGED. Managers can't manage shell scripts and other automated tasks, so it -has- to be done by a person. Manually. With mind-numbing repetition and constant reporting of progress to managers in charge of managing the lucky SOB who got assigned the task.
I think we need more lazy managers and fewer "activity for activities sake" managers. I KNOW we need lazy managers managing the lazy sysadmins and developers, and active managers managing the "Hmm... when was the last time you rebooted this Windows box?" folks.
What's a bank? In the US, banks are normally regulated by the 50 states, each with different rules and regulations. In addition, there are credit unions, savings and loans, insurance firms and a number of other brick and mortar institutions that have many of the normal functions of banks. Could they register.bank domains?
Do we open the top-level.bank domain to non-US institutions? This would seem reasonable if we are talking about Barclays, Deutsche Bank, etc. But do do we draw lines? Do we include little institutions incorporated in tiny little corrupt nations? How do we ensure that firms in these countries don't register names that sort-of look like large, reputable institutions?
Whose laws do we use to take action against violations? In the US alone, you could be talking about 51 distinct court systems, each operating under different laws.
And would banks -really- flock to this? Isn't it just as likely that they would insist on using the.com domains because that's what people are used to?
From the original: "The creation of a new domain for a specific industry is not unprecedented: We've already done it for museums, with their restricted ".museum" top-level domain. If we can manage to protect storehouses of precious works of art from the Internet's most shameless thieves, surely we can find a way to protect our money."
And millions upon millions of working men and women use that restricted ".museum" domain for their many daily museum transactions, right? There is a distinct difference between getting a fairly small group of people in a rather specialized field to validate transactions in this fashion and teaching millions of busy, technically challenged people to do the same.
A large percentage of attorneys can use LexisNexis; that doesn't mean it's suitable as a replacement for Google and Wikipedia.
Mostly agreed, with one modification and some additions:
> Remember: sometimes a manager has to be a jerk. > sometimes a manager has to be the heavy. > Don't look for the nicest person. > You HAVE to be the bad guy once in a while.
Yes and no. Yes, you have to be the heavy sometimes, you have to be the bad guy sometimes. But you don't have to be a jerk about it. I don't think you meant that a manager does; But some people do seem to feel that you have to be the heavy in the obnoxious a**hole way, and you don't.
> A good manager is one who lays down the bad news > and then still can motivate the team to perform well.
Bingo. He -has- to be able to motivate the team. I'd consider asking the candidates how they delivered bad news to the team. How did they keep the team motivated? I'd ask them for one or two examples of each of the following:
- a case when they had to tell their boss/customer 'no'. - a case when they had to get rid of a team member. - an example of how they dealt with a challenging or even impossible delivery date. - a description of their ideal developer. - a description of their ideal boss/customer.
People skills are funny things: some people are fine dealing with their superiors, but can't deal with subordinates. Others are the reverse. Good managers need to deal well with both.
> Since the overwhelming majority of fathers behind in their payments is because > of inability to pay,
(Majority of fathers) != (majority of -children-), nor (majority of dollars).
Many deadbeat dads (and I'm referring to the real -deadbeats-, not those in tight financial situations) spread their seed around to any gullible girl they can find. Tracking down that minority could make a huge difference.
And a certain number just walk away, alter their records slightly, and abandon the kids.
> Child support (and alimony) are pretty much set in stone and a change in the > man's employment situation doesn't matter.
Support -terms- are set in stone. Execution of support terms is fuzzy; there are thousands of cases where fathers made payments that were never credited, payments were never forwarded to the mother, and a dazzling array of bonehead screwups by bureaucrats, compounded by lack of traceability. A decent database could help that a great deal.
It's not a universal cure for all ills, but it would help in adressing some of the problems.
>...The problem with Clippy and other avatars was that it was:
Actually, in addition to the problems you noted were the following problems:
- You could not choose, in a custom install, not to have the damn avatars in the first place. You had to install, then disable them - The method for disabling the avatars is placed in a non-intuitive location - You could not reliably disable avatars in the first release of Office to have them; like things buried in the Pet Sematary, they kept coming back.
Similar problems exist in the "Clipboard Enhancement" that allowed Office apps to store more than one item in the clipboard, and pop up a stupid dialog to select which thing you wanted to paste. That turns off by dismissing the dialog 3 times (WTF, MS?), and can come back if you copy twice without pasting.
"Bad Pet Rock! We do that OUTSIDE!" - Peter Griffin, 'Family Guy'
> The reason why "MS Windows is still the most convenient platform for consumers" > is it is installed on the PC (unless you build it yourself) prior to you getting > it, there is little if any choice about it.
Oversimplified; not -wrong-, just oversimplified. Yes, there are viable, user-friendly, inexpensive alternatives to Microsoft...but there didn't used to be. Macs used to sell at a significant premium over PCs, and have less, usable software available. *nix boxes used to be either too expensive or too difficult for the home user.
It's different -now-, but it takes time for these factors to hit the mainstream. Vista may accelerate this process.
> I will admit Linux games are not on par with the Latest PC games because few > vendors make native Linux games (that is not the fault of Linux) but if I want > to play a game I prefer console games, so no loss there.
Games are getting better, too. they're behind the cutting edge, but they are better.
> citing that the right to bear arms only applies to 'a well regulated militia.'
Nitpicking on terribly poorly worded statement.
The second amendment states: 'A well regulated Militia, being necessary to the security of a free State, the right of the people to keep and bear Arms, shall not be infringed.'
Which clearly guarantees the right to keep and bear arms to -the people-.
Arguing that the -goal- of the amendment, based on the stated desire to promote a strong militia, is to limit gun ownership to 'official' militiamen is reasonable, although I don't support that view. But the -language- clearly states that the right applies to the people.
You can state that the -intent- is that it should be restricted to a 'well-organized militia' and people may argue about whether you are right or wrong, but you can't 'cite' language that isn't in the document.
Breakdown of amendment:
'A well regulated Militia': what is the goal of the amendment?
'being necessary to the security of a free State': why do we want to have
a well-regulated militia?
'the right of the people': who has the right?
'to keep and bear Arms, shall not be infringed.': what right do they have?
I'm not saying, "They can have my gun when they pry it out of my cold, dead hands". I don't own any guns.
I'm saying, lawyers are -supposed- to be well-educated people, trained to think clearly and express themselves clearly. Unless, of course, they are intending to mislead someone... Nahh; D.C. lawyers are too ethical to do something like that;>
Sometimes I've found management to be an obstacle in enforcing some of these types of rules. If that happens, a few ideas for coping:
> 1. Limit access to deployment server - only one or two person can access the server.
Sometimes managers insist on either retaining their own access to production boxes or delgating that authority to the 'village idiot'. See below.
> Even better - create automatic deployment scripts that can be run on the server by those persons.
If the wrong people are given access to the production boxes, try to limit everyone's access to running a limited set of scripts that log all operations performed, along with who did them, and let you easily roll back the last change. Don't let anyone access the box directly. Then put together an automated failure report that tracks what changes occurred before the box broke. This information can be useful in the uphill battles to stop the idiots from breaking the server.
If the question "why did the server go down?" comes up every month, it's useful to have a printout ready that says that each time it happened was immediately after Jimmy moved untested code into production, along with details.
> @. Create staging server - where you deploy the code from repository. Do not deploy to > production until you get a "go" from the client on staged version.
Also, if the validation process becomes subverted by pushes to "get it out the door", set things up so it can be easily rolled back.
> 3. Use Trac -...
Never used it, but it sounds like the kind of thing you definitely want.
> 4. Use framework - frameworks usually come with a set of coding concepts that ease code reuse.
Maybe; some are good, some are bad. I've had the misfortune of helping developers select the right framework, only to have management scrap the recommendations and buy overpriced crap that's "oooh, shiny!". If you adopt frameworks, treat them as "on probation". Review and be prepared to get rid of them if they aren't supporting you.
> 5. Communicate findings about bad practices - just talk with your colleagues and tell > them how can they write better code, with examples
Don't preach. Write it down (Wikis are good for that), and reinforce it in a non-threatening environment like peer code reviews/stand-up meetings.
> So how does any user clicking add any CYA aspect to the GPL?
The only way I can see this as CYA is in a corporate environment, it would protect (in a very small way) the distributor from accusations by someone who reused the code in an application that was released in a way that contravened the GPL.
I've seen some corporate lawyers go bats over developers and techies who downloaded tools, and some of the developers tried to claim they were unaware of licensing limitations on copying the code.
> If you can only fill in one page, then keep it to one page. > If you need 10 pages, fill 10 pages, but try to put the really > good and recent stuff on the first page.
Have to disagree. Not that one page is a firm rule, but ten pages is excessive. The main purpose of the resume (at least in the US) is to get an interview or call. Ten pages of detail doesn't help you do that. Pare the older/less relevant stuff down to a series of short summaries, and add "ask me for more details". If you're in the ballpark, they'll ask. This is particularly useful when companies put every cool catchphrase they've ever heard of on the list of qualifications.
Bring the ten pages of detail to the interview.
> Think long and hard if you want to work for a company that > rejects you based solely on the number of pages you submit.
I don't know of any that reject people for sending too long a resume; but I know -many- that give the big, honking ten page resumes to Sally from HR to pare down to the "relevant" ones, and Sally isn't usually the sharpest tool in the shed. Sometimes Sally doesn't forward the resume because "I don't think he speaks English very well; his resume says stuff about Perl and awk and sed, and I think he's been sick; I saw something about Mono on his resume?"
>> Developers can switch teams and/or projects any time they want, no questions asked; >> just say the word and the movers will show up the next day to put you in your new >> office with your new team.
> Having developers on a merry-go-round between projects is probably a good reason > why their products never make it past the Beta stage
A couple of points: the poster said "developers -can- switch teams and or projects anytime they want". Your criticism, while it has some validity, is not directed at the idea that developers -can- switch projects, but at the consequences of them doing so too frequently. Consequences that are identical to the consquences of managers moving developers around too much, overscheduling them on projects, and psychotic "matrix management", all of which would be reduced by allowing developers to change projects at will.
If you can't let developers choose their project teams, it might indicate that management has backed too many doomed projects.
>> There aren't very many meetings. I'd say an average developer attends perhaps 3 >> meetings a week.
> One meeting a week should be sufficient. Three meetings a week spells inefficiency > and poor process.
Maybe; depends on what the meetings are like and what they are for. 10 or 20 meetings a week are probably not too much if they are ten minute, "how do you want to handle this?" meetings.
>> there aren't Gantt charts or date-task-owner spreadsheets or any other visible >> project-management artifacts in evidence, not that I've ever seen.
> Okay, so now we're advocating against the use of project management techniques? > Let's piss in the wind and hope it lands where we intended?
I didn't read the poster's statement that way. The kind of documentation you mention can be useful, -if properly used-. In many places I've worked, they've been used primarily to obscure the fact that the emperor has no clothes.
> A few things I can tell you to steer clear of is Microsoft Certified > Solutions Developer.... In my workplace, all I hear is people making > fun of those certifications over and over and over again. I don't know > if they are jokes but from what I hear, it's a stupid idea to pay for them.
The Microsoft certifications, in general, have really been devalued by people trying to cash-in on marketplace demand. But even the less stringent ones, like MSCD, have some value in terms of employment.
But you need to know that being an MCSD -won't- get you a job; the most it will do is allow you to compete for a job on your real qualifications.
It's not a Willie Wonka Golden Ticket to success; but -not- having it may cause the lower-level staff who look at applications before they get to the hiring manager to file your resume in the "don't call us" file.
> or Microsoft Office Power User...
MS Office Power User, eh? Sounds like MS trying to milk the market dry.
Let me start off by saying I have never seen a decent cubicle layout, or a decent cubicle outside of a magazine. They may exist, but judging from responses by others, they are more rare than most of the animals on the endangered species list.
> Cube farms have many cost and flexibility advantages that should not be > dismissed out of hand. They can be reconfigured for less construction > cost and disruption, are easier to wire, easier to light, easier to > ventilate, easier to build, and much cheaper. You may also save on > the office lease if the landlord won't have to tear down too many > fixed walls for the next tenant when you leave.
You used comparatives all over the place in that paragraph; easier...to build, wire, light, ventilate, etc., without once mentioning what you were comparing them to: private offices. Yes, they are cheaper than private offices, easier to wire than private offices, etc., etc.
So is a cardboard refrigerator box, but I wouldn't recommend one as an workspace. I'm not being facetious; by dismissing private offices in your paragraph above, the way you structure the argument also discards out ot hand other options, that are also cheaper than private offices: shared offices; an open floorplan; probably many others. The choice isn't one thing or the other; the real decision is to find the right mix of cost and utility.
> Simply put, there are good cube farms and bad cube farms. "Bad" cube > farms have partition walls under 6ft, beige upholstry, poorly designed > desks, no door, poor insulation, no open collaboration areas and no > rooms with doors for meetings.
Agreed on all points, and a few others to add to it:
- Tech-unfriendly design: many cubicles are designed for people who use exactly one PC; never need to refer to technical manuals; never need to keep things under lock and key; never need to keep large amounts of printouts. They have itty-bitty drawers without locks, no shelves for books, and no %$#@! extra flamin' electrical outlets or network jacks for when you need to test on a second box.
- Small desks, just big enough for a PC but not to have a binder on the desk at the same time.
- Tiny little spaces for monitors, so you can't shove a 17" screen back all the way and end up sitting with your bloodshot eyes 2" away from it.
- No %$#@! wallspace for tacking up diagrams with pushpins or hanging up a whiteboard.
- No extra floorspace for just talking with -one- other developer and seeing the same screen or whiteboard.
> "Good" cube farms are possible. Select good partition walls that are 8' tall > (but do not stretch all the way to the ceiling), have doors and have good > sound insulation. Look for an attractive pattern on the cloth, a design > with very configurable and comfortable work surfaces, roll-under file > cabinets, etc. (Some old Steelcase stuff we have at work even has > electric raising and lowering motors for the desk!)
All sounds good; add extra outlets and network jacks, built-in locking bookcase or room to put a freestanding one, and enough floor space for 3 people to look at the same monitor/whiteboard at the same time without getting a neck cramp.
> To go with ANY office area, you need areas with comfy chairs, swing-out > writing surfaces, and whiteboards and projectors. These are great for > collaboration, but folks can still retreat to their cubes when they need > privacy. You can have the cubes surround the open areas if you wish.
> For manager cubes, it would be a good idea to have walls that go to the > ceiling for private personnel discussions. You will also need conference > rooms for your more "rambunctions" meetings, speakerphone conference > calls, client meetings, etc. These should be equipped with projectors.
And enough of them; at least one per floor, and enough that one or two are empty more often than n
I apolologize in advance for any offense; that's not my intent.
> 1. No company in their right minds wants to pay for TWO programmers > to do a single job.
True; but if a company has paid 20 programmers to do the work of onten (sub-par) programmers for some time, they can be convinced.
> 2. As with any other method, it assumes all the specs and implementation > have been worked out before the code is even written....
That sounds like BUFD, not XP; have I misinterpreted your meaning?
> nobody has the freedom to write experimental throwaway code to even see if > their approach is even feasible in the coding,
Sure they do; I've done it hundreds of times for -very- grateful managers. They'd much rather I test an idea with cheap throwaway code than try to implement an expensive, untested idea we can't afford to change later. They'd prefer to find out without even a few hours of coding, but sometimes that isn't possible.
Device comments snipped; I don't program devices.
> 3. While its great at letting the mundane functions be rewritten (refactored) > as many times as possible, it gives a mechanism where newer features are > *always* put off (by managers usually) indefinitely....its an illusion, > under a few managers, that the programmers will ever get to implement > the newer features wanted by customers
Sure doesn't sound like XP to me; sounds like you bought "Dr. Quack's new and improved miracle elixer - now fortified with XP from the healing waters of Casablanca. Guaranteed to cure what ails you or double your ailments back!"
> I always find it really is better for a group of Programmer Peers to > sit down together and review the code AFTER it has been written (with > tests). Trouble is, most companies/managers refuse to understand that > 'Programming Peers' do not include the stock boy in shipping.
So, let me get this straight; you did something someone called XP...but apparently wasn't. It didn't work, and you find good old code reviews work better...except you aren't actually getting to do peer code reviews either.
To paraphrase G. K. Chesterton, "XP has not been tried and found wanting; it has been found politically difficult to implement, and left untried."
>...However, if you are looking for all the in-and-outs of how an employer can screw > you and asking your questions from this viewpoint, it comes across quite clearly > and an intelligent hiring manager will know that you will be someone who will be > very difficult to with as you lack any ability to have any trust for management > in a business environment.
True; however, trust is not valued in all companies. I value it, and look for employers who do; but many employers do not. They usually -say- they do, but their actions quickly show that they reward the treacherous.
> It is never in an employers best interest to screw over its employees.
True; but some employers -believe- it is in their best interest to screw over its employees.
> If an employer does think this, his company will not suceed as he will > just drive away his best employees.
This is a level of long range thinking many businesses do not support. Business managers do not always do what is best for the company in the long run. Often, they focus on the short run as well. A good indicator is to check on how long the manager and his boss have been with the company. If they just came in 2 months ago, replacing a guy who was there for 3 months, who replaced a guy who was there for 2 months, chances are the company doesn't encourage long-term thinking.
> As to the original poster questions, it is never too late to attempt a career change,
Damn right.
> especially if it is something that you are really interested in. Just keep in mind > that you will be starting at the pay scale that someone in their early twenties > would be getting. Is your life style going to accomodate that?
Very true. On the upside, you may also advance faster than the guy in his early twenties when they see your work. Often the twenty-something will be out partying all night, showing up late, and checking in broken code at 11 PM. Often the boss sees the difference quickly.
>...you have to break your tasks down into small tasks with known dependencies to > the point you *can* estimate times to do things.
Also, Cliff, don't forget to account for the fact that some of these tasks are also interdependent, and count time to integrate the components created and test them.
> Once you get that far, experience (gut feeling) will contribute. After that, you > give an optimistic and pessimisitic times to your boss. Example: If all these > assumptions hold and these other three things happen on time, then the time estimate > is one week. If this, this, or this doesn't pan out as expected, then the time > estimate is three weeks.
Good example; Cliff, note that the pessimistic estimate is *3 times* the optimistic one in the example. That's pretty typical. A lot of people use a pessimistic estimate of (optimistic * 1.25) or 1.5, but your pessimistic estimates really should be significantly larger for many tasks. Think about the things that might go wrong. Sometimes, they don't go a little bit wrong, like "it was harder to integrate with product XYZ". Sometimes they go really wrong, as in "it -can't- integrate with product XYZ; this feature of XYZ is broken and won't be fixed in the future."
Have to push back here. The problems with ratings systems (TV, Movies, and Video Games), have -always- been made worse by the unwillingness of the industries to provide -full disclosure-.
The ratings tags (X/R/PG-13/PG/G and TVMA/TV14/TVPG and TVG) were created by the industries. Parents groups and other groups wanted explicit labeling according to meaningful critera: is explicit sex shown? Explicit violence? How many deaths? Etc, etc.
In each case, the industry wanted to weasel through, so -they- chose criteria that put sex and violence in the same category, and tried to come up with "age-appropriate" guidelines.
> "Computer literacy is becoming an increasingly used term in education, and > more and more schools are being asked to set computer literacy goals for > their students. Unfortunately for too many, it means being able to use > Microsoft products, and that's all. However, I see it much differently, and > I cannot help but think that computer literacy is all about using computers > to be able to communicate more effectively. With that in mind does anyone > have any recommendations for computer literacy goals, and how to measure them?"
Computer literacy, however we define it, requires basic thinking skills.
The user requires the ability and consciousness to
- read messages: error, status, and responsive, from the computer, attempt to understand what they mean, and decide how to respond appropriately. This means a "click monkey" who can't learn not to dismiss message boxes unread cannot claim computer literacy.
- attempt to discern patterns and relationships, understanding what the underlying system metaphors are. This means that people who can never understand that their documents aren't saved "in Word", but somewhere in a file system, cannot claim computer literacy.
- act sanely, according to the often used definition of insanity; trying the same thing repeatedly and expecting different results. This means that people who learn to can't slow down and watch what they do when trying to repeat a problem cannot claim computer literacy.
- attempt to learn the proper names of things they deal with often. People who can't learn their OS is Windows XP and not Word, cannot claim computer literacy.
Note that I said "can't learn" rather than "haven't learned."
> That's a good thing isn't it? Outlook 2003 is an assault on the visual senses.
Agreed, BUT it's only a good thing in terms of actual usability and technical proficiency. In terms of getting that -initial buy in- from the business people; the initial agreement to -try- something else, it's a -huge- liability.
On the last half-dozen projects I worked on, -appearance- was the number one issue for users. It had to be "just so" and alternatives, even if they were superior, were not permitted.
>...It's less obnoxious, however. Shows up in the right-bottom corner. And > I'm not 100% sure it's a paperclip, I think it might be a lightbulb or > something.
Oh, that thing. Yeah, It's unobtrusive enough I never really connected it with "Clippy".
Slashdot Mirror
Yes, software manufacturers have so far gotten away with that. For most physical products, you can put a similar statement on the item, but unless you are selling a specifically discounted, reused, or remaindered item at a significant discount, you can't dodge the basic warranty of fitness.
Thanks for your comments.
> ...in general:
_ 06.asp
l ity-Insurance.html
>
> * We trust all hand tools like wrenches and sockets to be exactly the size on the label
> * We trust all of our doctor's opinions whether or not a second opinion is recommended
> * We trust our math applications to do math properly
> * We trust our spell checkers to check properly
>
> In general, we trust the things we by to work as expected... as advertised.
http://www.oandp.com/edge/issues/articles/2006-08
http://www.brajeshwar.com/finance/insurance/Liabi
These links refer to the concept you're talking about. The second refers to the UK Consumer Protection Act, but the concept is general and fairly well accepted. From the first link:
"...any product that is sold comes with an implied warranty of merchantability and fitness for a particular purpose; and, just by selling a product, a seller is implicitly promising that: (1) the product is merchantable, i.e., fit for the ordinary purposes for which such products are to be used, provided that the seller is in the business of selling products of that kind; and (2) the product is fit for a particular purpose, provided that the seller, at the time of sale, knew the particular purpose for which the product was required, and the buyer relied upon the seller's skill or judgment in selecting a suitable product for that purpose."
This hasn't been successfully applied to software cases like this, but the issue hasn't be ruled out either. But it's hardly a stretch to expect that software such as a spreadsheet comes with an implied warranty that ordinary financial and statistical calculations are properly performed.
> I'm guessing the majority of the applications written to target Linux are server
> applications. It would be interesting to see if this can be explained by a result
> only in the server application space, or if more client applications are also
> being targeted at Linux.
It might also be affected by a higher percentage of server-side code being developed in general. I develop a lot on Windows, and probably the majority of the code I've written over the last few years is server-side.
Especially as more corporate apps move to web-based interfaces.
I don't quite agree with your reasoning:
> Typically recording people in public areas is OK without permission,
Presumably the teacher was unaware that there was a camera. Recording people in a public place -as part of recording the place- or an event held there or other neutral things in and about the place is perfectly acceptable.
Surreptitiously recording someone specific in a public place often violates laws against voyeurism and is classified as an invasion of privacy.
> In this case, they are in a public institution, and although it was not a public
> space, there is really no expectation of privacy.
IIRC, the criteria isn't reasonable expectation of privacy, it would be reasonable expectation that you would not be recorded, which would be a somewhat higher standard. Privacy would imply that you could expect no one could overhear or perhaps see you. Not recorded would simply mean that you would expect that while someone might see, you, it isn't being recorded for posterity.
IIRC, the 'filming in a public place' protection for photographers and videographers only applies to their more or less accidentally encountering something someone might not want filmed in the course of a non-targeted filming in a public place; not a deliberate attempt to film one specific person in an embarassing light without their knowledge and consent.
And, as you pointed out, a public school is a public institution, but not truly a public place.
> Standing up in front of a class of people is exactly the kind of step that can
> remove the "expectation of privacy".
Privacy, yes. But covert -filming- is more than invading privacy. The situation could be slightly recast with different participants and intent, and then the situation would border on stalking. As it is, I'd have to call it less serious, but still unacceptable, possibly illegal, violation of the teacher's rights.
Sorry, I think this one calls out for some sort of punishment. If the school didn't, the teacher might be able to sue the school as well.
> As a rule, companies refer all questions about former employees to HR. HR, as a rule,
> will only confirm stated dates of employment, title, maybe salary.
As a rule, yes. As a requirement, no. They are free to speak any truth about your employment that they wish, and many employers offer much more information, depending on the unwritten rule that no one will inform the person interviewing exactly what was said.
If the poster is being made a fall guy by one or two not-too-senior people, it may be a safe bet that the company will not say damaging things. However, if the person who picked him as the fall guy is senior staff, they may also deliberately target the poster.
I've known a few managers who have done that to people they didn't like.
The safest thing would be to have a trusted friend pose as an interviewer seeking to verify references.
> Also, again, firing black people isn't that easy. Anyone who's been a manager knows
> it can be a real bitch to get rid of an employee in any protected class - race, gender,
> or (in some states) sexual orientation.
Actually, there are a -lot- of clueless managers. I once worked for a manager who tried to fire a female employee who got pregnant. This was less than a year after congress passed that family leave legislation.
One of his subordinates had to practically -beg- him to check with the lawyers first; he didn't want to bother. He was stunned when the lawyers told him he not only couldn't fire her, but in spite of the fact that she was the least senior staff member, she was now safe from seasonal layoffs or other cuts to hours.
> Within the first couple years we had fixed the network and made it into something useful.
> The consequence was more use by upper management and as you might expect, more management
> from upper management. Every time we met another goal, the more visibility we received.
> The more visibility we received, the more layers of management they installed above us.
> Every layer of management installed made it harder and harder to actually get anything
> done, basically because each new layer of management knew less about IT but more about
> "managing.".
>
> I guess mostly I'm just whining here, but eventually most of us who had built the network
> quit. They 'managed' us right out the door.
Rambling follows. Cogent or indicative of caffiene deprivation?
There's a certain point of view among many sysadmins and developers that an ideal worth striving for is to avoid needless rework and busywork. If a task needs repeated, automate it. The lazy sysadmin / developer is the best. See Robert Heinlein's 'The Man Who Was Too Lazy To Fail" in "Time Enough For Love."
Among many managers, there is a point of view that says a constant hum of visible activity is a goal to strive for. It a task needs repeated, this indicates the importance of the task and means that it must be MANAGED. Managers can't manage shell scripts and other automated tasks, so it -has- to be done by a person. Manually. With mind-numbing repetition and constant reporting of progress to managers in charge of managing the lucky SOB who got assigned the task.
I think we need more lazy managers and fewer "activity for activities sake" managers. I KNOW we need lazy managers managing the lazy sysadmins and developers, and active managers managing the "Hmm... when was the last time you rebooted this Windows box?" folks.
What's a bank? In the US, banks are normally regulated by the 50 states, each with different rules and regulations. In addition, there are credit unions, savings and loans, insurance firms and a number of other brick and mortar institutions that have many of the normal functions of banks. Could they register .bank domains?
.bank domain to non-US institutions? This would seem reasonable if we are talking about Barclays, Deutsche Bank, etc. But do do we draw lines? Do we include little institutions incorporated in tiny little corrupt nations? How do we ensure that firms in these countries don't register names that sort-of look like large, reputable institutions?
.com domains because that's what people are used to?
Do we open the top-level
Whose laws do we use to take action against violations? In the US alone, you could be talking about 51 distinct court systems, each operating under different laws.
And would banks -really- flock to this? Isn't it just as likely that they would insist on using the
From the original: "The creation of a new domain for a specific industry is not unprecedented: We've already done it for museums, with their restricted ".museum" top-level domain. If we can manage to protect storehouses of precious works of art from the Internet's most shameless thieves, surely we can find a way to protect our money."
And millions upon millions of working men and women use that restricted ".museum" domain for their many daily museum transactions, right? There is a distinct difference between getting a fairly small group of people in a rather specialized field to validate transactions in this fashion and teaching millions of busy, technically challenged people to do the same.
A large percentage of attorneys can use LexisNexis; that doesn't mean it's suitable as a replacement for Google and Wikipedia.
Mostly agreed, with one modification and some additions:
> Remember: sometimes a manager has to be a jerk.
> sometimes a manager has to be the heavy.
> Don't look for the nicest person.
> You HAVE to be the bad guy once in a while.
Yes and no. Yes, you have to be the heavy sometimes, you have to be the bad guy sometimes. But you don't have to be a jerk about it. I don't think you meant that a manager does; But some people do seem to feel that you have to be the heavy in the obnoxious a**hole way, and you don't.
> A good manager is one who lays down the bad news
> and then still can motivate the team to perform well.
Bingo. He -has- to be able to motivate the team. I'd consider asking the candidates how they delivered bad news to the team. How did they keep the team motivated? I'd ask them for one or two examples of each of the following:
- a case when they had to tell their boss/customer 'no'.
- a case when they had to get rid of a team member.
- an example of how they dealt with a challenging or even impossible delivery date.
- a description of their ideal developer.
- a description of their ideal boss/customer.
People skills are funny things: some people are fine dealing with their superiors, but can't deal with subordinates. Others are the reverse. Good managers need to deal well with both.
A couple of points:
> Since the overwhelming majority of fathers behind in their payments is because
> of inability to pay,
(Majority of fathers) != (majority of -children-), nor (majority of dollars).
Many deadbeat dads (and I'm referring to the real -deadbeats-, not those in tight financial situations) spread their seed around to any gullible girl they can find. Tracking down that minority could make a huge difference.
And a certain number just walk away, alter their records slightly, and abandon the kids.
> Child support (and alimony) are pretty much set in stone and a change in the
> man's employment situation doesn't matter.
Support -terms- are set in stone. Execution of support terms is fuzzy; there are thousands of cases where fathers made payments that were never credited, payments were never forwarded to the mother, and a dazzling array of bonehead screwups by bureaucrats, compounded by lack of traceability. A decent database could help that a great deal.
It's not a universal cure for all ills, but it would help in adressing some of the problems.
>...The problem with Clippy and other avatars was that it was:
Actually, in addition to the problems you noted were the following problems:
- You could not choose, in a custom install, not to have the damn avatars in the first place. You had to install, then disable them
- The method for disabling the avatars is placed in a non-intuitive location
- You could not reliably disable avatars in the first release of Office to have them; like things buried in the Pet Sematary, they kept coming back.
Similar problems exist in the "Clipboard Enhancement" that allowed Office apps to store more than one item in the clipboard, and pop up a stupid dialog to select which thing you wanted to paste. That turns off by dismissing the dialog 3 times (WTF, MS?), and can come back if you copy twice without pasting.
"Bad Pet Rock! We do that OUTSIDE!" - Peter Griffin, 'Family Guy'
> The reason why "MS Windows is still the most convenient platform for consumers"
> is it is installed on the PC (unless you build it yourself) prior to you getting
> it, there is little if any choice about it.
Oversimplified; not -wrong-, just oversimplified. Yes, there are viable, user-friendly, inexpensive alternatives to Microsoft...but there didn't used to be. Macs used to sell at a significant premium over PCs, and have less, usable software available. *nix boxes used to be either too expensive or too difficult for the home user.
It's different -now-, but it takes time for these factors to hit the mainstream. Vista may accelerate this process.
> I will admit Linux games are not on par with the Latest PC games because few
> vendors make native Linux games (that is not the fault of Linux) but if I want
> to play a game I prefer console games, so no loss there.
Games are getting better, too. they're behind the cutting edge, but they are better.
> citing that the right to bear arms only applies to 'a well regulated militia.'
;>
Nitpicking on terribly poorly worded statement.
The second amendment states: 'A well regulated Militia, being necessary to the security of a free State, the right of the people to keep and bear Arms, shall not be infringed.'
Which clearly guarantees the right to keep and bear arms to -the people-.
Arguing that the -goal- of the amendment, based on the stated desire to promote a strong militia, is to limit gun ownership to 'official' militiamen is reasonable, although I don't support that view. But the -language- clearly states that the right applies to the people.
You can state that the -intent- is that it should be restricted to a 'well-organized militia' and people may argue about whether you are right or wrong, but you can't 'cite' language that isn't in the document.
Breakdown of amendment:
'A well regulated Militia': what is the goal of the amendment?
'being necessary to the security of a free State': why do we want to have
a well-regulated militia?
'the right of the people': who has the right?
'to keep and bear Arms, shall not be infringed.': what right do they have?
I'm not saying, "They can have my gun when they pry it out of my cold, dead hands". I don't own any guns.
I'm saying, lawyers are -supposed- to be well-educated people, trained to think clearly and express themselves clearly. Unless, of course, they are intending to mislead someone... Nahh; D.C. lawyers are too ethical to do something like that
Sometimes I've found management to be an obstacle in enforcing some of these types of rules. If that happens, a few ideas for coping:
...
....
> 1. Limit access to deployment server - only one or two person can access the server.
Sometimes managers insist on either retaining their own access to production boxes or delgating that authority to the 'village idiot'. See below.
> Even better - create automatic deployment scripts that can be run on the server by those persons.
If the wrong people are given access to the production boxes, try to limit everyone's access to running a limited set of scripts that log all operations performed, along with who did them, and let you easily roll back the last change. Don't let anyone access the box directly. Then put together an automated failure report that tracks what changes occurred before the box broke. This information can be useful in the uphill battles to stop the idiots from breaking the server.
If the question "why did the server go down?" comes up every month, it's useful to have a printout ready that says that each time it happened was immediately after Jimmy moved untested code into production, along with details.
> @. Create staging server - where you deploy the code from repository. Do not deploy to
> production until you get a "go" from the client on staged version.
Also, if the validation process becomes subverted by pushes to "get it out the door", set things up so it can be easily rolled back.
> 3. Use Trac -
Never used it, but it sounds like the kind of thing you definitely want.
> 4. Use framework - frameworks usually come with a set of coding concepts that ease code reuse.
Maybe; some are good, some are bad. I've had the misfortune of helping developers select the right framework, only to have management scrap the recommendations and buy overpriced crap that's "oooh, shiny!". If you adopt frameworks, treat them as "on probation". Review and be prepared to get rid of them if they aren't supporting you.
> 5. Communicate findings about bad practices - just talk with your colleagues and tell
> them how can they write better code, with examples
Don't preach. Write it down (Wikis are good for that), and reinforce it in a non-threatening environment like peer code reviews/stand-up meetings.
> 6. Introduce unit testing -
Agreed.
> So how does any user clicking add any CYA aspect to the GPL?
The only way I can see this as CYA is in a corporate environment, it would protect (in a very small way) the distributor from accusations by someone who reused the code in an application that was released in a way that contravened the GPL.
I've seen some corporate lawyers go bats over developers and techies who downloaded tools, and some of the developers tried to claim they were unaware of licensing limitations on copying the code.
Just a thought; I may be wrong.
> If you can only fill in one page, then keep it to one page.
> If you need 10 pages, fill 10 pages, but try to put the really
> good and recent stuff on the first page.
Have to disagree. Not that one page is a firm rule, but ten pages is excessive. The main purpose of the resume (at least in the US) is to get an interview or call. Ten pages of detail doesn't help you do that. Pare the older/less relevant stuff down to a series of short summaries, and add "ask me for more details". If you're in the ballpark, they'll ask. This is particularly useful when companies put every cool catchphrase they've ever heard of on the list of qualifications.
Bring the ten pages of detail to the interview.
> Think long and hard if you want to work for a company that
> rejects you based solely on the number of pages you submit.
I don't know of any that reject people for sending too long a resume; but I know -many- that give the big, honking ten page resumes to Sally from HR to pare down to the "relevant" ones, and Sally isn't usually the sharpest tool in the shed. Sometimes Sally doesn't forward the resume because "I don't think he speaks English very well; his resume says stuff about Perl and awk and sed, and I think he's been sick; I saw something about Mono on his resume?"
>> Developers can switch teams and/or projects any time they want, no questions asked;
>> just say the word and the movers will show up the next day to put you in your new
>> office with your new team.
> Having developers on a merry-go-round between projects is probably a good reason
> why their products never make it past the Beta stage
A couple of points: the poster said "developers -can- switch teams and or projects anytime they want". Your criticism, while it has some validity, is not directed at the idea that developers -can- switch projects, but at the consequences of them doing so too frequently. Consequences that are identical to the consquences of managers moving developers around too much, overscheduling them on projects, and psychotic "matrix management", all of which would be reduced by allowing developers to change projects at will.
If you can't let developers choose their project teams, it might indicate that management has backed too many doomed projects.
>> There aren't very many meetings. I'd say an average developer attends perhaps 3
>> meetings a week.
> One meeting a week should be sufficient. Three meetings a week spells inefficiency
> and poor process.
Maybe; depends on what the meetings are like and what they are for. 10 or 20 meetings a week are probably not too much if they are ten minute, "how do you want to handle this?" meetings.
>> there aren't Gantt charts or date-task-owner spreadsheets or any other visible
>> project-management artifacts in evidence, not that I've ever seen.
> Okay, so now we're advocating against the use of project management techniques?
> Let's piss in the wind and hope it lands where we intended?
I didn't read the poster's statement that way. The kind of documentation you mention can be useful, -if properly used-. In many places I've worked, they've been used primarily to obscure the fact that the emperor has no clothes.
Thanks for the interesting read.
> A few things I can tell you to steer clear of is Microsoft Certified .... In my workplace, all I hear is people making
> Solutions Developer
> fun of those certifications over and over and over again. I don't know
> if they are jokes but from what I hear, it's a stupid idea to pay for them.
The Microsoft certifications, in general, have really been devalued by people trying to cash-in on marketplace demand. But even the less stringent ones, like MSCD, have some value in terms of employment.
But you need to know that being an MCSD -won't- get you a job; the most it will do is allow you to compete for a job on your real qualifications.
It's not a Willie Wonka Golden Ticket to success; but -not- having it may cause the lower-level staff who look at applications before they get to the hiring manager to file your resume in the "don't call us" file.
> or Microsoft Office Power User...
MS Office Power User, eh? Sounds like MS trying to milk the market dry.
Let me start off by saying I have never seen a decent cubicle layout, or a decent cubicle outside of a magazine. They may exist, but judging from responses by others, they are more rare than most of the animals on the endangered species list.
> Cube farms have many cost and flexibility advantages that should not be
> dismissed out of hand. They can be reconfigured for less construction
> cost and disruption, are easier to wire, easier to light, easier to
> ventilate, easier to build, and much cheaper. You may also save on
> the office lease if the landlord won't have to tear down too many
> fixed walls for the next tenant when you leave.
You used comparatives all over the place in that paragraph; easier...to build, wire, light, ventilate, etc., without once mentioning what you were comparing them to: private offices. Yes, they are cheaper than private offices, easier to wire than private offices, etc., etc.
So is a cardboard refrigerator box, but I wouldn't recommend one as an workspace. I'm not being facetious; by dismissing private offices in your paragraph above, the way you structure the argument also discards out ot hand other options, that are also cheaper than private offices: shared offices; an open floorplan; probably many others. The choice isn't one thing or the other; the real decision is to find the right mix of cost and utility.
> Simply put, there are good cube farms and bad cube farms. "Bad" cube
> farms have partition walls under 6ft, beige upholstry, poorly designed
> desks, no door, poor insulation, no open collaboration areas and no
> rooms with doors for meetings.
Agreed on all points, and a few others to add to it:
- Tech-unfriendly design: many cubicles are designed for people who use exactly one PC; never need to refer to technical manuals; never need to keep things under lock and key; never need to keep large amounts of printouts. They have itty-bitty drawers without locks, no shelves for books, and no %$#@! extra flamin' electrical outlets or network jacks for when you need to test on a second box.
- Small desks, just big enough for a PC but not to have a binder on the desk at the same time.
- Tiny little spaces for monitors, so you can't shove a 17" screen back all the way and end up sitting with your bloodshot eyes 2" away from it.
- No %$#@! wallspace for tacking up diagrams with pushpins or hanging up a whiteboard.
- No extra floorspace for just talking with -one- other developer and seeing the same screen or whiteboard.
> "Good" cube farms are possible. Select good partition walls that are 8' tall
> (but do not stretch all the way to the ceiling), have doors and have good
> sound insulation. Look for an attractive pattern on the cloth, a design
> with very configurable and comfortable work surfaces, roll-under file
> cabinets, etc. (Some old Steelcase stuff we have at work even has
> electric raising and lowering motors for the desk!)
All sounds good; add extra outlets and network jacks, built-in locking bookcase or room to put a freestanding one, and enough floor space for 3 people to look at the same monitor/whiteboard at the same time without getting a neck cramp.
> To go with ANY office area, you need areas with comfy chairs, swing-out
> writing surfaces, and whiteboards and projectors. These are great for
> collaboration, but folks can still retreat to their cubes when they need
> privacy. You can have the cubes surround the open areas if you wish.
> For manager cubes, it would be a good idea to have walls that go to the
> ceiling for private personnel discussions. You will also need conference
> rooms for your more "rambunctions" meetings, speakerphone conference
> calls, client meetings, etc. These should be equipped with projectors.
And enough of them; at least one per floor, and enough that one or two are empty more often than n
I apolologize in advance for any offense; that's not my intent.
> 1. No company in their right minds wants to pay for TWO programmers
> to do a single job.
True; but if a company has paid 20 programmers to do the work of onten (sub-par) programmers for some time, they can be convinced.
> 2. As with any other method, it assumes all the specs and implementation
> have been worked out before the code is even written....
That sounds like BUFD, not XP; have I misinterpreted your meaning?
> nobody has the freedom to write experimental throwaway code to even see if
> their approach is even feasible in the coding,
Sure they do; I've done it hundreds of times for -very- grateful managers. They'd much rather I test an idea with cheap throwaway code than try to implement an expensive, untested idea we can't afford to change later. They'd prefer to find out without even a few hours of coding, but sometimes that isn't possible.
Device comments snipped; I don't program devices.
> 3. While its great at letting the mundane functions be rewritten (refactored)
> as many times as possible, it gives a mechanism where newer features are
> *always* put off (by managers usually) indefinitely....its an illusion,
> under a few managers, that the programmers will ever get to implement
> the newer features wanted by customers
Sure doesn't sound like XP to me; sounds like you bought "Dr. Quack's new and improved miracle elixer - now fortified with XP from the healing waters of Casablanca. Guaranteed to cure what ails you or double your ailments back!"
> I always find it really is better for a group of Programmer Peers to
> sit down together and review the code AFTER it has been written (with
> tests). Trouble is, most companies/managers refuse to understand that
> 'Programming Peers' do not include the stock boy in shipping.
So, let me get this straight; you did something someone called XP...but apparently wasn't. It didn't work, and you find good old code reviews work better...except you aren't actually getting to do peer code reviews either.
To paraphrase G. K. Chesterton, "XP has not been tried and found wanting; it has been found politically difficult to implement, and left untried."
Anyone else have a different take?
> ...However, if you are looking for all the in-and-outs of how an employer can screw
> you and asking your questions from this viewpoint, it comes across quite clearly
> and an intelligent hiring manager will know that you will be someone who will be
> very difficult to with as you lack any ability to have any trust for management
> in a business environment.
True; however, trust is not valued in all companies. I value it, and look for employers who do; but many employers do not. They usually -say- they do, but their actions quickly show that they reward the treacherous.
> It is never in an employers best interest to screw over its employees.
True; but some employers -believe- it is in their best interest to screw over its employees.
> If an employer does think this, his company will not suceed as he will
> just drive away his best employees.
This is a level of long range thinking many businesses do not support. Business managers do not always do what is best for the company in the long run. Often, they focus on the short run as well. A good indicator is to check on how long the manager and his boss have been with the company. If they just came in 2 months ago, replacing a guy who was there for 3 months, who replaced a guy who was there for 2 months, chances are the company doesn't encourage long-term thinking.
> As to the original poster questions, it is never too late to attempt a career change,
Damn right.
> especially if it is something that you are really interested in. Just keep in mind
> that you will be starting at the pay scale that someone in their early twenties
> would be getting. Is your life style going to accomodate that?
Very true. On the upside, you may also advance faster than the guy in his early twenties when they see your work. Often the twenty-something will be out partying all night, showing up late, and checking in broken code at 11 PM. Often the boss sees the difference quickly.
> ...you have to break your tasks down into small tasks with known dependencies to
> the point you *can* estimate times to do things.
Also, Cliff, don't forget to account for the fact that some of these tasks are also interdependent, and count time to integrate the components created and test them.
> Once you get that far, experience (gut feeling) will contribute. After that, you
> give an optimistic and pessimisitic times to your boss. Example: If all these
> assumptions hold and these other three things happen on time, then the time estimate
> is one week. If this, this, or this doesn't pan out as expected, then the time
> estimate is three weeks.
Good example; Cliff, note that the pessimistic estimate is *3 times* the optimistic one in the example. That's pretty typical. A lot of people use a pessimistic estimate of (optimistic * 1.25) or 1.5, but your pessimistic estimates really should be significantly larger for many tasks. Think about the things that might go wrong. Sometimes, they don't go a little bit wrong, like "it was harder to integrate with product XYZ". Sometimes they go really wrong, as in "it -can't- integrate with product XYZ; this feature of XYZ is broken and won't be fixed in the future."
Have to push back here. The problems with ratings systems (TV, Movies, and Video Games), have -always- been made worse by the unwillingness of the industries to provide -full disclosure-.
The ratings tags (X/R/PG-13/PG/G and TVMA/TV14/TVPG and TVG) were created by the industries. Parents groups and other groups wanted explicit labeling according to meaningful critera: is explicit sex shown? Explicit violence? How many deaths? Etc, etc.
In each case, the industry wanted to weasel through, so -they- chose criteria that put sex and violence in the same category, and tried to come up with "age-appropriate" guidelines.
Full disclosure is good.
> "Computer literacy is becoming an increasingly used term in education, and
> more and more schools are being asked to set computer literacy goals for
> their students. Unfortunately for too many, it means being able to use
> Microsoft products, and that's all. However, I see it much differently, and
> I cannot help but think that computer literacy is all about using computers
> to be able to communicate more effectively. With that in mind does anyone
> have any recommendations for computer literacy goals, and how to measure them?"
Computer literacy, however we define it, requires basic thinking skills.
The user requires the ability and consciousness to
- read messages: error, status, and responsive, from the computer, attempt to understand what they mean, and decide how to respond appropriately. This means a "click monkey" who can't learn not to dismiss message boxes unread cannot claim computer literacy.
- attempt to discern patterns and relationships, understanding what the underlying system metaphors are. This means that people who can never understand that their documents aren't saved "in Word", but somewhere in a file system, cannot claim computer literacy.
- act sanely, according to the often used definition of insanity; trying the same thing repeatedly and expecting different results. This means that people who learn to can't slow down and watch what they do when trying to repeat a problem cannot claim computer literacy.
- attempt to learn the proper names of things they deal with often. People who can't learn their OS is Windows XP and not Word, cannot claim computer literacy.
Note that I said "can't learn" rather than "haven't learned."
The ability to receive clue is necessary.
>> "They don't look anything like Outlook..."
> That's a good thing isn't it? Outlook 2003 is an assault on the visual senses.
Agreed, BUT it's only a good thing in terms of actual usability and technical proficiency. In terms of getting that -initial buy in- from the business people; the initial agreement to -try- something else, it's a -huge- liability.
On the last half-dozen projects I worked on, -appearance- was the number one issue for users. It had to be "just so" and alternatives, even if they were superior, were not permitted.
> ...It's less obnoxious, however. Shows up in the right-bottom corner. And
> I'm not 100% sure it's a paperclip, I think it might be a lightbulb or
> something.
Oh, that thing. Yeah, It's unobtrusive enough I never really connected it with "Clippy".