Nicholas Sheppard
Software development life cycle

Most of what I read in software engineering textbooks, magazine articles, and blogs seems to assume large teams of developers working on sprawling projects for giant organisations like Microsoft, Google or the Apache Foundation. Nearly all of my own software development experience, however, has been in teams of one or two developers working on research prototypes or customising open source software. One review, admittedly somewhat dated, suggested that around half of all software projects might be of this scale (Deshpande et al., 2011). What becomes of all those stand-up meetings, Kanban boards, continuous integration tools, and so on, in such miniscule projects?

Many principles and practices advocated in popular software development methodologies can be applied without modification by small teams and lone developers: one list (Bernabé et al., 2015) includes the agile principles of simplicity, embracing change, making decisions, user stories, estimation of time required to complete a task, planning, automatic testing, re-evaluation, limited documentation, partial prototypes and automated build processes. But less obvious is how freelance or lone developers might work in close proximity with the client, or implement pair programming or daily stand-up meetings.

A number of scholars have described how they adapted well-known software development methodologies to small teams or lone developers, often in the context of university teaching where teams and projects are of necessity small (Marthasari et al., 2018; León-Sigg et al, 2018). These scholars simplified the process in obvious ways, such as by eliminating the need to assign roles in "teams" of one, and also replaced stand-up meetings with documentation and on-site clients with telephone or e-mail.

Other researchers have looked at how software development can be divided into discrete tasks that can be carried out by a lone developer, often in the context of "crowdsourcing" services like TopCoder and Bountify. Thomas LaToza and colleagues (2018), for example, propose "microtask programming" to divide software development into a collection of small tasks, each of which can be completed in a relatively small amount of time by a lone developer. While they say this approach can produce workable software from the contributions of a large number of developers each with only a small amount time, their trial suggests that this approach is very inefficient compared to a single developer with a lot of time: forty-four hours of total developer effort produced only 490 lines of program code and 2920 lines of test code, with much of the test code being redundant.

Crowdsourcing and microtasking research tends to focus on how organisations can get the best out of outsourcing software development tasks rather than how software developers can best approach the small tasks that result. LaToza and colleagues, for example, stress the importance of (i) identifying tasks that can be performed without needing to understand an entire codebase, (ii) dividing larger tasks into incremental improvements, and (iii) automating the production of tasks so as to minimise the overhead created by the first two steps. One may suppose that the resulting tasks, being very small, do not require any attention to software development methodology at all.

Recent studies of crowdsourcing platforms conducted by Inam Illahi and colleagues (2019) and Stamatia Bibi and colleagues (2020) suggest that crowdsourcing competitions frequently produce unsatisfactory results. Illahi and colleagues conjecture that this is because most participants are inexperienced developers looking for practice, whereas professional developers typically prefer their regular paid work; Bibi and colleagues suggest the lack of a systematic method for identifying and describing tasks to be crowdsourced. To be fair, Bibi and colleagues do note that software development tasks achieved the highest quality and lowest cost out of types of tasks they studied, which are the tasks of most interest to this article.

Lone workers in other fields

Steven Chen and Kristin Schiele (2017) have studied how small-to-medium enterprises able to employ only one "designer" (architect, graphic designer, fashion designer, etc.) make the best use of that designer, or try to. While earlier literature suggests that multidisciplinary teams produce designs of higher quality and greater innovation than lone designers, smaller firms using a lone designer out of necessity have several strategies available to them in positioning their work against larger firms:

  • a lone designer can experiment with vaguely-defined projects;
  • a lone designer may be more consistent and cohesive than "design by committee";
  • a lone designer eliminates the overhead due to coordination, deliberation, etc. that might occur in a team;
  • a lone designer may nonetheless be part of a broader network from which he or she can obtain feedback;
  • a lone designer may offer a personalised face-to-face relationship for clients; and
  • a lone designer may carry credibility from past projects, awards, and so on.

Chen and Schiele conclude that a multidisciplinary team is surely the best choice where one is available, as per the earlier literature; but where such a team is not available, a lone designer with a strong network may also get good results. They do not, however, say what methodologies a lone designer might employ in carrying out his or her work, except insofar as a designer embedded in a broader professional network may seek feedback from that network.

ISO 29110: software development in very small entities

ISO 29110, Standards and Guides for Very Small Entities involved in the Development or Maintenance of Systems and/or Software, intends to provide guidance for software development firms (or departments) having no more than twenty-five staff. The standard describes four profiles for Very Small Entities, of which the first two—the Entry and Basic profiles—are relevant to the kinds of projects discussed in this article. The Entry profile is intended for start-ups and projects of no more than six months duration while the Basic profile covers a single team working on a single project.

ISO 29110 doesn't define or mandate any particular methodology, but provides checklists against which very small entities can verify the quality of their processes. The software implementation process, for example, ought to ensure that tasks are carried out according to the project plan; software requirements are defined and communicated to the customer; software components and interfaces are defined; components are constructed and (unit) tested then integrated and (integration) tested; the software is delivered to the customer; and the customer verifies that the software performs as expected. Sounds like a lot of work—but then again so is developing software alone!

References

Rodrigo Borrego Bernabé, Francisco José García-Peñalvo and Iván Álvarez Navi. Faat – Freelance as a Team. Proceedings of the Third International Conference on Technological Ecosystems for Enhancing Multiculturality, Porto, Portugal, 7-9 October 2015, pages 687-694.

Stamatia Bibi, Ioannis Zozas, Apostolas Ampatzoglou, Panagiotus G. Sarigannidis, George Kalampokis, and Ioannis Stamelos. Crowdsourcing in Software Development: Empirical Support for Configuring Contests. IEEE Access 8, 2020, pages 58094-58117.

Steven Chen and Kristin Schiele. Positioning SMEs with a Lone Designer: A Qualitative Study of Small Design Firms. Journal of Marketing Theory and Practice 25(3), 2017, pp. 213-233.

Shweta Deshpande, Joe Bolinger, Thomas D. Lynch, Michael Herold, Rajiv Ramnath and Jayashree Ramanathan. Teaching Students Software Engineering Practices For Micro-Teams. 41st ASEE/IEEE Frontiers in Education Conference, Rapid City, South Dakota, 12-15 October 2011, Session T1H, pp. 1-6.

Inam Illahi, Hui Liu, Qasim Umer and Syed Anees Haider. An Empirical Study on Competitive Crowdsource Software Development: Motivating and Inhibiting Factors. IEEE Access 7, 2019, pp. 62040-62057.

Thomas D. LaToza, Arturo Di Lecce, Fabio Ricci, W. Ben Towne and Andre van der Hoek. Microtask Programming. IEEE Transactions on Software Engineering 45(11), November 2010, pp. 1106-1124.

María de León-Sigg, Brando J. Pérez-Valenzuela, Sodel Vázquez-Reyes and Juan L. Villa Cisneros. Adaptation of the Initial Software Development Method for a Single Developer. 6th International Conference in Software Engineering Research and Innovation, San Luis Potosí, Mexico, 24-26 October 2018.

Gitah Indah Marthasari, Wildan Suharso and Frendy Ardiansyah. Personal Extreme Programming with MoSCoW Prioritization for Developing Library Information System. Proceeding of the Electrical Engineering, Computer Science and Informatics (sic), Malang, Indonesia, 2018, pp. 537-541.