Tips & Tricks - Solving a simpler version of your problem…

[#1]

Tip #1 – The spinning wheel time-limit

Set yourself a time-limit for how long you will work at solving a problem, and possibly spinning your wheels, before you will seek advice from others. For most scenarios I’d say 15 or 30 min is about right, possibly a bit more when you are new to something – but definitely no more than 1 hour.

Seeking advice does not mean someone else has to take over and write the code for you, just bouncing ideas off from someone else or doing some Googling and other searching might turn up ideas for how to approach you problem.

Tip #2 – I can see clearly now…. that I’ve written it out
Pretend you need to write out your problem in order to get assistance (in fact, this might be true). It is surprising how often the act of writing out a problem in a clear, organized and accurate manner manages to shine a bright light on something you have overlooked while struggling deep within your code. In fact, often a much less complicated approach to organizing and solving the problem suddenly appears.

Tip #3 – Ask your sales people for help!
What? Why would I ask my sales people for help with a technical consulting problem?

When customizing software, one of the most productive techniques is to find some feature or functionality in the base product that works in a similar manner – then copy and adapt those techniques liberally. As consultants we usually assume we know the product very, very well and that we and have already performed a mental search. The fact is though, that sometimes consultants don’t touch some parts of the product nearly as often as others – Campaign Management, Contracts & RMA’s are all good examples. On the other hand, the sales people and pre-sales engineers in your organization touch all parts of the software on a regular basis.

Example:
Consultant – “someone wants a data grid where the user can select multiple rows from the grid and then press a button to do something to the selected records. I’m pretty sure that is not done anywhere in the stock product, but thought I’d ask in case I’ve overlooked something.

Sales person – Actually, I think there is one place if I understand what you are asking. Take a look at the Campaign feature – I am pretty sure the Targets tab has a data grid where the user can select multiple rows using check boxes as the first column in the data grid. Pretty slick actually and I kinda wondered why we don’t see that any place else in the product.”

Tip #4 – Solve a simpler version of your problem
This is the tip that helped me reminded me of the prior tips above. It is extremely easy to get lost in the depths and complexity of your specific problem – spinning your wheels, getting distracted by tangents, and finding yourself constantly “almost there”… but not quite ever finished solving that new challenge or problem.

Create a very simple version of a specific part of your problem – solve that problem without the distraction of other distracting behaviors and logic. This will allow you to focus on the specific problem and a clean, clear solution. Once you have confidence in the technique, you can introduce it into your larger, more complex scenario.

It is surprising how much people resist this advice… myself included at times – but it is equally surprising how frequently this advice solves problems, reduces stress, and yields better solutions. People most often say, “but I’m so close – just have a look at this thing I am doing right down here at line 596…”. Trust me, years of experience have taught me that it will actually be faster to take the time to create a simple version of your problem and solve that first, believing you are close to the solution is more often an illusion than a reality.

If you have a tip or strategy, please reply and share with others and/or create posts in the community when you figure out an interesting technique or problem solving strategy – which I suppose is really tip #5 (with acknowledgements to the Beatles).

Tip #5 – I get by with a little help from my friends
Share your experiences and knowledge with others here on this community and elsewhere, and they will share with you – so in the end we will all get by.

[#2]

Thanks for the suggestions, Todd. I especially like Tip #4. It is crucial to "remove all the noise" and to solve the simplest problem first. I suggest developers also walk through their code line by line to identify the issue. Guessing and making changes on the fly in hopes it will fix the problem may compound the problem. First, prove your suspicions in a debugger. Then make changes based on your findings. It may seem like a shortcut to see an error, make code changes, rebuild, redeploy, and retest but it is not. There is a lot of time wasted building, deploying, and retesting if your guess was incorrect. I am not casting stones as I fall victim to the allure of the shortcut more often than not. I also think it is important to change one variable at a time. If you have concluded the connection string is the problem, change the connection string and retest. Do not also change your SQL statement, for example. Granted, this is more applicable for resolving defects in a working solution. When starting a brand new project it is inefficient/impractical to write one line of code, deploy, and test. However, once the debugging begins keep it simple and only fix/test one thing at a time. Thanks again, Todd!

[#3]

Future "commenters" beware - the posted comment does not reflect your formatting. Lame.

[#4]

Great stuff Tim!

The advice about only changing one variable at a time when problem solving is especially good to remind ourselves about. I always think back to Chemistry or Physics labs - it is difficult to determine cause and effect with any certainty if you change more than one variable at a time.

[#5]

This is all great stuff.  On item 4, I frequently use this approach when dealing with a logical problem that seems to have inconsistant results.  Commonly, I get to the bottom of the issue and find that I have made an incorrect assumption.  Solving the simplier version of the problem in an empty VS project is my method of choice, as it takes alot of those asumptions away. 

[#6]

Great tips Todd!

It's amazing how much time I can waste "Spinning my wheels."    I'm getting better, but I certainly can get caught up in the event of the moment.  The suggestion on the timer is great!  Remembering to take a break and walk away from the project does wonders.

Indeed, simplifying the task at hand makes a lot of sense. Great suggestion from Todd.  Break it down and keep it simple.

 In most cases, I'll make changes directly in the deployment aspx file and move that to the AA, saving a lot of time.  Nice write-up Todd.

Now if  could get past this next problem  

[#7]

Don't rule out any possibility unless you can prove with 100% accuracy that it is an impossibility. I can't tell you how often over the years I have heard "that should have nothing do with it", only to find out/prove that a little investigation in that direction would have yielded a much faster response time.