Software Methodologies for Very Small Teams

Bootstrap DNA

When I was working on my undergraduate degree in Computing and Software Systems, I took a class in software engineering. The purpose of this class was to introduce us to the range of real-world processes that professionals use to develop software, processes that didn’t often come up in our academic work. That goal turned out to be a tall order for a three-month class, given the scope it tried to cover. It might have been more effective to pick one process and use it for a group project. Nevertheless, one exercise I remember from the class is matching software development processes to types of projects.

Here’s the type of question I’m talking about, from a University of New Brunswick class assignment:

Giving reasons for your answer based on the type of system being developed, suggest the most appropriate generic software process model that might be used as a basis for managing the development of the following systems:

a) A system to control anti-lock braking in a car

b) A virtual reality system to support software maintenance

c) A university accounting system that replaces an existing system

d) An interactive travel planning system that helps users plan a journey with the lowest environment impact

Methodologies

There are hundreds of specific software development methodologies. Perhaps there are so many because the best way to develop software, even particular kinds of software like embedded systems or web applications, is still an open question.

Nevertheless, methodologies do usually fit into some broad categories. Here are the ones in the introduction to Wikipedia’s software development process article:

Waterfall model

Each phase in the process must complete before the next one starts. For example, a requirements document must be produced before design work begins, and the design must be complete before developers start implementing the system.

Software prototyping

Developers build a version of the final product which is incomplete, but can be finished quickly. This allows developers and other team members to experiment with ideas and validate assumptions.

Iterative and incremental development

The product is built as a series of sub-projects, each of which is useful to the customer and can also be used to inform subsequent development.

Spiral model

This process uses each software project’s unique set of risks to create a customized version of one of the other models.

Rapid application development (RAD)

RAD processes emphasize the development phase of a software project, and spend less time on up-front planning. RAD is often associated with UI-driven projects.

Extreme programming (XP)

Characteristics of XP include frequent releases, pair programming, unit testing, building only what is immediately needed, and ongoing communication with the customer. Artifacts such as design documents are de-emphasized.

Agile software development

Agile processes value communication among team members, working code, and responding to change (see the Agile Manifesto).

In recent years, “agile” has become a term that almost every team wants to claim. Although some teams implement agile principles more successfully than others, a shift in the way software is delivered has made at least one agile goal more achievable: Ubiquitous connectivity means that consumer devices, and even interplanetary robots, can get software patches as needed. This reduces the risk of using methodologies that emphasize frequent releases. (Though you still need to be careful not to brick your robot).

Small Teams

Software development methodologies are most relevant for project teams, and getting them right becomes more critical as teams get larger. As I mentioned at the beginning of this article, different methodologies are appropriate for different types of software. This week I’m going to investigate what a methodology might look like for a single developer, working on types of projects where people often don’t often consider using a methodology:

  1. An undergraduate programming project in a CS class
  2. A graduate-level research project in a non-CS area
  3. The set of problems in a programming contest

1. Undergraduate Project

How do the components of an undergraduate programming project map to corresponding parts of a software methodology?

  • The customer is the professor who is teaching the class. He or she defines the requirements and evaluates how well the final product meets them. Therefore, the professor also plays the role of a systems analyst or technical stakeholder.
  • The project team is the student, who plays the role of architect, developer, tester, project manager, and possibly also UX designer and other specialized roles depending on the nature of the project.
  • The schedule is highly date-driven, possibly even time-driven in the case of automatic code submission mechanisms that close at 23:59:59 on the due date.
  • The requirements are fairly static, but not necessarily complete at the start of the project. The project team may need to obtain clarifications from the customer while the project is in progress. If they try to do this too late in the schedule, they may find that the customer has gone to bed for the evening.

What factors are critical to the success of this project?

  • Missing the deadline may result in significant penalties, so monitoring the schedule is critical.
  • Adherence to the specification may be more important than creative changes or extra functionality. It may be best to interpret requirements literally.
  • The codebase doesn’t need to be maintainable over time, since it is designed for one-time use.
  • However, code quality is still important, both because it facilitates development and because the code may be inspected by the end user (which would be unusual in a real-world project).
  • While project teams usually learn something from every project, in this scenario learning is the primary goal. The software itself doesn’t have to be useful for any particular purpose as long as it passes acceptance tests.

Which methodology is best?

This project de-emphasizes changing requirements, frequent communication with the customer, and communication among team members. Code cleanliness, correctness, and schedule predictability are key. There is only one release, and it needs to be complete.

Given these project characteristics, Rapid application development (RAD) would be a good fit. RAD is designed for small to medium-sized systems, focuses on reducing schedule risk by tackling complex parts of the system early in the project, and is associated with on-time deliveries. One aspect of RAD that doesn’t quite fit the undergrad project scenario is frequent customer interaction. In this case, the student would need to play the role of the customer, using the assignment description as a guide.

2. Non-CS Research Project

In this scenario, a graduate student is writing software to automate some part of a research project. As an example, consider research in computational biology. Although there is packaged software available to perform many tasks in this field, a researcher with a programming background might want to develop custom software for a particular research area.

How do the components of this project map to corresponding parts of a software methodology?

  • The customer and the project team are both the researcher. This is an example of a common scenario where a programmer is developing software for his or her own needs.
  • The schedule may be somewhat flexible, but there is probably still an overall project end date driving software development deadlines.
  • Requirements may be vague at first, and driven by ongoing research.

