I’m an academic. I’ve never had a full-time developer job in my life. Yet, I write and screencast about software development. Why the heck should you care to listen to me?
Yes, I’m an academic. That makes me special. I’m sitting in my own particular boat, which means I face my particular set of challenges, originating from my boss’ expectations, the domain I work in, the colleagues I work with, my private life, and the voices in my head.
Awesome. Then you’re as special as me!
Being special is great, isn’t it? It allows us to leave behind the chains that bind others. We don’t need no source control! TDD is dead, long live cowboy coding! They may profit from continuous integration, but our situation is completely different! Don’t you see? We stand above the laws of men; the laws of physics; we make the rules; we…
No. That wasn’t it.
That’s not to say that my situation isn’t special. It is. About as special as anyone else’s, I guess. I do develop software for academic purposes. “Research prototypes,” they call them. But aren’t these prototypes just minimum viable products (MVPs) to reach a research goal?
MVPs… that’s what the agile folks are out for, right? Take a supposedly valuable feature, implement a minimal solution, deploy it, get feedback, adjust, repeat. Sounds like the scientific method, if you ask me.
Does that mean research is agile?
If research and agile development are indeed alike, can we learn from one another? Let’s see…
In research it is important to communicate. After all, we are measured by our ability to publish our results. Therefore, we need to explain our ideas, experiments, and results to students, to fellow researchers, to industry partners, and even to the government, if we need funding.
Our goal is to find simple solutions. Elegant answers to the problem at hand. Conceptual solutions, boiled down to their essential components. Only as complex as they need to be.
We also require feedback. Lots. First from fellow researchers, to validate our ideas, then from experiments or studies, to evaluate our approaches, and then again from researchers, to validate our conclusions.
To do all this, we need the courage to take responsibility for our ideas and hypothesis, to take feedback, and to accept that our attempts might fail.
We also need respect for the people we work with.
Funny, isn’t it? How the fundamental values of eXtreme Programming (XP) just fit here. And hey, XP even talks about the scientific method!
Next time somebody asks what I do, I’ll say that I’m an eXtreme Researcher. Sounds way cooler than PhD student or research assistent, if you ask me.
Now, maybe being an academic doesn’t make me quite so special…
I don’t know. Why don’t you decide for yourself?
From now on, I’ll be writing about software development from an academic’s perspective in this blog. And if you got this far, maybe you join me on this journey? You know… feedback and all…
Maybe together we find out if anything special happens, when academics code.