Or in our case, the person in the teaching office!
Our "tenets for software that can be maintained by non-specialists" might have some things in common with Jef Raskin's "Design Considerations for an Anthropophilic Computer" (28-29 May 1979). Simple hardware is not that unlike simple software: dispensing with multiple modes, interfaces with other systems, no libraries you can't find or understand...
Friday, 30 April 2010
Tuesday, 27 April 2010
Closing summary
We reproduce here the executive summary from our final report:
Most universities have a central IT function. Despite this, or sometimes because of it, individual departments and academics are frequently motivated to develop ʻhome grownʼ IT systems, to fulfill unmet needs or to support particular departmental processes. These systems are often small and minimally complex, but highly fit for purpose, and likely to be of wider benefit.
This project took two such e-administration modules, originally developed (or part-developed) for internal use by the departments of Physics and Engineering at the University of Cambridge, and sought to extend their use to other departments, including those which would not have considered developing their own software internally.
The Engineering Department took the lead in developing and deploying a staff teaching duties allocation module generally known as the Teaching Office Database, or TODB. The Department of Physics took the lead in developing a module for recording and managing studentʼs course options, known as the Student Choices module. The Centre for Applied Research in Educational Technologies (CARET) provided project co-ordination and development staff.
Student Choices attempted to follow a standard software development and deployment process, in which the needs of a variety of possible users are met (or traded off) within a single piece of software. Users would be expected to maintain the project beyond the development phase using common OSS practices, contributing patches to a central version or ʻtrunkʼ.
TODB followed an innovative ʻtrunklessʼ model. Instead of complicating the software by making it meet many peoplesʼ needs at once, each user received a version customised for their specific needs. By this expedient the software is made simple and is easily related by users to their working practices, so that they are comfortable taking full ownership of it themselves. At the conclusion of this part of the project, TODB has been successfully customised and deployed to seven different departments.
Although the Student Choices module did not find users beyond the Physics department, its development has served as motivation and specification for the Universityʼs centrally-administered student information system, which has decided to offer similar functionality to the University as a whole. The inclusion of Student Choices in the e-Administration project also provided a valuable alternative perspective on sustaining ʻorganically grownʼ IT sytems.
Most universities have a central IT function. Despite this, or sometimes because of it, individual departments and academics are frequently motivated to develop ʻhome grownʼ IT systems, to fulfill unmet needs or to support particular departmental processes. These systems are often small and minimally complex, but highly fit for purpose, and likely to be of wider benefit.
This project took two such e-administration modules, originally developed (or part-developed) for internal use by the departments of Physics and Engineering at the University of Cambridge, and sought to extend their use to other departments, including those which would not have considered developing their own software internally.
The Engineering Department took the lead in developing and deploying a staff teaching duties allocation module generally known as the Teaching Office Database, or TODB. The Department of Physics took the lead in developing a module for recording and managing studentʼs course options, known as the Student Choices module. The Centre for Applied Research in Educational Technologies (CARET) provided project co-ordination and development staff.
Student Choices attempted to follow a standard software development and deployment process, in which the needs of a variety of possible users are met (or traded off) within a single piece of software. Users would be expected to maintain the project beyond the development phase using common OSS practices, contributing patches to a central version or ʻtrunkʼ.
TODB followed an innovative ʻtrunklessʼ model. Instead of complicating the software by making it meet many peoplesʼ needs at once, each user received a version customised for their specific needs. By this expedient the software is made simple and is easily related by users to their working practices, so that they are comfortable taking full ownership of it themselves. At the conclusion of this part of the project, TODB has been successfully customised and deployed to seven different departments.
Although the Student Choices module did not find users beyond the Physics department, its development has served as motivation and specification for the Universityʼs centrally-administered student information system, which has decided to offer similar functionality to the University as a whole. The inclusion of Student Choices in the e-Administration project also provided a valuable alternative perspective on sustaining ʻorganically grownʼ IT sytems.
Monday, 26 April 2010
Project Outputs
Continuing our wrapping-up theme, we've put together a list of links to code, demonstrations and documents we've produced during the project. The final report of the project has been posted on the JISC website, but we promised to include all the links right here as well so here they are:
Final Report
White papers
Project web pages
Google Code sites
TODB documentation
Sakai
Final Report
- Final Report of the e-Administration of Teaching Project
- Appendix A - Overview of differences between departmental TODBs
- Appendix B - e-Administration Requirements Specification
White papers
Project web pages
Google Code sites
TODB documentation
- TODB demo site
- TODB installation and configuration guide
- TODB developers' guide
- TODB user guide
- TODB modification journey (sequence of customisations)
- TODB 'How To' guide
Sakai
Friday, 23 April 2010
Comparison of software development approaches
Following on from our last post, about 'trunkless' software development, we want to share some thoughts about when it might be useful to consider that model. Many thanks to Matthew Jones, now of the South African Sugar Cane Research Institute, who developed much of this thinking.
Centralised systems in the Cambridge University context
The University of Cambridge is, to a greater degree than most, a loose collection of independent or largely-independent colleges and departments. Each department (and each college, if the TODB is extended this widely) prides itself on its independence, so there is potentially large diversity in the way that teaching is organised in different departments. This independence is fiercely guarded as part and parcel of academic freedom. These conditions create considerable scepticism about centralised 'one-size-fits-all' software. The University’s cultural memory records the deployment of recent centralised IT systems as being painful experiences. This strengthens the distrust of centrally-provided software. The organic, per-department approach followed with the TODB avoids running foul of this by customising the software for each department and allowing each instance to be locally managed. From departments’ point of view, this avoids the risk and overhead of engaging with central bodies who have many other priorities to balance and may deliver an unsatisfactory one-size fits all solution.
Quick and dependency-free operation
One of the advantages offered by small, independent and non-centralised software is that the usual dependencies that might apply bluntly in a large institution will not necessarily be enforced. For example, under most teaching circumstances, a member of staff will be appointed formally, will appear on a central staff database, and their information eventually trickles down to where it is needed. In a situation where a representative of industry gives a single lecture, they need not be formally appointed as a member of staff for the duration of that lecture. In the TODB, if the people list was 'formal' and enforced, it would be difficult to accommodate such people unless special provision was made in the system. By severing links with central systems, it is very easy to add that person as a member of staff – or even assign a job to them without them appearing in the people list. The work is accounted for. Centralised systems require far more prescription, consistency and formality in their operation in order to adequately handle their greater scope – and this is not necessarily how a Cambridge University department operates, or is willing to operate. The cost of course is the inability to synchronise information when this is desired – when a new member of staff joins, or someone retires.
Iterative participation
Rather than trying to develop a set of requirements from discussions about abstract concepts in the first phase of the project and then going ahead and developing the software, the constant to-and-fro between the developers and the project participants made for a very much richer interaction and engagement. It is felt that better software resulted – and not only this; as the stakeholders have been present in the software development process for up a to year already, those individuals probably feel that their contributions to the software have been substantial and worthwhile, and will feel a much greater desire to use the software.
The centralised, phased alternative is far less personal: each individual's contributions become diluted by time and the necessity to manage conflicting requirements for the software (where multiple stakeholders are consulted for the development of a single centralised piece of software). With the TODB approach, rather than an individual's desires having been 'taken into account', they are, in general, reflected in the implementation. That said, the phased/centralised model usually has one or more feedback iterations anyway; nevertheless, it is felt that this software development approach supported true engagement with the project's stakeholders. In fact, this could be considered an outstandingly successful aspect of the approach taken.
Use of an initial prototype
A number of participants expressed the view that an important success factor in this project was the availability from the start of a prototype system: the original, developed within Engineering. The prototype gave concrete form to what would otherwise have been a hard-to-visualise and far-off concept. It also meant that rather than being expected to develop ab initio for each department, customisation was limited to adapting the prototype, reducing to manageable proportions inter-departmental differences. It should be noted that the development and distribution of a ‘prototype’ originating in a particular department is a key part of this software development model. Developing a prototype remains a fairly substantial software development exercise, but where a prototype is available, this model is highly appropriate.
We have also seen, in the case of TIS, that software originated by individual academics or departments can be both motivation and specification for others, including central institutional IT departments, who wish to take on, extend, productionise and institutionalise the software.
Resource allocation considerations
It is worth noting that the trunkless model is not free - it simply offers an alternative division of resources. The cost is borne by the funder of initial customisation and roll-out - JISC in this case - and by departments, in slight but ongoing hosting and maintenance duties for their computer officers.
The TODB process consumed substantial resource in terms of project staff time. In future it should be considered whether beneficiary departments will realise sufficient value from the software to justify funding a developer for some time - two months in the case of TODB - to customise and support their adoption of it.
Without knowing the extent of stakeholder differences, it is difficult to predict how much software development work will be required for a 'trunkless' project. Unexpectedly high variability would require more customisation. Much of this risk is easily controlled by engaging potential adopter departments with a prototype before beginning the project, and setting expectations in terms of development priorities rather than an ‘all you can eat‘ menu.
Even though structural differences may be present at department level, at a broader level University departments are roughly similar: students are lectured and examined by representatives of the department and colleges. Given this large commonality, it would seem likely that software that assisted and addressed teaching issues at this level would be useful. Generally speaking, larger budgets are allocated to projects with larger numbers of clients – so where a centralised systems is viable, it might be expected to be a more polished, feature-rich product.
Software simplicity and functionality
The 'locally-maintained' or ‘trunkless’ aspect of this unconventional software development approach requires a careful approach to software complexity. Given the profile of the expected person in charge of further development of TODB in a department – an interested academic, a computer officer, possibly a summer student – the software really does need to be simple and straightforward, placing a higher value on this than even ‘best practice’ computer science conventions (highly structured abstractions, data models, etc).
This leads to two issues for consideration:
In the specific case of TODB, it was noticed that in order to ensure that the database is as simple and straightforward as possible, the SQL queries in the code are more complicated than they might otherwise be. This appears to be another tradeoff, where the complexity is defined more by the functional requirements than by how the solution is implemented.
Software support
The development of a software product usually also develops a software support problem. For an institution like CARET, apart from allocating the resources required to liaise with users and write the code, people need to be trained for support as well. Criticism of the software development methodology used with the TODB has been leveled at the difficulty in supporting software that, at the time of release, has eight slightly different versions, and may have been independently modified further without knowledge of changes being fed back to the support team. The simple answer is – there is no support burden! The whole point of the trunkless, decentralised model is that departments are self-supporting. This is a 'launch and forget' model. Were such a model used more widely, it would be wonderful for software developers, who traditionally enjoy developing new things and despise the 'housework' of ongoing support. The temptation to compromise the constant focus on local maintainability must be held in check, however.
In practice, it is possible that departments who make few changes to the software might require some support. CARET will provide support as required to Cambridge departments using versions of the software, as part of our institutional contribution to the project. Those departments which engage with the software to the point of making substantial changes to the code are likely not to need support – as their own competence at that stage will be quite sufficient to address any TODB-specific support challenges they encounter.
The Google Code site7 used to make the generic code widely available also supports community features including a mailing list, wiki, and bug tracking, creating an infrastructure for community-based support in the style of a ‘trunked’ OSS project. Although in future it might be expected that some users will develop their TODB instances away from being in a position to offer mutual support, it might also be expected that they would be replenished by new adopters. Support within Cambridge will be mediated by a group mailing list and a backed-up CARET SVN repository containing all versions of the software, plus Cambridge-specific documentation.
Departments have been warned that although CARET will provide support this will not include further code customisations and will not be of the intensive level available during the project.
Project scale
The approach of developing a rough prototype and then working individually with eight departments approximately in parallel was excellent for a product of the relatively small scale and complexity of TODB.
Each instance of the TODB is somewhat different. Maintaining eight independent branches means each time a change is made to one that might be useful to all, a rather laborious merging process is required to ensure that the new functionality is available in other departments but does not overwrite some other department-specific changes. This was manageable for the e-Admin TODB project development, but if the application had been much larger, or if there had been many more departments involved, it might not have been. On this basis the approach is very favourable for small projects and may be untenable for larger ones.
The situation might be retrieved using the approach, previously discussed, of separately modularising ‘core’ and ‘custom’ code - as long as this can be successfully reconciled with the need to eliminate avoidable abstraction. It is worth noting also that Biochemistry, the last department to join the project, benefitted from a relatively mature TODB and required very few customisations. This suggests that the support requirement may not scale linearly with the number of departments, as early lessons are incorporated and it becomes progressively harder to find new bugs or feature requests.
It will be interesting to monitor how future development by departments is merged, or not, with the generic version after the end of the project. CARET will monitor this as part of our evaluation of the processes discussed here, including beyond the end of the project.
Specification-variability considerations
Where proposed software is required to accommodate large variability between 'branches' (such as in this case, between departments), the TODB development model scales elegantly and well: where variability is small, the development approach more closely resembles a more conventional software development project; and where variability is large, this approach allows each instance to be quite different and for the differences to be pursued independently. This makes it a powerful model. Centrally hosted and supported software has its advantages, however, and the TODB development model could be changed to a conventional centralised model if it transpired that inter-stakeholder differences are very small. The only danger of such a decision might be that the architecture of the system might be inappropriate – as software designed to be maintained by 'non experts', and so free of abstractions, use of 3rd-party libraries and so on, might, perversely, be less efficiently maintained by 'professionals'.
Inter-instance compatibility
In general, it does not matter what each department does with its instance of TODB after release. The one caveat to this is with the benefits that would accrue to have TODBs communicate with each other. Being able to view the activities of a staff member in another department (in a shared lecturing environment) can be extremely valuable. There is a danger that this communication mechanism could break down through uncoordinated changes.
Centralised systems in the Cambridge University context
The University of Cambridge is, to a greater degree than most, a loose collection of independent or largely-independent colleges and departments. Each department (and each college, if the TODB is extended this widely) prides itself on its independence, so there is potentially large diversity in the way that teaching is organised in different departments. This independence is fiercely guarded as part and parcel of academic freedom. These conditions create considerable scepticism about centralised 'one-size-fits-all' software. The University’s cultural memory records the deployment of recent centralised IT systems as being painful experiences. This strengthens the distrust of centrally-provided software. The organic, per-department approach followed with the TODB avoids running foul of this by customising the software for each department and allowing each instance to be locally managed. From departments’ point of view, this avoids the risk and overhead of engaging with central bodies who have many other priorities to balance and may deliver an unsatisfactory one-size fits all solution.
Quick and dependency-free operation
One of the advantages offered by small, independent and non-centralised software is that the usual dependencies that might apply bluntly in a large institution will not necessarily be enforced. For example, under most teaching circumstances, a member of staff will be appointed formally, will appear on a central staff database, and their information eventually trickles down to where it is needed. In a situation where a representative of industry gives a single lecture, they need not be formally appointed as a member of staff for the duration of that lecture. In the TODB, if the people list was 'formal' and enforced, it would be difficult to accommodate such people unless special provision was made in the system. By severing links with central systems, it is very easy to add that person as a member of staff – or even assign a job to them without them appearing in the people list. The work is accounted for. Centralised systems require far more prescription, consistency and formality in their operation in order to adequately handle their greater scope – and this is not necessarily how a Cambridge University department operates, or is willing to operate. The cost of course is the inability to synchronise information when this is desired – when a new member of staff joins, or someone retires.
Iterative participation
Rather than trying to develop a set of requirements from discussions about abstract concepts in the first phase of the project and then going ahead and developing the software, the constant to-and-fro between the developers and the project participants made for a very much richer interaction and engagement. It is felt that better software resulted – and not only this; as the stakeholders have been present in the software development process for up a to year already, those individuals probably feel that their contributions to the software have been substantial and worthwhile, and will feel a much greater desire to use the software.
The centralised, phased alternative is far less personal: each individual's contributions become diluted by time and the necessity to manage conflicting requirements for the software (where multiple stakeholders are consulted for the development of a single centralised piece of software). With the TODB approach, rather than an individual's desires having been 'taken into account', they are, in general, reflected in the implementation. That said, the phased/centralised model usually has one or more feedback iterations anyway; nevertheless, it is felt that this software development approach supported true engagement with the project's stakeholders. In fact, this could be considered an outstandingly successful aspect of the approach taken.
Use of an initial prototype
A number of participants expressed the view that an important success factor in this project was the availability from the start of a prototype system: the original, developed within Engineering. The prototype gave concrete form to what would otherwise have been a hard-to-visualise and far-off concept. It also meant that rather than being expected to develop ab initio for each department, customisation was limited to adapting the prototype, reducing to manageable proportions inter-departmental differences. It should be noted that the development and distribution of a ‘prototype’ originating in a particular department is a key part of this software development model. Developing a prototype remains a fairly substantial software development exercise, but where a prototype is available, this model is highly appropriate.
We have also seen, in the case of TIS, that software originated by individual academics or departments can be both motivation and specification for others, including central institutional IT departments, who wish to take on, extend, productionise and institutionalise the software.
Resource allocation considerations
It is worth noting that the trunkless model is not free - it simply offers an alternative division of resources. The cost is borne by the funder of initial customisation and roll-out - JISC in this case - and by departments, in slight but ongoing hosting and maintenance duties for their computer officers.
The TODB process consumed substantial resource in terms of project staff time. In future it should be considered whether beneficiary departments will realise sufficient value from the software to justify funding a developer for some time - two months in the case of TODB - to customise and support their adoption of it.
Without knowing the extent of stakeholder differences, it is difficult to predict how much software development work will be required for a 'trunkless' project. Unexpectedly high variability would require more customisation. Much of this risk is easily controlled by engaging potential adopter departments with a prototype before beginning the project, and setting expectations in terms of development priorities rather than an ‘all you can eat‘ menu.
Even though structural differences may be present at department level, at a broader level University departments are roughly similar: students are lectured and examined by representatives of the department and colleges. Given this large commonality, it would seem likely that software that assisted and addressed teaching issues at this level would be useful. Generally speaking, larger budgets are allocated to projects with larger numbers of clients – so where a centralised systems is viable, it might be expected to be a more polished, feature-rich product.
Software simplicity and functionality
The 'locally-maintained' or ‘trunkless’ aspect of this unconventional software development approach requires a careful approach to software complexity. Given the profile of the expected person in charge of further development of TODB in a department – an interested academic, a computer officer, possibly a summer student – the software really does need to be simple and straightforward, placing a higher value on this than even ‘best practice’ computer science conventions (highly structured abstractions, data models, etc).
This leads to two issues for consideration:
- What is simple software? What are the conventions to be avoided? Essentially, how is the line drawn between acceptably-simple and unacceptably-complex coding approaches? In this project, the TODB had been initially developed by a non-expert, and was extended in a similar style. Although PHP and MySQL had already been chosen as the underlying technology for the TODB, these can be considered relatively easy technologies in which to acquire basic competence.
- To some extent, a tradeoff exists between complexity and functionality. This certainly does not hold in all cases, but there are definite situations where the code required to achieve a certain level of functionality will be more complex than might ideally be found in a 'simple, straightforward' system designed to be maintained and extended by non-experts. In practice, in such situations, either the complex functionality was not included in the software, or small sections of code within the TODB have complexity that exceeds the ideal target. Overall, however, it is felt that the software abides by the 'simple, straightforward' principle.
In the specific case of TODB, it was noticed that in order to ensure that the database is as simple and straightforward as possible, the SQL queries in the code are more complicated than they might otherwise be. This appears to be another tradeoff, where the complexity is defined more by the functional requirements than by how the solution is implemented.
Software support
The development of a software product usually also develops a software support problem. For an institution like CARET, apart from allocating the resources required to liaise with users and write the code, people need to be trained for support as well. Criticism of the software development methodology used with the TODB has been leveled at the difficulty in supporting software that, at the time of release, has eight slightly different versions, and may have been independently modified further without knowledge of changes being fed back to the support team. The simple answer is – there is no support burden! The whole point of the trunkless, decentralised model is that departments are self-supporting. This is a 'launch and forget' model. Were such a model used more widely, it would be wonderful for software developers, who traditionally enjoy developing new things and despise the 'housework' of ongoing support. The temptation to compromise the constant focus on local maintainability must be held in check, however.
In practice, it is possible that departments who make few changes to the software might require some support. CARET will provide support as required to Cambridge departments using versions of the software, as part of our institutional contribution to the project. Those departments which engage with the software to the point of making substantial changes to the code are likely not to need support – as their own competence at that stage will be quite sufficient to address any TODB-specific support challenges they encounter.
The Google Code site7 used to make the generic code widely available also supports community features including a mailing list, wiki, and bug tracking, creating an infrastructure for community-based support in the style of a ‘trunked’ OSS project. Although in future it might be expected that some users will develop their TODB instances away from being in a position to offer mutual support, it might also be expected that they would be replenished by new adopters. Support within Cambridge will be mediated by a group mailing list and a backed-up CARET SVN repository containing all versions of the software, plus Cambridge-specific documentation.
Departments have been warned that although CARET will provide support this will not include further code customisations and will not be of the intensive level available during the project.
Project scale
The approach of developing a rough prototype and then working individually with eight departments approximately in parallel was excellent for a product of the relatively small scale and complexity of TODB.
Each instance of the TODB is somewhat different. Maintaining eight independent branches means each time a change is made to one that might be useful to all, a rather laborious merging process is required to ensure that the new functionality is available in other departments but does not overwrite some other department-specific changes. This was manageable for the e-Admin TODB project development, but if the application had been much larger, or if there had been many more departments involved, it might not have been. On this basis the approach is very favourable for small projects and may be untenable for larger ones.
The situation might be retrieved using the approach, previously discussed, of separately modularising ‘core’ and ‘custom’ code - as long as this can be successfully reconciled with the need to eliminate avoidable abstraction. It is worth noting also that Biochemistry, the last department to join the project, benefitted from a relatively mature TODB and required very few customisations. This suggests that the support requirement may not scale linearly with the number of departments, as early lessons are incorporated and it becomes progressively harder to find new bugs or feature requests.
It will be interesting to monitor how future development by departments is merged, or not, with the generic version after the end of the project. CARET will monitor this as part of our evaluation of the processes discussed here, including beyond the end of the project.
Specification-variability considerations
Where proposed software is required to accommodate large variability between 'branches' (such as in this case, between departments), the TODB development model scales elegantly and well: where variability is small, the development approach more closely resembles a more conventional software development project; and where variability is large, this approach allows each instance to be quite different and for the differences to be pursued independently. This makes it a powerful model. Centrally hosted and supported software has its advantages, however, and the TODB development model could be changed to a conventional centralised model if it transpired that inter-stakeholder differences are very small. The only danger of such a decision might be that the architecture of the system might be inappropriate – as software designed to be maintained by 'non experts', and so free of abstractions, use of 3rd-party libraries and so on, might, perversely, be less efficiently maintained by 'professionals'.
Inter-instance compatibility
In general, it does not matter what each department does with its instance of TODB after release. The one caveat to this is with the benefits that would accrue to have TODBs communicate with each other. Being able to view the activities of a staff member in another department (in a shared lecturing environment) can be extremely valuable. There is a danger that this communication mechanism could break down through uncoordinated changes.
'Trunkless' development
Following on from our last post, about developing simple software, we'd like to describe how we used this in practice, taking the Engineering Department's TODB software, making custom versions for six other departments, and making them feel able to take responsibility for maintaining and supporting it into the future.
We plan to publish this also as part of a companion whitepaper to the e-Admin project final report.
Overview
A method of spreading user-originated software in HEIs, which allows each user a ‘made to measure’ customised version of the software, for which they are subsequently able to take complete responsibility.
Model summary
Because our partner departments are only now, at the end of the project, falling back on their own capabilities for maintenance and support, and because none save Engineering have as yet used the software over a complete academic year, we can not say that evaluation is finished. It needs a long view over coming years, which CARET will be providing.
We plan to publish this also as part of a companion whitepaper to the e-Admin project final report.
Overview
A method of spreading user-originated software in HEIs, which allows each user a ‘made to measure’ customised version of the software, for which they are subsequently able to take complete responsibility.
Model summary
- Prototype developed by originating user
- Other users interested
- Central, one-off funding obtained for development
- Software is genericised, with a view to making expected range of stakeholder-specific customisations manageable
- Software deployed and customised user by user. Users and developers agree priorities for development.
- Lessons are incorporated back in to generic version and pushed to previously-addressed departments
- Detailed, tested documentation and handover to users
- A working prototype exists
- At least some partner institutions have expressed an interest in evaluation with a view to adoption
- Institutional IT systems are unlikely or unable to assume similar functions in the project timeframe
- Small to medium-sized applications in which the use of frameworks, large or numerous libraries, or substantial amounts of abstraction is unnecessary. It is worth noting that lots of ‘big’ projects are actually small, once all the abstraction and configuration capability needed to handle different user requirements is stripped out.
- Projects with a user base of approximately 3-20 users, each with distinct needs. If the numbers are larger or the requirements uniform then a traditional open-source approach is likely more efficient.
- The risk of having to apply similar and significant changes to all systems subsequent to deployment is small.
- It is not critical that all systems interoperate consistently. If it is, then centralised systems are likely to be more effective, as the overhead of 'softly' maintaining interfaces will offset the advantages of locally-maintained, locally-modified software.
- Administrative tools are in general likely candidates.
- Software which, being created by academics, addresses their particular needs very well, can be genericised and then customised repeatedly for other users. Traditional, centrally budgeted and supported systems would not be able to provide such customisation at a reasonable cost owing to ongoing support requirements, and in any case are unlikely to invest a great deal of effort on behalf of relatively limited numbers of users, unless there are substantial financial or educational benefits.
- Originators are by definition able to resource a modest level of formal or informal development, and are likely to be able to do so again, if necessary. However, without the benefit of JISC or other capital funding it is not possible to re-engineer and distribute systems in this way.
- Less well-resourced adopters will be able to maintain the software, but not to extend or make significant modifications.
- The model is good as long as it is not subsequently necessary to apply similar but significant changes to all the deployed, customised systems, in which case support cost has been multiplied.
- The model accommodates large variations between sets of users, and becomes leaner, more efficient, and more like a conventional ‘one size fits all’ development approach as this variability decreases. It might become apparent that actually a one size fits all approach would have been appropriate, in which case architectural inefficiency might result from having followed the TODB approach initially.
- This kind of project might benefit from having fewer staff, for a longer period; or from being able to draw on a developer ‘pool’. This would overcome difficulties in hiring great staff for a short term. Longer, lower intensity projects also allow more time to talk and work with other institutions, once the local systems and processes were established.
Because our partner departments are only now, at the end of the project, falling back on their own capabilities for maintenance and support, and because none save Engineering have as yet used the software over a complete academic year, we can not say that evaluation is finished. It needs a long view over coming years, which CARET will be providing.
Developing Simple Software
These are the principles we used to guide our development of software which would be deployed and maintained locally in university departments by non-professional programmers, such as computer officers, competent academics, even summer students. We are planning to also publish them as a white paper companion piece to the e-Admin project's final report.
Appropriate to the task
Software involving workflow through numerous or systems or users, especially complex ones or those outside the maintainer’s sphere of influence, is inherently unlikely to be ‘simple’. Similarly for software which must be used by many different users, or which involves high-stakes or confidential operations.
No external libraries
Libraries are ‘black boxes’ for those unfamiliar with them and make it more difficult to build a mental model of the software. Application frameworks are bad for the same reason - they might be great for professional programmers, but they introduce a huge amount of noise for novices. External libraries get updated, maintained and retired, adding work for the diligent application maintainer, especially if they are popular targets for security hacks.
This rule is flexible, within reason - sometimes a library or API might be the only reasonable way of achieving something, Shibboleth login for instance, but the impact on the maintainer but always weigh heavy in the balance.
No abstractions
Abstractions are usually introduced to promote code re-use and support configuration for different users. Even if well explained and documented, they make it harder for someone unfamiliar with a program to understand how it works. Lots of ‘big’ projects are actually small, once all the abstraction and configuration capability needed to handle different user requirements is stripped out.
Novice-friendly
Professional software developers will want to apply their ideas about best practice, appropriate tools, and software architecture. All this draws on considerable background knowledge and context, without which none of these things makes much sense. Put best practices to one side and consider the novice user. How would someone whose background consists of “PHP in 24 hours” approach the problem?
The code is the configuration
Don’t try too hard to bring all possible configuration parameters into one place. Parameters such as text labels clearly benefit from extraction, but creating configuration abilities beyond that basic level requires increasing abstraction and alternative execution paths in the code, placing a larger barrier in the path of subsequent maintainers and developers, and risking the counterproductive situation where understanding the configuration language is as difficult as understanding source code.
Users know what they’re doing
I.E., users have a reasonable mental model of the process and data structures. The tool should support that mental model, and not attempt to second-guess or restrict their actions.
For example instead of enforcing strict referential integrity, TODB provides operations that assist the user in locating anomalies, e.g. a query that lists all jobs allocated to people who are not found in the database6. In a typical database scenario it would not be possible to allocate a job to a non-existent person, but this is possible on paper, and in the mind of the teaching administrator, so that to impose such a restriction in the software would only interfere with their working and thinking process.
Appropriate to the task
Software involving workflow through numerous or systems or users, especially complex ones or those outside the maintainer’s sphere of influence, is inherently unlikely to be ‘simple’. Similarly for software which must be used by many different users, or which involves high-stakes or confidential operations.
No external libraries
Libraries are ‘black boxes’ for those unfamiliar with them and make it more difficult to build a mental model of the software. Application frameworks are bad for the same reason - they might be great for professional programmers, but they introduce a huge amount of noise for novices. External libraries get updated, maintained and retired, adding work for the diligent application maintainer, especially if they are popular targets for security hacks.
This rule is flexible, within reason - sometimes a library or API might be the only reasonable way of achieving something, Shibboleth login for instance, but the impact on the maintainer but always weigh heavy in the balance.
No abstractions
Abstractions are usually introduced to promote code re-use and support configuration for different users. Even if well explained and documented, they make it harder for someone unfamiliar with a program to understand how it works. Lots of ‘big’ projects are actually small, once all the abstraction and configuration capability needed to handle different user requirements is stripped out.
Novice-friendly
Professional software developers will want to apply their ideas about best practice, appropriate tools, and software architecture. All this draws on considerable background knowledge and context, without which none of these things makes much sense. Put best practices to one side and consider the novice user. How would someone whose background consists of “PHP in 24 hours” approach the problem?
The code is the configuration
Don’t try too hard to bring all possible configuration parameters into one place. Parameters such as text labels clearly benefit from extraction, but creating configuration abilities beyond that basic level requires increasing abstraction and alternative execution paths in the code, placing a larger barrier in the path of subsequent maintainers and developers, and risking the counterproductive situation where understanding the configuration language is as difficult as understanding source code.
Users know what they’re doing
I.E., users have a reasonable mental model of the process and data structures. The tool should support that mental model, and not attempt to second-guess or restrict their actions.
For example instead of enforcing strict referential integrity, TODB provides operations that assist the user in locating anomalies, e.g. a query that lists all jobs allocated to people who are not found in the database6. In a typical database scenario it would not be possible to allocate a job to a non-existent person, but this is possible on paper, and in the mind of the teaching administrator, so that to impose such a restriction in the software would only interfere with their working and thinking process.
tasty outcomes
Yesterday, the project team met to complete our programme evaluation. In our discussions, we summarised the outcomes of the project:
Photo by PetitPlat by sk_ - http://flic.kr/p/52bGDC
- two examples of a prototype user-generated software system providing a requirements definition or specification for use in further work
- provided a model of how simple software development principles can provide a system which non-specialists can deploy and maintain
- an example of a sustainable development model, where non-technical end users can maintain and modify their own software
- an example of how experimental software development, merely by happening, can catalyse institutional change in policy and process; the software development may not be part of the eventual solution, but if the original need is met by other processes/systems, it is a good outcome
- we learnt that arts, social science and humanities departments often have strong technical skills!
Photo by PetitPlat by sk_ - http://flic.kr/p/52bGDC
Thursday, 22 April 2010
wrapping up
The project team is currently wrapping up the final loose ends for "MEAoT". I think one thing we've learned is that acronyms can be very ugly, and it might sometimes be better to stick with a nice meaningful name!
We've had some people join us towards the end of the project, with Guy Chisholm working hard on the latest iteration of the Student Choices software, and Amyas Phillips coming in to help evaluate our work, and to check that our "client" departments had all had good experiences.
We'll be sharing our final report, and associated other reports, here shortly.
We've had some people join us towards the end of the project, with Guy Chisholm working hard on the latest iteration of the Student Choices software, and Amyas Phillips coming in to help evaluate our work, and to check that our "client" departments had all had good experiences.
We'll be sharing our final report, and associated other reports, here shortly.
Subscribe to:
Posts (Atom)
Posts
