Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 12 years ago.
Improve this question
As I have been testing sites, I have found reCAPTCHAs getting more and more difficult to read. Is it just me or are others having this problem too?
Along with this, I had a user this morning complain about receiving a Bristish Pound character in their reCAPTCHA. Of course the user didn't know what to do, even though I have message stating they can click the reload/refresh icon to get a new CAPTCHA.
Unfortunately, this implementation is on a site often used by people over 60 years of age, so more complicated or confusing CAPTCHAs are a problem, but the site still receives a lot of people attempting to produce spam.
Despite the opinions presented until now I actually like the reCAPTCHA system. I like it mostly because I consider that it manages to solve two problems at once: verifying human identity and help digitalizes writings (For those of you who don't know here is why it uses 2 words and not one : reCAPTCHA philosophy
So I encourage all of you to try passing the reCAPTCHA tests as often as you can because you are really helping a good cause.
The worst are the ones that are case sensitive. L, l, I, o O 0 ?
I have a hard time reading most Captcha's, but I agree that reCAPTCHA's are a special nuisance.
Yes, Captchas are getting more difficult to read.
Image of CAPTCHA http://img165.imageshack.us/img165/1253/picture3rs8.png
I can't find the link right now but I believe the Microsoft Passport (MSN and Hotmail) are the hardest ones to break.
The problem is that whenever software gets better at detecting the text, the text has to become more difficult to read.
The irony I guess is that CAPTCHA stands for "Completely Automated Public Turing test to tell Computers and Humans Apart" but it won't be long for computers to catch up and they become too hard for the majority of humans to read. At this time they'll go away and some other version of a CAPTCHA will be used.
Perhaps photo based CAPTCHAS using googles image labelling system?
Ironic, because although computers are certainly getting smarter, people are probably getting dumber, too.
I think they are getting harder, I know I tend to fail every captcha I try at least once, sometimes twice. There are good alternatives emerging though. For example, Geoff Appleby shows nine photos and gives a text description for you to select three of them (scroll down to the comments form).
Such a system would be very accessible to the profiles you outlined (the photos could be quite big). Also a lot easier to implement.
Definitely getting harder now. My most recent one had something completely indistinguishable, next to 'are' written upside down.
I find reCAPTCHA's to be the absolute worst for usability. I often avoid sites that use them.
I don't mind that sites need to do these tests, but they don't need to be so near-impossible to figure out.
Perhaps reCAPTCHA, as it starts to run lower on words that people get correctly, starts paring harder and harder 'unknkown' words as people filter out all the easy ones?
I think eventually CAPTCHA is going to stop being feasible and there's going to have to be some kind of universally recognized "passport" system for websites. Some kind of account that you pay a couple bucks for and it identifies you as a human when you sign up for a website.
Then, if you start using that account for your spam robots, you can get banned universally. Sites could even retroactively clean up posts based on those bans. shrug Just a thought
I've been identified as not-human several times by the Stack Overflow blog comment captcha. Now I just keep requesting new captchas until I get one I can read. Usually only takes ~3 tries.
Update: According to Ben Maurer, the Chief Engineer at reCAPTCHA, who commented on my blog about this, over 96% of reCAPTCHAs are solved correctly. So maybe we as a group are just getting dumber?
reCAPTCHA will always get harder.
As they make tools to break reCAPTCHA, they will be using the same technology to help digitize text, therefore only the ones that the latest technology cannot read will be used as a CAPTCHA.
Its spy vs spy, except its a win win for reCAPTCHA and human knowledge.
The only problem they face is if they have a reader that is so good it never fails, reCAPTCHA will no longer work, but it would be a good problem to have for digitization of human knowledge.
Quite a few downloading sites have just stopped using captchas. All you really need to do is log the IP address of the client and stop giving them access for x minutes.
Same thing can be used for passwords. Did the user mistype his password 3 times? Let them wait five minutes to try again. And give them the option to refresh it by sending them an e-mail.
About time we get rid of those captchas. Computers and algorithms have become fast enough to crack even the hardest ones. While only making it frustrating for people.
Yes. It is getting harder.
If everyone realized how reCAPTCHA works, everyone should pass even with an unreadable word. reCAPTCHA always shows 2 words: one of the words reCAPTCHA knows its ASCII representation through OCR, the another, you can fail, because reCAPTCHA doesn't know the correct answer. When I find a too difficult reCAPTCHA I simply type "verydifficultword" along with the readable word.
Yes, it is getting harder. What ever may be the good thing it does, it should be usable. I tried 3 or 4 times on their audio captcha and failed each time. Though captchas try to solve a real issue, for those who can not see the captcha image and have to rely on audio captchas it is a big problem. Also not all the sites which uses captcha provides audio options. In any case, I think we'll have to keep proving to these machines that we are indeed humans for a long time to come.
The thing to keep in mind about ReCAPTCHA is that they are images actually scanned from real books and articles. As such you have to be aware that funky punctuation and stuff can make it in--it's not just words. For example I've seen partial words that end in a hyphen (that obviously occurred on the end of a line) as well as dollar-signs, numbers (like 1. Something), etc.
I find if you bear in mind the origin it makes a heck of a lot more sense and is easier to solve.
Also interestingly, you only need to get one of the reCAPTCHA words right, because the other is used to aid in the digitization. However you won't know which is which. :)
Related
I am using recaptcha for the registration page in my website got from recaptcha.net. I feel difficult to read the two word that is generating automatically. I want to remove the dark circl at the back ground of the text or else single word to type easily.
Thanks.
Recaptcha is constantly evolving and the image distortion algorithm changes every once in a while to keep fooling bots. They used to draw a line though the word a while back, then they used very little obfuscation, now they have circles. The whole point of a Captcha is to obfuscate text, so yes, it is hard to read sometimes.
Here's a list of things you can customize. Using another obfuscation algorithm is not among the options. So there's not much you can do about it besides using a different Captcha.
I feel for you, there has been severe inflation in the level of distortion of the images in some popular Captcha solutions the last 1-2 years. If it has to be human-unreadable to be bot-unreadable you have to ask yourself if it was a good solution to start with.
reCaptcha certainly is often not very user-friendly.
Look for a better solution such as identify-the-symbol or the question/answer ones. The latter works great for special-interest sites as you can provide some questions new users should know the answer to!
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
Why is it more costly to discover a defect later in the process?
I've heard this a lot but I struggle to understand and put context/examples to this.
You're building a house. You're laying the sewer pipes into the foundations, but unknown to you one of the pipes is blocked by a dead hedgehog.
Would you rather find out:
Just before you pour the concrete
After the house is finished and the new owner tries to use the toilet?
(There's a "Stack Overflow" joke somewhere in this analogy . 8-)
The longer it takes to find a bug, then:
the more the behavior of the bug may have been accepted as correct, and the more other things may have become dependent on that behavior (Windows is notorious for this).
the more tightly integrated the system is likely to have become, and the harder the bug will be to extract.
the higher the likelihood that the bug's erroneous behavior will be duplicated elsewhere by virtue of copy-pasting or in clients that use the erroneous code.
the longer it's been since the code was originally written and the harder it may be to understand it.
the less likely it will be for people who understand that original part of the system to be around to fix it.
This can be illustrated in a simple (if not trivial) example.
Take a simple dialog with a message and just two buttons "OK" and "Cancel".
Assume that the error is a spelling mistake.
If this is found after the product is released then a new version of the product has to be released with all the costs associated with that. Manuals will need to be reprinted.
If this is found in final testing the manual will have to be reprinted. The code will need to be rewritten and tests re-run.
If this is found during development then there is just the cost of fixing the code.
If this is found during design then the code is written correctly first time - no cost.
The later you find out a bug, the worse. When you find a bug immediately after you code, you have all the behavior in mind, and know exactly what changes caused it. You will be able to focus on the problem, once you know where it resides.
When you take long, developers no longer remember exactly how it worked, and there are many more places to investigate to find the bug. Perhaps the developer who coded the bug is no longer working in the company also.
Also, as time goes by, more parts of the code will probably depend on the buggy code, and you may need to fix them as well.
Finally, there are issues involving users. If you find a bug after a release, more users will be frustrated by it, and your product image will be worse. Users may also be used to have a workaround for this bug, which may start to fail after you fix the bug.
Summary: When you take long to find a bug
Your scope to investigate is bigger
The developer who created the bug may not be there anymore, and the other developers will have to study the code more to find it, understand it, and fix it
You may also need to fix parts that depends on buggy code (and there will be more parts like that)
Users will already be frustrated by the bug, and the image of the product will be damaged
No-one ever understands the code as well as you do as you are writing it.
People may have come to depend on the bug being there.
You may have to fix up lots of bad data that the bug has saved away.
You may have to roll out a new version or patch of your software.
Your helpdesk may have to field a whole heap of calls.
You may have to fill in bunches of paperwork explaining why that bug exists and what problems it causes, and what you are going to do to make sure it never, ever happens again.
Because more people will have spend time with the defective software.
If you fix a bug at early on you and maybe a code reviewer will spend a little time on it.
If it gets released to customers and reported as an error, you will have coded it, someone may have reviewed it, someone may have tested it, somebody may even have documented it and so forth ...
There may be other dependencies (internal or external) which will affect the fixing of a defect.
For example - If I resolve this defect, I may have to fix something else
Imagine you're writing an essay on why it's more costly to discover a defect later in the process, and you suddenly realise one of the premises on which most of your essay content is based is false.
If you're still planning, you only have the half a page of plan to change. If your essay is nearly finished, you suddenly need to scrap the lot and start over. If you've already handed it in, the error is gonna cost you your grade.
Same reason.
For a shrink-wrapped software product:
If you find a bug after your product hits the stores, you will have to help users through support calls, suggest a workaround or even recall the product/issue a service pack.
For a website:
Site outages and delays cost you money.
Customer loss as a result of poor/malfunctioning site costs you more.
The debugging process is also costly itself.
It is probably an error by the question author, but the actual question is, "Why is it more costly to discover a defect later in the process" Within that question is the cost to discover the bug and we can hope it also means to fix it. Most of the answers do a good job at describing the cost to fix and why it is better to fix early versus fix later. And, I really don't disagree with any of them. But, that isn't the whole question.
I have a regular series of esoteric arguments with some about the discovery cost. How much testing would have been required to find a specific bug (without hindsight). Would it have take 3 man-months more of automated or manual testing before you would have been likely to find that test case and scenario ?
In practice, test as much as you can but finding that balance point isn't as easy as many would have you think. Most programs are too big to have 100% code coverage. And, 100% code coverage is usually just a fraction of all the possible scenarios the code must handle.
Another factor that comes into the cost of a bug is the business cost associated with the bug. Are there 5 million boxes out there holding the bug ? Would you have to do a product recall ? Will it generate X calls to your warranty help desk ? Will it trigger some clause in a contract holding you liable for damages. In very simple terms, this is why software written in the medical field costs more per LOC than those for website development.
Because of the development process and all the work involved in fixing the defect.
Imagine you find a problem in the function you coded yesterday, you just check out, fix, check in, period. It's still fresh in your mind, you know what it is about and that your fix won't have any side effect.
Now imagine finding the same bug in six month from now. Will you remember why the function was coded that way ? Will you still be working on this project/company ? You have to open a defect report, a new version of your software have to be issued, QA needs to validate the correction. If the software has been deployed, then all instances have to be upgraded, customers will call support ...
Now it's true that the curve showing the cost are made up to illustrate the point; it actually depends on the development process.
I would say that the most costly is to find a defect and let it be. The longer you allow the defect to live the more costly it becomes.
I was at a company at a time, where they had the policy, that once they had taken a decision, they stick with it. The system I worked on was loaded with bugs because of a stupid corporate framework that we were forced to use, and a deep misunderstanding of the proper usage of web services.
To this day, I believe that the cheapest way for that company to get a working, usable system, would be to ditch the entire system and rewrite it from scratch.
So my point is, that I don't think that finding a defect at a late stage is that problematic. But ignoring a defect until a late stage is extremely problematic.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
You and I want to be the expert on computer programming or website design, but sometimes a customer would rather try their hand at your specialty than concentrate on real estate sales, marketing, or being a former member of the Israeli army. Then we have a choice: either figure out how to tell the prickly customer their logo would NOT be better spinning in 3-d with a righteous lens flare, or perhaps suffer the small indignity of making link texts as verbose as possible in direct opposition to any style guide ever written.
Have you been able to convince your customers to focus on whatever it is they are trained to do so they will let you execute your technical skill to the best of your ability?
I always try to point my clients in the right direction with regard to design. Sometimes it's just not possible though; they want something that's dreadful design, but they're convinced it's essential to their system. If they're unconvinced after a modest pitch, I just do what they want. They are, after all, the ones paying me (usually) thousands of dollars to build to their spec.
Often the reason the client wants to get involved is they are concerned consciously or unconsciously you don't understand the details of their business or how they do it.
The best approach is to work with the client to learn their business. This involves zero assumptions and learning the "how they do it" of their business. From that, discover all the data they use, what states the data sits in at what point in their process.
Keep taking it back to them and eventually they will realize that not only do you understand their stuff, what they want, and what direction they want to go in, but that you might even know the implications or impacts better than them.
After this they will usually stay out of your hair. This can be hard though when working with micromanaging types, or engineers. By nature they want to know how everythign works which is great. The timing of when it's best to learn how it works is the tough part.
Often you can get stuck in more conversing about solving a problem than it would take to just fix it. Maybe you can tell us more about the client's personality.
The trick is to get them to make the right decisions, but think it's their idea. :-)
You can't have this conversation with them easily in the abstract, but you can drill down and guide them towards the side of righteousness on each individual decision. Eventually, after you've been through this a few times, they'll start to trust you.
If possible, it helps to wait a day. Tomorrow they may be less clear on exactly what they asked for. (Do they really have their heart set on a flaming logo, or was it just a whim?) Then, in your response, you: describe what you recommend, and why. Restate agreed-upon objectives, and show how the solution meets the objectives. And make it sound like it was their idea. ("The point you made yesterday about xxx is really excellent, and I think that suggests a yyy solution.")
At this point you have a choice. You can ideally pretend you never heard their silly suggestion. Or if you feel you have to, respond to it tactfully and explain costs. ("I'm a bit concerned about the animated logo idea, because it may not convey the brand image the way you requested. Of course if you want to go this route, we certainly can--in which case I'd suggest we get our graphic design consultant involved. Let me know if you want to explore this further and get a quote from the consultant for his services.")
I found that customers are always easier to convince by "optical evidence" than by theoretical arguments - so you could e.g. show them logos or the general style used on websites which won a price for their usability, or maybe even show them how some big competitor is doing it, and then point out the benefits based on what they see.
I've also once managed to get rid of a really terrible user interface suggestion by making screen mock-ups of how this feature would actually look and work - and I made sure to make thes mock-up as unappealing as possible ;-) When I presented them, the client quickly realized that there were better ways of achieving his goal.
Knowledge is power. When you know a client is doing something wrong, have the facts ready as to why and present them quickly and in plain english. You need to remind them why they hired you in the first place.
Bearing that in mind, sometimes clients insist on shooting themselves in the foot. Have backups ready, use version control, but most of all: don't antagonize them. Your reputation is worth a lot more than their 3d-logo-spinny site.
Very carefully.
You've got several conflicting issues here: you want to keep the relationship (and the revenue), you want to do good work, and you don't want to end up with your name on a turkey.
Start by asking lots of questions about the business aspect: what do you want it to do, who do you want to reach, what impression do you want to give. Sometimes that will let you turn the discussion to more useful topics.
If that doesn't work, sometimes it helps to mock up the customer's idea and your idea, and compare them; if yours is clearly superior, they may see it.
If not, sometimes you have to remember that contracting/consulting is a form of prostitution; you do what the customer wants, whether it's your favorite thing or not.
The other thing to remember is a lesson I got from another consultant years ago: some customers aren't worth the trouble. he recommended that once you have enough business to live, you make a practice of firing your least liked 10 percent of the customers. Over time you develop a customer base that you can work with, and give the turkeys to someone else.
The problem with customers is that they are the customer. They have hired you to do a project to their specifications. What they seem to have missed in your example is that they have hired you because of your experience. You need to remind them of that fact in a gentle way. Perhaps a story such as "At one client, we used a logo like that and they expereinced a drop in traffic. Once we switched to a flat icon the traffic returned." Doesn't have to be true, per se, but you need to sell it.
All you can do it explain to your customer that they hired you for your expertise in design, but at the end of the day, the customer is always right.
If you find you don't enjoy working for customers like that, simply state at the beginning of a new project that you require complete creative control. If they still want rotating logos, then you'll have to put up with it for that project but at least you can decline any offers from the same customer in the future.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
While novice software designers expect their users to behave rationally, it's far from being the case ; I've seen many times the user perception being totally disconnected from reality, or it's feedback obviously irrational.
I think we are the one who should adapt, not the other way around.
There's only one way that I know of to achieve this : listen to users, especially about what they don't like in software they use.
If there's one thing I've learned so far ; they often complain about things one wouldn't expect
What unexpected things did you learn from your users?
A few years ago, hospitals (at least French hospitals) were run using old win 3.11 software’s. Every single task was tedious; moving someone from one room to another would take 5 minutes to an expert user
A friend of mine was working on selling up-to-date software to those people. The same simple task would take 30s to a total beginner.
While most of the users were very happy with the new software, a handful were complaining, which wasn’t a surprise (there’s always a handful of users complaining). What was more unexpected was their reason: the software was damn slow. “The same simple task was instantaneous, now it takes ages to achieve. Give me my old software back”, they would say.
My friend decided to meet them, and asked them for a live demo of the slowness they were complaining about.
“Look, said the user, with my old software : I input the first name, enter, the name, enter, the admission number, enter, the old room number,[…insert 5 minutes here…] the new room number enter … and it’s done….. See… Everything is instantaneous”
“Now, look at your software. I do a drag and drop, as you taught me. And I wait, I wait… look, it’s done..I’ve waited for almost 30s….”
That’s a real world example. It really happened. I’m pretty sure that if the software had been modified to ask for useless information that it would have discarded afterwards during the 30s period, this user would have had a far better feeling with the new software
If you think about it there's no such thing as irrational user behaviour, there's just a mismatch between your expectations and theirs. The only way to close that is through dialogue. That doesn't necessarily mean going and doing usability studies, often the right dialogue is for them to read the help where the discrepancy is easily dealt with.
The only wrong thing to do is to not listen to what they are saying - or to listen and not really hear them (see the post on here about IE on the Mac - it's the height of arrogance). Of course you are going to get some people who just don't like change and will whinge about anything, but in general if a user will take the time to point out something in your software which bugs them, then you should listen. You may choose to ignore them, but if you listen right you may just as easily uncover a real gem.
I don't believe your users or customers will often innovate for you, but I strongly believe that they are the key to your software being usable, and usability leads directly to success. So to characterise them as irrational probably doesn't serve your best purposes - or theirs. Better to take them seriously to start with and filter out what you consider not to be good feedback.
Developing for a hand held unit many years back, I got contacted by a user who complained that their unit kept on turning off immediately after power on. It turned out to be a bug; the startup message ended with the line "Press any key to continue". It should have said "Press any key, except the big red key marked power, to continue".
One thing I have learned over the years is that time spent with end-users on requirements analysis prior to going anywhere near design is hugely important, as is understanding the culture and educational background of the users. Designing computer systems that look and work like existing manual systems is a good start, as is understanding the workflow. Another hand held van sales delivery system I was involved was specced to look for on-screen customer signatures on delivery, and this was necessary to complete the transaction. It turned out that most of the deliveries actually occurred early morning before anyone was there to sign for them, so the perceived workflow didn't gel with reality at all. The client IT staff didn't actually know this, nor did the business analyst. If you design systems without input from actual end users you do so at your peril.
In my previous job, I was designing a huge trading software for a huge bank.
The software would typically take around 5 minutes to launch.
Of course, the users were complaining a lot about the startup time, especially when the software was crashing during the day, which was happening from time to time.
From the day we added a detailed progress bar (progressing quite regularly, with an indicator of the number of remaining items), the complaints almost stopped.
Typical users would say "I used to take ages to load, but now, it's quite fast"
The next step for us was to display the user interface before the data is loaded instead of after (which makes more sense for an IT point of view)
This time, the modification resulted in a slight performance drop (from 5mn to 5"30), due to the cost of impacting the UI during the loading time.
From a user perspective, the software was much faster this way !!
I was once working on a cms for images. The admin would basically browse though pages of user-made images, and check the ones he wanted to publish. I wrote a nice manual on how the system works, but since everybody knows people don't read manuals, i put some guides on the page telling what to do (in this case, something like: "Check the box for every image you want to publish").
It wasn't long before some guy came pull my sleeve: "There's a bug in your program. It actually tosses the images i don't select, and not the ones i select".
The problem was solved by asking him to read aloud the text on the page.
While novice software designers expect
their users to behave rationally, it's
far from being the case ; I've seen
many times the user perception being
totally disconnected from reality, or
it's feedback obviously irrational.
I think we are the one who should
adapt, not the other way around.
Are you saying we should adapt to irrational behaviour? Software development is already irrational enough (dynamic languages, test driven development, ...), and you expect us to unilaterally bend over backwards to accommodate some distorted expectations?
A few years ago, I designed a small application which was mainly aimed at helping users to input complex data in a database.
Their old method was to input everything into an excel sheet (without validation of any kind), and then to use a vba macro.
My new program added validation, and was able to auto-fill almost half of the data they previously manually entered.
I expected to be a success... which it wasn't ... at all:)
"It's just impossible to use", they said...
I had tested it, asked my mother to test it... my software was fine...
In fact, those users were so used with inputting repetitive data that they used only the keyboard, not the mouse. And of course, I hadn't thought of managing the tab order correctly, so the cursor was just jumping all over the place each and every time they hit "tab", thus the "impossible to use" comment !
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
When I am stuck with a problem:
I search Google for code snippets.
I look at isolating the problem, so that I can better explain it to others in order to get answers.
What search techniques do you use to find the solution to your problem?
I started asking questions in Stack Overflow.
What other techniques or methods do you follow, to fix the problem more quickly?
Go and do something else. No, really. I've found that putting the problem away in the back of my mind helps. I can't count the number of times I thought of a great solution to something I've been working on when I was working on something else, or watching TV, or eating. It seems your brain is still working on the problem in the background.
If that fails to solve your problem, try talking to someone. You'd be surprised how often others can give solutions to your problem that are so simple you'd facepalm.
Well there's:
Google
Google
Google
Stack Overflow
Google
Google
Maybe a book if I have one.
Seriously, I started (hobby) programming in the 1980s and even into the mid 90s you had to know things and have a technical library. Then Google came along and it's easier to Google something than it is to look up (bookmarked!) API documentation (Google "java stringbuilder" will get me there faster than navigating will) let alone an actual book (electronic or paper).
Most problems you're trying to solve have been solved before. Many times.
The rest of debugging comes down to decomposition, possibly unit testing (which is related to decomposition) and verifying your assumptions.
By "decomposition", I mean that your solution is structured in such a way that small pieces can be individually tested and readily understood. If you have a 7000 line method you're (probably) doing something wrong.
Understanding what assumptions you've made is key too so you can verify them. For example, when I started with PHP I wrote a piece of code like this:
$fields = $_SESSION["fields"]; // $fields is an associative array
$fields["blah"] = "foo";
and I was scratching my head trying to figure out why it didn't work (the array wasn't being updated next time I queried $_SESSION). I came from a Java background where you might do this:
Map fields = (Map)httpSession.get("fields");
fields.put("blah", "foo");
and that would most definitely work. PHP however copies the array. A working solution is to use references:
$fields =& $_SESSION["fields"]; // $fields is an associative array
$fields["blah"] = "foo";
or simply:
$_SESSION["fields"]["blah"] = "foo";
The last thing I'll say about debugging and writing robust code in general is to understand the boundaries of your solution. By this I mean if you're implementing a linked list then the boundary conditions will revolve around when the list is empty.
Explain the problem to a colleague, or write it down to describe it. That will makes you think a different way, from a different perspective. In order to be more accurate, and to describe the context of the problem, you'll step back, get a higher level view of the problem, you may find out think you overlooked something that is actually important.
Sometimes, you even find the explanation before ending your description.
My best friend for many years has been to jump on my bike and go home. Just getting away from the keyboard has solved many problems over the years for me.
If the problem lasts to the end of the day, I try and consciously lock the problem away for solving before I go to sleep.
I realise this sounds a bit out there, but it has been very common in my experience that I'll wake up with at least an alternate approach to the problem, if not the full-on solution. The idea is not to stress about it - but actively decide to solve it over night. That way you can go to sleep without worry.
I think eating well, regular exercise and good sleep are huge contributors to the problem-solving process.
Usually I'll try nut out the problem for a few hours or so, trying different things writing it on paper, making diagrams. If none of that works I'll usually work through the following options.
Put a sticky note on my monitor and keep going with something else
Glance at the note through out the next few hours to keep the problem in the back of my mind
Google for similar problems and the methods used
Consult a co-worker or a friend
Ask on a forum such as stackoverflow
Give up and design the problem away or design a way around the problem so it can be dealt with some other time and stick a TODO note at the site of said workaround
Don't forget Google Code Search
It's often best to clear your head by doing something other than programming for a little while. See this answer for an example - I did it while struggling with a particularly thorny bug, and when I came back to the problem I solved it in about a minute.
Usually I try to solve it until I go to sleep.. Sometimes I write on paper what the code is doing and then I divide it in pieces; I try to know how the variables of the program change when it's running.
Try solving a much smaller version of the problem first and see how you get on with that.
Once you've done that the bigger problem won't look so scary.
Ask yourself: is solving this particular tricky problem really important to what you doing?
For the purposes of your application (or whatever the big picture is) is there a similar but easier problem that you could address to accomplish broadly the same thing.
Normally, I would get pen and paper and try to work out the details of the problem there. If that doesn't help, Google. Failing that, I'd do something else for a while, or ask online. Worked for me so far.
The fact you are stuck might be a 'code-smell'. Suggesting that their is something wrong with the design or approach somewhere else. Try to put your finger on what's causing this and fix this instead.
When you come back to your problem it might no longer exist.
One more time, browse thru what I think might be relevant, then take nap.
There are two other answers which mention sleeping or napping, but this deserves more emphasis. It is now known that there's SERIOUS machinery in there which goes to work when you sleep. Google (( CBS SCIENCE SLEEP )) will get you to a great free video.
If I can't figure out how to solve the real problem, I try to consider a simplified version of the problem. To take a simple example: I recently had the problem of finding a set of shipping routes to get an item from point A to point B, when there is not necessarily a direct route from A to B, but there might be an A to C and then C to B, or A to C, C to D, and then D to B. (I'm sure the airlines and railroads do this all the time.) That was fairly complex, so I tried looking first at the simple case: a direct A to B. That was easy. Then consider how I'd handle it with one stop along the way. Then consider two stops. At that point I was able to see the pattern to a solution.
Solutions to a simplified version of the problem may end up being a part of the bigger solution, with some additional complexity wrapped around them. But even if not, the exercise of solving the easier problem often gives you ideas on how to solve the real problem.
The main techniques I use (should be followed in order so that you can reuse what you have done in previous steps to be more efficient):
Define your issue: Try to clearly define what's the problem, and what's expected. See 2 to help you.
Collect data about the bug: Log everything: your attempts, the expected result, the observed result. This will avoid the need to redo several times the same tests (because your mind cannot memorize it all), and probably help you see the bigger picture.
Reduce your problem. This is true in general for any abstract modelling of natural phenomenons, but it's even more true of programming, because programs are very complex entities. You should try to reduce your code to a minimal program that reproduces your issue. Automated tools exist.
Talk to someone: several anecdotes affirm than about 2/3 of the bugs are resolved just by talking about it. See the Helpful Teddy Bear anecdote. If you have previously reduced your program to a minimal program, and have a clear definition of your issue, both will be useful to your explanation.
Reach for collaborative help: search on Google and on StackOverflow, and post if you can't find anything that answers your problem (but first see 1, you must have a clear definition of your problem).
As you can see, I put the collaborative help as the last step, because you should only ask for help after you have clearly defined your issue and tried to reduce the problem and fix it by yourself. If you reach for collaborative help before having tried the previous steps, you will either end up with a poor help or figure it out by yourself as soon as you have posted.
Also you can be interested in the Coursera Software Debugging course, which also describes several automated debugging methods.
Go to the toilet.
You move, so your brain gets oxygen.
You relax, so you focus on other things.
Peeing for innovation! :)