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.
	* BadProgrammer''''''s 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