Software development in industry vs academia
Thu, Feb 4, 2016
There’s a fair amount of speculation in both camps about what you can expect from each environment and as I spent my formative years as a software developer in industry, I thought I’d compare my experiences of both.
The main difference is the motive. In industry it’s profit. If something doesn’t directly contribute to profit it doesn’t get done. If something doesn’t support something that brings in profit, it doesn’t get done. There is of course research but it’s profit focused. New product lines, new features but all with the aim of keeping the company in the market and hopefully boosting its position.
In academia there are customers too. They are students who have selected your institution to change their lives. To educate themselves, broaden their skills base and open new opportunities for themselves.
Whereas in industry you’re working on a product that fulfills a purpose for a customer, if that product isn’t up to scratch the customer is free to go elsewhere with their cash. It will be inconvenient for them but unlikely to be a disaster. Too many like that and the company is in danger of folding and so the consequences work their way downstream, towards the company. Ultimately the provider fragments into a lot of unemployed developers while the customers find solutions with better focused providers.
The situation in academia is rather different. Students choose your institution as their education provider but once they’re signed up, the effects of finding out how quality focused, or not, the institution is, can have far reaching consequences for the student, the customer. It’s not as easy to up sticks and find a solution elsewhere as the product, a degree for example, isn’t as freely available as market driven product solutions. Or not at the moment. The situation is changing rapidly so watch this space. As a disgruntled student you’d have to consider things like location (where can I get a better experience without having to vastly increase my accommodation/living expenditure?), credit transfer (I’ve done a year of this degree but it’s no use, who will take that into account if I go elsewhere?), availability (who will take me?).
In industry the answer to the last question is ‘everyone’. Or everyone who provides that product and knows you have the cash to pay for it. They don’t care how you did it in the past. They want you to do it now, with them and stay with them for the future.
So bearing that in mind, software developers in academia have a different focus in that they have an onus to provide solutions that support teaching staff who in turn provide good educational experiences for their students. The consequences of failing do that works its way upstream, towards the customer.
The net result of failure in both camps is the same. No customers. How that situation is avoided is handled differently.
In academia there is more broader research. Research into supporting new teaching methods for example. How best to integrate leading products into existing workflows. If a product doesn’t exist, should we develop it? And once we’ve done that, should we shout about it? Go to conferences, disseminate our work, build our profile, all to the good of the institution. ‘Come and study here’ is the overarching message. ‘Let me, as a software developer, work on more really interesting projects’ is the underlying message.
When I worked in industry, I was focused on one product line. A particular brand of printer which required a particular type of driver and a particular type of installer. Now this makes for an interesting comparison. In academia, if you can make a case for a particular technology and show a proof of concept and a cogent argument for how it can improve user experience (remember those students?) there’s a good chance you will be allowed to use that technology. Especially if it aligns with external funding priorities. In industry, new technology can be a risk. There’s a learning curve, testing, validation etc, none of which contribute to making money and it was here that I experienced some frustration as orders from head office were to use a certain brand of installer. Which was very little use in installing printer drivers. But you’re a small cog in a collection of many big wheels in industry and those who decide where to go had decided that the corporate image would be better served by the use of what was seen as industry standard software. It was then my job to work out how to make it work.
While the orders come top down in industry, the freedom in academia to make choices comes at a very high risk for the developer pushing that choice. And a high risk for the customer, the student.
Also, due to the nature of education, developers in academia tend to work on many and varied projects, often three to six months in duration. Often externally funded with tight reporting schedules. Often in disparate domains. Looking back over my years in academia it seems more like contract work. 3/6/12 month projects with different goals, different technologies, different clients. New domains to learn, new risks to avoid, new skills to learn.
My time in industry was spent on a narrower development path but was much more fully supported. Merit is rewarded in industry. If the company recognises your worth, your talent, you can go far. There are career progressions not available to developers in academia. Whereas academic developers largely have to take care of their own professional development, in industry you can be fully supported with market leading training.
Balancing that in academia is the freedom to try new things, as long as you can justify them. The increased holidays of course and the chance to ‘build your profile’ through presenting at conferences. I’ve presented throughout Europe and the ‘States as a developer in academia, in support of the project work done at the time but also to raise the profile of my institution. In industry I was sent to the ‘States for 3 weeks of training and always had four star accommodation in London on courses. I also had a company credit card for when I wanted to go to the cinema, or eat in a nice restaurant when I was away. It’s swings and roundabouts.
Go high and narrow in industry or low and wide in academia.
There are similarities in working practices however. We’re all developers ‘under the hood’ after all. We all use stuff like TDD, Agile iterative releases etc. We manage our code in version control. We perform release management. It’s just the end goal that is different. How we get there is the same.
Having said that, if a hack is more appropriate to get a profit making product out the door, then a hack it is and deal with the technical debt later. But it’s the same everywhere. We’ve all had that ‘make it work now’ phone call. So we’re all realists too. We love what we do and we do our best to produce work to a high standard but we all realise too the realities of developing software to tight schedules. Yes there most definitely are schedules in academia! Student enrollments for example, to name but one.
Add in a healthy dose of politics (especially for an integrator like me), turf wars, project sniping and ‘please sir his is crap, can I use my solution instead?’ and developing software in industry vs academia is remarkably similar.
If you just remember why you’re developing that software, what the ultimate motive is, you should be fine.