What factors are critical to the success of this project?

  • As with most software projects, the key to the success of this project is how well it solves a problem. In this case, the problem has to do with analyzing genetic data. Helping the researcher uncover a unique insight is more important than code quality, checking off features from a requirements list, or even finishing on a precise date.
  • Though code quality is not a primary concern, the software needs to be maintained for the duration of the research project. If the code gets too messy, fixing bugs or adding features may become prohibitively expensive. Good code quality may also facilitate releasing the software as open source for other researchers to use.
  • Learning something about programming is low on the priority list. The developer in this scenario is using his or her programming skills as a tool, not as a way to get better at programming.

Which methodology is best?

This project is like an ongoing prototype. There’s no need to finish the software, since it may never be released to anyone other than the author. In a traditional software project, a prototype is used to try out ideas and validate assumptions that can inform the final product. In this computational biology scenario, there will be new ideas to test and assumptions to validate throughout the duration of the research project, but there doesn’t have to be a final software product to release.

3. Programming Contest

The programming contest scenario is similar to the undergraduate project scenario. But before I get into the similarities and differences, I’m going to dig a bit more into the scenario. As I argued a few weeks ago, the definition of competitive programming depends a lot on the level of the participant. With that in mind, I’m going to split this scenario into two parts:

Scenario 3a: A programming contest from the perspective of a programming puzzle enthusiast (Level 0 — 3 from the linked article).

How do the components of this scenario map to corresponding parts of a software methodology?

  • In this scenario, the customer is the online judge. If the judge’s tests pass, then the customer is happy.
  • As in the undergraduate example, the project team is the student.
  • The schedule is fairly open-ended. At this point in their study of competitive programming, the participant should avoid time pressure. The important thing is to learn each problem type and not peek at the solution too quickly.
  • The requirements are completely static, though peers can provide clarification through online editorials and other discussions of the problem.

What factors are critical to the success of this project?

  • There are often no hard deadlines, since the goal is learning. However, serious young enthusiasts may be trying to move up to Level 4 (see the next scenario). In this case, there may be age limits in play (IOI and ACM-ICPC eligibility for high school and college students, respectively).
  • The customer (a non-sentient computer program) is completely literal about requirements. However, this doesn’t mean that the human being who wrote the problem description is equally literal. Some interpretation of requirements may be necessary.
  • Code quality and organization is important at these levels. Code, or at least design, can be re-used in future problems. And badly-organized code might be impossible for a beginner to debug, which might prompt them to give up on a problem that they could otherwise solve.
  • Learning is the primary goal, since the software being written has no practical purpose.

Which methodology is best?

Although Extreme programming (XP) was designed for a team of developers, several aspects of it are applicable to this scenario:

  • Frequent “releases” (submissions to an online judge) provide feedback about correctness and performance. There is no penalty for doing this, since Scenario 3a developers aren’t competing seriously yet.
  • Pair programming is exactly what is expected of ACM-ICPC competitors, who are provided with only one computer during a competition. Some experienced competitors recommend having one team member code while the other one looks over their shoulder to check for bugs — i.e., the classic pair programming setup. (The third team member works on solving the next problem on paper). Programmers anticipating a move to Level 4 may want to practice this approach.
  • Unit testing can be an effective way to approach more difficult programming puzzles.
  • XP encourages building only what you need and no more (YAGNI). This is exactly the mindset required for programming contests. In a contest, there’s no need to write code that runs faster than required by the time limit.
  • Although XP de-emphasizes design artifacts other than code and unit tests, I do recommend writing a design when practicing all but the most trivial programming puzzles.

Scenario 3b: A programming contest from the perspective of a competitive programmer (Level 4) — i.e., someone who is likely to rank high in a contest.

How do the components of this scenario map to corresponding parts of a software methodology?

  • In this scenario, the customer is the sponsor of the contest and/or the organizations who are paying attention to the contest. Contestants at this level can get rewards from programming puzzles beyond the learning benefits.
  • The project team is the contestant and/or teammates.
  • The schedule is very strict. The contest usually takes place over a few hours, and every minute is critical.
  • The requirements are what the contestants see when they open a problem, with minimal chance for clarification except in the case of glaring omissions.

What factors are critical to the success of this project?

At this level, success is very simple (but not easy): speed and correctness. Many contestants ignore normal coding standards, since they rarely need to do any traditional debugging.

Which methodology is best?

Competitive programming at this level is a unique process that doesn’t map well to any standard methodology. Like Scenario 3a, it shares some similarities to XP. But additional parts of that process, like unit testing, have to be thrown out since they are impractical in a competitive situation. This scenario really calls for a customized process. But as I mentioned in the Level 0 — Level 4 article, it’s rare to get to Level 4. For most people, it makes more sense to use a standard methodology and focus on learning.

Project Goals

The message behind the software methodology exercise is that there isn’t a single approach to software development that works for every project. Just as we need to select the right technology stack and architecture for the job, we also need an appropriate methodology to manage the project.

Software engineering research into methodologies tends to focus on large professional project teams. Since it takes a lot of resources to manage and execute those kinds of projects, even a small gain in efficiency can lead to significant savings.

But individuals working on small projects also need to think about the methodology that best fits their needs. CS undergraduates solve clearly-defined problems under strict time constraints while learning the concepts that the assignment is designed to teach. Scientists who use programming as a tool need to write code that is clean enough to be maintainable, while focusing most of their energy on their specialized work. Beginning to intermediate competitive programmers may be using more experienced contestants as examples, but they should avoid emulating their coding style and their single-minded focus on speed. And top competitive programmers have a relationship to code that is different from that of almost every other programmer.

Top Stack Overflow users are often professional developers with strong opinions about how code should be written. This can make it tricky to ask questions about coding topics that don’t fit the traditional model of a programmer on a project team. Programming advice tends to be targeted at the majority audience, professional programmers working on traditional projects. But not every software project has the same goal, and programmers working on those non-traditional projects may have good reasons to break some rules.

(Image credit: mira66)