HomeNews and blogs hub

We're all engineers now

Bookmark this page Bookmarked

We're all engineers now

Author(s)

Rob Baxter

Posted on 29 June 2011

Estimated read time: 4 min
Sections in this article
Share on blog/article:
Twitter LinkedIn

We're all engineers now

Posted by s.hettrick on 29 June 2011 - 12:01pm

MeccanoTrain.jpgWell, OK, of course we're not. Most of us are researchers who want to get on and make new discoveries in our chosen fields. Increasingly we find ourselves having to create and use software to make progress, but that doesn't make us all software engineers. What we're doing is research - computational research, if you will - but not software engineering.

Hmm. Hold on a minute.

Research works best without constraints on thought; it needs the freedom to chop, change, freewheel and go off at tangents; it is, by definition, a voyage into the unknown.
 

In contrast, research software can't, doesn't and isn't.

Whatever the purpose of your software, its creation isn't a matter of research, it really is software engineering. A different shade, perhaps, but it's the same colour. We need to adopt the same approaches to research software as we do to any other kind. But fear not! A little can go a long way. Here are five key things that every computational researcher should understand about creating software.

  1. Requirements, requirements, requirements. Software tools are meant to do something, behave in a certain way - they have a goal. Writing these things down, however informally, is an important first step on the path to creating something sustainable. Spending time up-front thinking about, documenting and prioritising what your software should do will save pain later on. It needs to do this now (a requirement!), but what if we want to extend it later? (ah, there's another requirement!). Which should we do first? A simple, prioritised list of requirements can be a very effective planning tool.
     
  2. No release schedule = no releases. Without a fixed point in time, software can easily drift. It can always be better, can always be extended, will always be 95% complete... While research shouldn't be timeboxed, development should be. Set release milestones to focus development, but don't over-prescribe what will be released. This is where your prioritised requirements list comes in: Release 1 will address the first three requirements, more if we have time, but it will go to users on the fourteenth!
     
  3. Throwaway prototypes never are. Once I've proved this I'll junk the code. Really! No, you really won't! Your code will live on in all its gory glory, forever, being built upon and extended in ways you never even imagined until it becomes the foundation of several research careers! Assume that even the most trivial-looking programs have a future and apply some basic engineering processes from the start. It may take a little more time now, but it will save a lot more later. Code for sustainability from the get-go.
     
  4. Agility is all. Computational research problems are very often attempts to get to grips with complex systems, and complex systems imply very complex software projects - with all their attendant risk of failure. Be agile: adopt an incremental approach to requirements, design and implementation. Take small bites. Expect change. Deliver working code early and often. Don't try and build the entire system at once. This kind of agile approach helps to minimise the risks, and is also good for code quality, progress visibility and developer morale!
     
  5. Keep your eyes on the road. Having mentioned risks, keep an eye on them. Ask yourself, on a regular basis, what happens if this goes wrong? Spend some time thinking about the worst and you'll be much better prepared when things do go wrong. And they will, because that's life!

While as a computational researcher you really want to, well, research, we contend that just a little bit of software engineering discipline will go a long way. Adopting simple, lightweight processes based around the five points above will pay off, and often sooner than you might expect.  

Share on blog/article:
Twitter LinkedIn