Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

There are times where I can immediately recognize and suggest a fix for a problem design pattern. However, there are other times where putting it into words just isn't possible. I know something isn't right based upon my experience and "gut instinct", but it might not be possible to pinpoint and refactor the offending code without writing tests or some R&D. For example, someone might say there are performance issues, or, the application is "slow". I know where to start looking, and I might even make a recommendation, but it's almost a subconscious effort. When is this acceptable (if ever)?

share|improve this question

closed as primarily opinion-based by gnat, MichaelT, GlenH7, Rob, Kilian Foth Jan 5 '15 at 12:03

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

A bad, unclear question, imho. It is acceptable when it gets accepted, which depends on the environment, where you give your answer; how much reputation you have, and what the usual procedures are. – user unknown Jul 22 '11 at 18:52

11 Answers 11

up vote 20 down vote accepted

Although subconscious you are really drawing on lessons learned from prior experience.

Conclusions drawn from experience sometimes can be hard to justify to another person because it makes sense "in your head".

The challenge is in articulating why you made the decision.

share|improve this answer
Mostly true. An experienced developer has all his past experience immanently in his mind. But I've experienced cases in which my gut feeling has tricked me twice in similar situations. – Falcon Jul 22 '11 at 17:45
Definitely for the final sentence - a gut instinct is often a good guide, but constructing a sound rationalisation is really a minimal sanity check. The difficulty is that "sound" part. After all, you want it to be right. It's a bit like debugging - if you don't switch mental modes to assuming that your rationale is flawed and trying to prove it, you're probably just fooling yourself. – Steve314 Jul 22 '11 at 17:49
@Falcon What do you mean tricked you in similar situations, like you thought you were right, but it turned out you were wrong? – Brian Reindel Jul 22 '11 at 18:00
@Brian Reindel: I was in the same situation twice. I first went down the wrong way and did it right afterwards. Years later, I was facing the same situation again and so I thought to myself: Dude, you've done that before. So I started going down the wrong road again and only got it right afterwards - again. – Falcon Jul 22 '11 at 18:02
+1: Start with intuition. Finish with proof. – S.Lott Jul 22 '11 at 18:19

It's always a good start, but needs to be further qualified. So when you're looking for options and places to begin, go with your gut--however if you can't prove that it's correct then you need to back away and start from a more objective position.

One point to consider though is your gut's track-record. Typically your instinct will improve with experience, and it's good to bounce your thoughts off a more experienced developer to see if they agree. Worst case is typically that you have to eat a little crow and you learn not to trust your instinct quite so much.

share|improve this answer

I think it should be perfectly acceptable to be able to say, "experience inclines me to believe ...some something or other may be the problem; however, without out some conclusive tests it is impossible to know."

I had a similar situation yesterday where my conclusion (based on experience) had to be proven by writing a test. It took 3 hours to complete; in the end my conclusions were upheld.

This leads to building a track-record with others and you will eventually be given more leeway when it comes to relying on your gut instinct.

share|improve this answer

Gut instinct can help lead you in the right direction but as someone responsible for your work you should be able to defend your design descisions.

If you come up with a solution that feels right but seem to be unable to articulate why it is a good solution, try to come up with different possible solutions and compare them and ask for the opinion of others if possible.

Changing perspective on your solution and comparing it to others will help you find advantages as well as disadvantages.

However independant of this advice the most important aspect is the situation you are in. Sometimes no solution is better than a bad one, other times a solution that is just good enough may be preferrable over spending the effort necessary for a perfect one. Once you gain the experience necessary to accurately identify the situation you are in the answer to your question becomes obvious.

share|improve this answer

An experienced programmers gut instinct is going to save time in pinpointing a problem. *Gut instinct should not be a deciding factor in determining a solution unless the software quality triangle gets in the way and you just need to get things done. You should follow up with a refactor or risk becoming a duct-tape programmer.

*Gut Instinct is ok in cases where "good enough" is in fact good enough. Over-engineering is a bad thing. Identify the varying points in an application and ensure those parts are well planned and designed.

share|improve this answer
On "save time" - I think of it like the "heuristic" in "heuristic search". It can mislead you and, with enough (which may mean infinite) time, you can be more reliable. But the heuristic almost always saves a lot of time. In a sense, it probably is that kind of heuristic too - a connectionist neural-net variation on the imperfect rule-of-thumb theme. – Steve314 Jul 22 '11 at 17:54
@Steve314 Agreed. There is certainly a point of over-engineering. And a point where good enough is good enough. I should have expanded upon this a bit. – P.Brian.Mackey Jul 22 '11 at 18:01

This is why you have to take those "useless" literature, composition, and liberal arts classes in college. Having a good idea isn't enough unless you can communicate and justify it.

If you're having trouble vocalizing the benefits of your solutions, read some books on design patterns or on code quality, like Martin Fowler's Refactoring, and pay attention to the reasons behind the suggestions. If you expand your knowledge this way, your gut will still lead you to good solutions, but then you'll be able to say, "Oh! I like this solution better because it's much more loosely coupled." Or, "I don't like this existing design because it violates the Liskov Substitution Principle."

Once you can name it, you can use the arguments of people much more knowledgeable in software design to bolster your own arguments. You'll probably also find a few instances where your gut instinct is wrong, but you realize that as soon as you hear the reasons behind it.

share|improve this answer

