The Fine Thread between Being a Good Researcher and a Good Programmer

Last updated on 2012-12-10

My “day job” is studying a PhD in Information Systems Management, where I am investigating the executable aspects of OPM (the Object-Process Methodology). While doing this I am also developing an open source tool where I am able to create OPM diagrams, and my plans are to use this tool as the interpreter of the OPM modeling language that I am creating (OPP – Object Process Programming).

As a researcher, how the code looks, how much it is tested, patterns, style, etc.. is of no matter to me. What matters is the result: can I prove using the tool that OPP is really a visual programming language which can be executed? On the other hand, as a programmer, all of this things are of interest to me. Writing “good” code is something that must be done always. Writing unit tests should not be optional. The code should be documented. But these two views are in constant battle because of the limited time in the world. If I want to advance faster in my research, I must write “ugly” code, because writing good code takes more time, no matter how good you are. Documentation takes time, writing unit tests take time.

So I am walking this fine line, on the hopes that I will have enough time to create good enough code so that at least complete strangers who download it will be able to read it. And if you are one of these strangers, please forgive me if I didn’t manage to do the job right.