As a software engineer I know from day one that reusable components are our best friends. Gradual development of the product – which is really possible with software unlike many other things – helps dealing with the constantly changing and improving requirements. Systematic work results in predictable deliverables: almost on time and providing functionality just as specified. Okay, we all know that this never happens as is, but at least something similar takes place, something that could be used as a basis for example agile project management.

When scientific research enters this quiet world almost everything changes. Your estimates that were almost precise due to decades of programming experience – read: you need only twice as much resources to finish your task compared to the original estimate – blow up: when the ratio of fact vs plan goes up to ten you are still wondering if it is ever possible to solve the problem. And not only is this embarrassing: you constantly have to go against the principles that you have learnt as a software guy. For example you have to rewrite most of the code all the time. When you replace your good old algorithm running in exponential time with something that takes only polynomial but considers a whole bunch of simplifications and approximations of the actual problem then almost no code line can stay in place. You feel that your previous work was a waste of time – at least if considering the actual piece you have put into the product.

And what about the heritage of history: books get you excited, you are not only learning while reading them but you are also filling up your batteries regarding optimism and enthusiasm – you tend to feel that knowledge helps and by the end you will solve the actual research challenge as a finger exercise. But actually that’s almost never the case. Slight changes in the problem definition might flip everything down and a completely different solution might become necessary. The patterns that you learn from others are crucial regarding developing yourself but this is only the very first step on a long way and most of the time the best use case of books is to sit down on them…

Or lying on them…

Or sleeping on them…

Or…

…you get it.

So what helps, what is the magic bullet? If there is any… well, if I would know the answer then probably I could go on holiday for the rest of my life just after documenting it. Or… trying to survive the attacks of maffia attempting to make money out of this exceptional, wonderful secret.

Seriously… there are good practices. There are also signs that you can pay attention to. There are patterns in your iterations while jogging around the same problem for days, weeks and months – these could be also recognized and used for both project management and teamwork. You don’t have to feel alone and being crazy while working day and night without a working solution.

Signs on your way that you should pay attention to:

• something works what you didn’t expect to…
• the approach you are experimenting with is a lot simpler than the previous one…
• the method seems to be trivial…
• you can explain your solution in depth with a couple of sentences..
• you feel that the final solution is just a couple of days ahead…
• you can hack a demo easily…

… these all mark that probably on the right track.

Some best practices that I found useful while solving bioinformatics problems:

• go for the smallest possible subset of the original problem
• start with the best input you have
• pick the easiest way to solve the problem
• try to keep things simple, ignore design patterns
• drop things not working, don’t try to rescue any piece
• never ever be afraid of local maximums where you could get stuck

… and don’t forget about your best friends:

• common sense
• Google
• visualization
• measurement
• rubber duck (really 🙂 )

… also simplicity delivers you a couple of rules of thumb:

• when you delete more code than you write you are on the right way
• the less parameters necessary the more robust your solution
• always feel free to start from scratch if it is simpler
• don’t waste your time on backward compatibility – it’s not for research
• always put things into order before moving on – it frees up your capacities
• bear in mind that shorter code is not always the simpler

… and finally the gifts prepared for you at the end of the road:

• heureka feeling
• persistent knowledge
• valuable experience
• trust to never give up
• respect for nature
• something what you can share

I wish you find these useful, dealing with problems of the nature is one of the best tasks at work – never give up and enjoy!

/ By György Horváth