|
Open Systems Interconnection (OSI) model
, where we have the
physical layer (hardware, wires, modulation types, encoding), the data layer (data framing, error correction coding), the
network layer (packet addressing and routing) and several other layers abstracting different environments for code.
Right at the top of this stack we again have the application layer, allowing the user to be entirely blind to the nitty gritty
of voltage levels of bit transmission at the physical layer.
The Academic Problem
So, it seems that software architecture is a useful technique, building on both abstraction layers in other engineering
domains and the history of computers and software itself. So why are such concepts dif cult to implement within
academia? Why do we still see code of 1000+ lines within a single le? Why do we still see high interdependence and
version control issues within code developed within academia?
There are three issues within academia that separate it, from a code development perspective, from industry. The rst
is that as academia quite rightly focuses on the results, rather than the path, or the longevity of that path, there is a
certain attitude of “just get it working” within academia. This is principally historical, where the methods may be
discussed in a paper, but the headlines are always the results and a few paragraphs within the method section may be
swamped by the mathematical algorithms, signal processing and experimental method rather than the speci cs of a
project’s software code.
The second issue is one of project and indeed code longevity. In industry, new products may rest on development and
sub-units of previous products. While in academia, projects may generally follow on from each other, they often stand
upon the results and concepts from a previous project rather than implementation of code. When this is coupled with
typical four- or ve-year research grants, often three- to four-year PhD projects, and often short one- to two-year
postdoc contracts, it becomes dif cult to ensure project and personal work effort longevity.
The third issue is one of team size. In industry, the larger the work package and the more invested in a leading product,
typically the larger the development team. As the lifetime of a product can be decades, team sizes can range from 10s
to 100s of developers. While ideally at the grant writing stage academia has a similar mechanism, the nature of
research often means work packages grow during the lifetime of a project, while staf ng budgets are pre-allocated
costs with little ability to transfer money from equipment into staff etc. The result is that a project may budget for one
full-time postdoc and one PhD student, but the work package may quickly grow too large for a small team size.
Likewise, the student’s project needs to be of limited scope amenable for a coherent write-up, shunting any growth of a
work package onto the shoulders of the postdoc. Software development can therefore quickly become a solitary
exercise.
Within academia, the pressure to get results often restricts both PhD students and research staff to being self-taught
with respect to software development or engineering best practices. It does help if a staff member’s background used
the same programming language, concepts or if they have industrial experience. However, this may not be the case, as
highlighted by the variety of disciplines within the Software Sustainability Institute’s Fellowship Programme.
To add re to thish situation, academia in entire contrast to industry has a continuous professional development (CPD)
issue. In industry, if a new skill is required to complete a work package, a staff member may easily go to a suitable
training course. But in academia, there is an unwritten rule that informal training and osmosis from research papers is
adequate. Further—while university’s have in-house training, and may indeed pay for small, cheap CPD courses—if
there is no dedicated funding written into a grant proposal, then postdocs and PhD students struggle to obtain cutting-
edge advanced training. As an example, Oxford university offers a digital signal processing (DSP) course, at £2,500 with
a likely total cost of £3,000. It is beyond the scope of an individual’s nances and is beyond the scope of small bits and
pieces within a research grant. Likewise, funding may not be available from an institution. External funding may be
available, however why should professional development, and the ability to perform world-class novel research
become a numbers game with highly competitive funding routes?
To summarise then, the major issues are the academic "just get it working" attitude, project and code longevity, small or
indeed unary team sizes and the issues regarding continued professional development, training and self-tuition.
Solutions and Conclusions
Luckily, there are some solutions to these issues, although most are highly sensitive to the will, opinion and funding of a
research group’s principal investigator. They are also highly sensitive to institution infrastructure and a critical mass of
like-minded individuals, although they are also highly in uenced by the will of software development staff.
As many research groups have some form of legacy project active when a new member starts, one solution would be a
research group technical introduction. Here a new PhD student could be shown the location of a group’s sub-version
repository, could become accustomed to various tools used within the group and would obtain stylistic elements
through osmosis. Shared code would add to this introductory ethic, although more formal training may be worthwhile,
particularly within the rst year of a new role. Companies sometimes utilise style guides for new staff members,
coupled with of course formal and informal CPD. This idea of training prior to development is particularly prevalent in
the American PhD model.
A primary solution, closely linked to the ideas of abstraction and architecture, would be to instil a group or institute-
wide work ethic of drawing an architecture prior to the start of development. Taking a top-down approach to the issue,
supervisors would need to implement periodic design reviews, similar to industry. Here, the separate modules could be
discussed prior to code development, libraries and code shared by other staff could also be incorporated allowing a
minimisation of “reinventing the wheel” and a maximisation of research output. Certainly, such a shared code, shared
library and perhaps shared modular design work-ethic promoted by a group’s leader would instil a robust team effort
attitude, thereby breaking the issues with solitary code development.
Groups such as the Software Sustainability Institute and training providers such as
Do'stlaringiz bilan baham: |
