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)?
Tell me more
×
Programmers Stack Exchange is a question and answer site for
professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
|
|
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. |
|||||||||||||||
|
|
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. |
|||
|
|
|
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. |
|||
|
|
|
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. |
|||
|
|
|
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. |
|||||
|
|
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. |
|||
|
|
|
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:
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.
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. |
|||||||||||||||||||||
|
|
in·stinct /ˈinstiNGkt/Noun
"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. |
|||
|
|
|
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. |
|||
|
|
|
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. |
|||
|
|
|
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. |
|||
|
|
