Around the start of the COVID-19 pandemic, I wrote about developing software in remote teams. Over the past few years, I've also had a few conversations about developing software part-time—usually to the effect of we don't do it.
Nonetheless, much software does get developed by part-timers, be they professional developers working on personal projects in their spare time, freelance developers working across several projects at a time, or students developing software for one subject while studying others.
In a review of part-time work (not considering software developers in particular), Natalie Smith and Paula Macdonald (2015) say that part-time work has demonstrated benefits including higher workforce participation, increased household income, reduced conflict between work and other aspects of life, and increased employee retention. On the other hand, part-time workers suffer from higher gaps in pay, lower career progression and training, lower status, and intensification of work.
Out of reach, out of touch?
Thora Thorgeirsdottir's PhD thesis (2017) gives an extended account of software development with part-time and non-co-located team members. She says that earlier studies of flexible work report flexible workers "find it difficult to maintain their identity and legitimacy within the organisation" but that workers attempted to combat this by being present in the office more often and/or using electronic communication. Studies of the co-workers left in the office, however, report "adverse reactions and frustration" due to the difficulty of collaborating with absent colleagues.
Thorgeirsdottir interviewed consultants who'd assisted in implementing flexible work plans across several countries, who argued that the negative impacts on co-workers could be managed by thoughtful planning of in-person events and by developing trust and fairness within the team. Thorgeirsdottir explored these ideas through case studies of seven software development teams in Belgium and the Netherlands.
Thorgeirsdottir says that the main challenge to flexible work is reduced "passive facetime", that is, time during which team members are available but not participating in formal meetings. She identified a number of factors affecting the success or otherwise of flexible working arrangements and suggests several strategies for success full flexible work:
- use flexible work sparingly (she suggests 1-2 days per week);
- cross-training team members in each other's tasks can help ensure that someone is available for a task at any given moment;
- support critical points in projects by formal face-to-face collaboration;
- synchronise the availability of team members;
- make flexible workers' availability well-known amongst the team; and
- continue communication even when workers are not sharing physical space.
Lessons from distributed and open source development
While Thorgeirsdottir's thesis is one of the few studies to explicitly consider part-time software developers, a great deal of literature describes distributed (or "global") software development and open source software development. These share characteristics of part-time development in that members of the development team may not work at the same time or in the same place.
Luigi Lavazza and colleagues (2010) observe that open-source software development shares many principles with agile software development, such as acceptance of change, iterative development, and regular involvement of users. Daily Scrum meetings, however, are clearly impractical for non-co-located development teams, so Lavazza and colleagues replaced them with an on-line tool through which developers could report the state of their tasks and any obstacles they faced. Lavazza and colleagues say this tool achieved comparable or better results across several measures when compared to the ad hoc method of open-source development previously used on their project.
Philipp Diebold and colleagues (2013) used a similar method, called Moonlighting Scrum, in which part-time and non-co-located developers submitted their progress and obstacles to an on-line forum every six working hours. They stress finding parameters for reporting periods, sprint lengths, and so on, that minimise the time spent communicating and maximise the time spent developing. They say this method worked well for a small software project undertaken with part-time developers at their research institution, but admit that further experimentation is required to validate and improve the method.
Lessons from crowdsourcing
Sites such as TopCoder and Bountify promise to get software development done by farming out tasks to freelance developers. For organisations looking to farm out tasks, challenges exist in selecting tasks suitable for outsourcing and identifying a freelancer with the suitable skills; for freelancers, complementary challenges exist themselves in identifying tasks they have the skills to complete and identifying organisations they can work with (Gupta et al 2020). Crowdsourcing platforms exist to address these challenges.
Researchers studying crowdsourcing stress the importance of dividing software development into "micro-tasks", being well-defined tasks that can be completed by a lone developer in a reasonable amount of time and with minimal knowledge of the broader context in which the software will work (LaToza et al. 2018; Zanatta et al. 2020). Not all software development can be broken down this way—but of course we all learned about the importance of modularity and loose coupling in software design class (didn't we?).
Doing without the team
Finally, I've worked on several projects on which I was the only developer, such that the question of daily scrums, team meetings, and so on, didn't arise. I wrote about software development in small teams (including teams of one) in a previous article.
Of course even lone developers still have clients with whom they should communicate, but they can do so with less frequency than they might do when working in a full-time development team. In this sense, part-time development is simply a slower-moving version of full-time development.
Conclusion
Developing software part-time certainly has its challenges. If nothing else working part-time will presumably result in development taking longer than it would working full-time. Nonetheless, strategies exist for getting development done when not everyone is available all of the time.
References
Philipp Diebold, Constanza Lampasona and Davide Taibi (2013). Moonlighting Scrum: An Agile Method for Distributed Teams with Part-Time Developers Working during Non-Overlapping Hours. Eighth International Conference on Software Engineering and Advances, 2013, pp. 318-323.
Varun Gupta, Jose Maria Fernandez-Crehuet and Thomas Hanne (2020). Freelancers in the Software Development Process: A Systematic Mapping Study. Processes 8(10), 2020.
Thomas D. LaToza, Arturo Di Lecce, Fabio Ricci, W. Ben Towne and Andre van der Hoek (2018). Microtask Programming. IEEE Transactions on Software Engineering 45(11), November 2010, pp. 1106-1124.
Luigi Lavazza, Sandro Morasca, Davide Taibi and Davide Tosi (2010). Applying SCRUM in an OSS Development Process: An Empirical Evaluation. International Conference on Agile Software Development, 2010, pp. 147-159.
Natalie Smith and Paula Macdonald (2015). Facilitating Sustainable Professional Part-Time Work: A Question of Design? Journal of Management & Organization 1(2), August 2015, pp. 1-19.
Thora Thorgeirsdottir (2017). Out of Reach Out of Touch? The Impact of Flexible Work Arrangement Use on Collaboration Within Teams. PhD thesis, Cranfield School of Management, Cranfield University, 2017.
Alexandre Zanatta, Leticia Machado, Igor Steinmacher, Rafael Prikladnicki and Cleidson R. B. de Souza (2020). Strategies for Crowdworkers to Overcome Barriers in Competition-based Software Crowdsourcing Development. Proceedings of the IEEE/ACM 42nd International Conference on Software Engineering Workshop, June 2020, pp. 125-128.