What Recurs Every Software Project

From SoftwareDevelopmentImprovementParadigmShift:

Software projects do not repeat like a manufacturing assembly line. Software projects do not repeat like a reproducable experiment. But something about them repeats... Maybe we need a word other than "repeat" that means "that which recurs, and how it recurs, in every software project". I am pretty sure it is not a sequence of steps that recurs, like a recipe. It is more like the same problems and same solutions recur, but in different sequences and different guises. -- Stan

Making deals, bargaining, negotiating, etc. ItsaPeopleProblem
Flow of time
Customers
Funding
Budgeting
Vacations
Dependencies
Builds
Resource Planning
Defect management.
Manufacturing
Customer Support
Marketing
Creating teams.
Programming.
People problems
Company problems
Problems in the world
Tools that fail
People who fail
Good programmers writing bad code.
Dreaming
Thinking
Continuity of Thought
Design
Writing code
Unit test [ProgrammerTest].
Acceptance test
People quitting.
Yearly evaluations.
Shortage of resources.
Change in requirements.
Branching.
Delivery.
Field support.
The next release.
Multiple simultaneous releases.
Training.
Equipment failures.
Software upgrades.
Hardware upgrades.
Useful meetings.
Useless meetings.
People conflicts.
Writing documents.
Getting to work.
Eating lunch.
Attending company functions.
Meeting with vendors.
Evaluation of products.
Watercooler talk.
Vendor relations.
Health benefits.
Security.
Licensing.

Items that apply to many (but maybe not most) projects:

Hiring/Firing
Office reorganization.
Company reorganization.
Childbirth.
BurnOut.
BadProgrammers writing BadCode.
Managing stock and options.
Airplanes, rental cars, and hotels.
Retirement.
Tax planning.

There is no defined process that explains how to cope well with all of the above. We (hopefully) learn through years of experience and working with others who already know how. But is there a better way to learn and teach how to cope well with all of the above? Maybe a better way to write it down? How do we better CodifyAcquiredSoftwareWisdom?

I'm not sure why people jump from talking about a manufacturing processes to writing great novels. What about writing just ordinary novels? Perhaps writing great software is like writing great novels, but I'd be happy if people learnt to reliably produce half-decent software.

Writing half decent novels is something that people can learn on Creative Writing courses. Perhaps this is a better model for software development than a chemical plant. -- StephenHutchinson

Items following now rendered less relevant by the splitting of the list. Feel free to delete or defend if they're yours. I'll come back and tidy them away if you don't care about them. 2002/07/11

It's interesting i didn't come up with the travel related items because i don't really travel. What recurs depends on where we are.

So travel doesn't recur every software project. It should be deleted from the list above. Taking the 'every' very strict will yield a more limited list. We're looking for the minimal set here, I believe. This article is somewhat related. It discusses human factors in software development: http://members.aol.com/acockburn/papers/adchange.htm

-- PieterVerbaarschott

There are lots of other items that don't apply to every project: hiring/firing, people quitting, managing stock and options, creating teams, people problems, childbirth, etc. However, those items are still applicable to any study of software projects. Knowing the minimal set that is truly universal would have some merit, but focusing only on that would ignore too much.

Agreed. I guess I wasn't really trying to get the list truly minimalistic. It surely helps to differentiate between projects in general and the subset of software projects. Maybe it also helps to note in which way the more general items affect software projects specifically. -- pv

But software projects are projects so wouldn't everything need to be included?

Depends on what you're looking for. Maybe the page title should be WhatRecursEveryProject? then. I guess software projects are different in specific ways from just projects. The things encountered could be the same, as the list and discussion above suggests, but what I'm interested in here is how these things affect the software produced. This particular bias is the reason for my comments on this page. --pv

The page seem to have been here a long time and I do not know why "people issues" have been missed out. Maybe project managers here got intimidated to silence previously? -- dl

CategoryProject