Never. Always have measurements, metrics, or accepted knowledge from a reputable source to back you up. If you think you know where to start looking for the problem, start your investigation there, but don't wall yourself into that area and close your mind to other possibilities.

For your slow application, profile it and find the methods that are taking the most time, make the appropriate changes, and reprofile. For defects, create test cases that highlight the defect and then pass once the fix it applied. For new software or changes, correlate every decision back to a requirement and have a justification for it captured somewhere.

This reliance on empirical data is what separates some random programmer from an engineer.

To add to this based on the comments:

Never say never. If the approach works its good enough. In some cases it is good to have measurements, metrics, or accepted knowledge but that would be a waste of time for most problems.

It's always important to have some kind of cold, hard facts to back up your decision, action, or thought. It doesn't have to be anything impressive. A unit test, log files, a passage from a respected source, performance numbers from the last handful of runs. Just something that you can clearly hand or show to other people (developers, managers, the customer) that they can see or make note of. There are no problems where this doesn't apply.

Almost agree. Intuition can be a good starting point. After that, totally agree: measurements are essential.

This is true. Intuition is an important starting point. However, you can't act on intuition alone. You could be wrong, or you could overlook another piece of the puzzle. You can start with a particular thought, but you can't close your mind to other possibilities, until you've eliminated those possibilities.

share|improve this answer
Too harsh. Good developers, with experience, build good instincts--they certainly need to be vetted, but never following your instinct is almost guaranteeing you're taking the long-road every time. – STW Jul 22 '11 at 17:24
@STW - "never follow your instinct" isn't the same as "always have ... to back you up". You can follow your instinct to a large degree, but still do sanity checks, collect evidence, etc. Absolute trust in your instinct... the mechanisms underlying that instinct are in significant part a product of our Cro-Magnon ancestors evolution, and not many of them were computer programmers. – Steve314 Jul 22 '11 at 17:58
Almost agree. Intuition can be a good starting point. After that, totally agree: measurements are essential. – S.Lott Jul 22 '11 at 18:21
@Thomas Owens: Except that the literal answer to the literal question is unhelpful. Expanding on your answer with something line "intuition is a good starting point" makes your answer more helpful in providing a direction instead of the necessary road block. – S.Lott Jul 22 '11 at 18:47
@Thomas: Yes, I have. And I see massive arguments about how to interpret it, which implies that it's largely meaningless. – Paul Nathan Jul 22 '11 at 22:10

in·stinct /ˈinstiNGkt/Noun

  1. An innate, typically fixed pattern of behavior in animals in response to certain stimuli: "predatory instincts".
  2. A natural or intuitive way of acting or thinking: "rely on your instincts".

"Gut Instinct" is a useful tool that can be a good guide to point you in the direction towards an answer. The more experience you have the more you can recognize and seem to just 'know' how to fix things.

While its acceptable to use to begin solving a problem it shouldn't be the answer to solving a problem. You should always be able to explain how you solved a problem. Even if its only to yourself. Otherwise you run the risk of having to rediscover solutions again.

Also not being able to explain can make you appear less cooperative or lacking in experience. While people like getting things solved businesses like knowing how something is solved as well so it doesn't have to be solved again in the future. It also shows you really know what you are doing and not just taking guesses.

So even if your solution was just gut instinct, take a moment to see why the solution worked so if asked you have a concrete repeatable answer.

share|improve this answer

Yes. Mostly. A gut instinct is an acceptable starting point. Particularly when you've written code for years and years. You start pretty much feeling what the right way is without too much work. Typically in software design there are many 'right' ways to structure a problem.

Sometimes you can articulate it cleanly, other times it takes a while to come out. Needing to have a data-driven justification for every design decision is wearying and quite often pointless.

Data needs to drive higher level questions like, "This is taking too long", or, "this percentage of users always click away". For performance, measurement is easy: it's very quantifiable.

share|improve this answer

There are many studies in expertise that answer this question.

The simple answer is "Of course". Human experts often use broken leg clues or heuristics to solve problems. A broken leg clue come from a scenario like the following.

"Harry is a highly regarded and well paid plastic surgeon living in upper Manhattan that is very involved in the high society culture. Tonight is the opening night of a new highly regarded Broadway play. Harry worked very hard to get tickets to this play and received them just this afternoon from a doctor who Harry highly respects and wants to work with. As harry walks out the door he slips on the ice and breaks his leg. Does Harry go to and enjoy the play?"

One expert system trained to analyse human behavior had problems with this kind of scenario because it didn't have the experience to recognize what breaking a leg at that point in time meant whereas a human can see the problem immediately without even understanding the implications of being a plastic surgeon and all the other stuff.

Experts recognize various clues within a problem domain without any effort. They sometimes don't even know they recognize them as you have noticed.

However that doesn't make them the "best" expert. The exceptional expert not only just "knows" when something is wrong (or correct) they are also able to explain in detail why it is so.

share|improve this answer

Academically the answer is no. If a student chooses a certain way to solve a problem, the instructor asks the student why the student chose that solution, the student will not receive credits if talking in circles something like "We chose this solution because it works...according to instict" or some undefined claim like that. An almost identical and also rather immediate approach is to compare advantages and disadvantages with different solution. The latter approach probably academically be approvable while being opinionated and subjective won't get credit.

In real world business though it could be perfectly good and even better in some cases to be more subjective and speak for opinions. So it's likely to depend on the situation and how you measure a successful software - commercially of academically- since very well designed projects still could fail to get successful and also very successful projects could have less than perfect design.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.