Software development tends to happen in cycles and it's good to be aware of this.

The innermost cycle is the edit-build-test-debug loop. You write or change some code, you build the software (assuming a compiled language), and you run the software to test it, either manually or by using automated tests.

Being the innermost cycle, it's probably where most of development time happens. It tends to pay to optimise it to make it as fast as possible. Each of the parts can be optimised. For editing, use an editor you like and are comforable with. Also, a keyboard you can type efficiently with. For building, use incremental building, and maybe turn off optimisation to make the build got faster. For testing, maybe run only the relevant tests, and make those run quickly.

Other cycles are:

• The TDD cycle: add a new test, add or change code to make test pass, refactor. This tends to embed the edit-build-test-debug loop. Usually at most minutes in length.

• Adding a minimal user-visible change: a new feature is broken into the smallest increment that makes the user's life better, and this is then developed, often using a number of TDD cycles.

• A "sprint" in Agile development: often a week or two or three, often adds an entire user-visible feature or other change, or several.

• A release cycle: often many weeks or months, adds significant new features. The set of added features or other changes, and the length of the release cycle are all often determined by business interests, business strategy, and often ridiculed by developers. This sometimes happens for open source projects too, however. For example, a Linux distribution might synchronise its own release schedule with multiple major, critical components it includes.

• The maintenance cycle: after the software has been "finished", and put into production, bugs and other misfeatures get fixed and once there's enough of them, a new release is made and put into production.

In each case, it is useful to know the intended and expected length of the cycle, and what needs to happen during the cycle, and what the intended and expected result should be. It is also useful to try to identify and remove unnecessary clutter from the cycles, to make things go smoothly.

It's not often that we just link to a single article, but sometimes that article is simply "worth it". In this instance I recently read a posting by Loup Vaillant which made me think "This needs to be distributed to the yakking community" and so here we go…

Loup wrote about what needs to happen when you think you're finished writing your free/open source project's code, and I think you should run over there right now and read it: After your project is done — Loup Vaillant

If you're still here afterwards, well done. Now go and look over any projects of your own which you consider "finished" and see if there's anything Loup hilighted which still needs to be done to them. Maybe make a next-action to do something about it.

The history of computing has a number of famous bugs. It can be amusing to read about them. Here's a start:

• The very first recorded bug (1945)
• The Mariner 1 crash (1962)
• The Therac-25 radiation overdose (1985)
• The AT&T network failure (1990)
• The Pentium bug (1994)
• The Ariane 5 rocket explosion (1996)
• The other Pentium bug (1997)
• The Mars climate orbiter crash (1999)

What's your favourite bug? Please tell us in comments.

We've spoken about how you are not finished yet with your project, how to avoid burning bridges in conversation, how to tell if a project is dead, or merely resting, and on knowing when to retire from a project. Today I'd like to talk about coming back to a project which you have taken a hiatus from.

Whether your break from a project was planned or unplanned, whether you were fundamental to a project's progress, or "just" a helper, your absence will have been felt by others associated with the project, even if they've not said anything. It's always a nice thing to let anyone who ought to know, know that you have returned. Depending on your level of integration into that project's community and the particulars of your absence, your own sense of privacy around any reasons, etc., it can be worth letting the community know a little of why you were away, and why that means that now you are back.

If your time away was unannounced, unplanned, abrupt, or otherwise disruptive to the community, it can also help to mend things if you are prepared to apologise for your absence. NOTE I am not saying you have to apologise or excuse the reasons why you were absent, merely to note to the community that you are sorry to have been away and that you look forward to reintegrating.

Just like I'd recommend when you join a community, make a point of discussing what you intend to achieve in the short term, in case there's someone who wants to assist you or has been working on something similar. Also make it clear if you've kept up passively with the community in your time away, or if you've essentially a blank for the period of your absence. That can help others to decide if they need to tell you about things which might be important, or otherwise relevant, to your interests and plans.

If you were specifically, and solely, responsible for certain things when you were previously part of the project, you should, ideally, go back and check if anyone has picked it up in your absence. If so, make a point of thanking them, and asking them if they wish to continue with the work without you, share the burden with you, or pass the work back to you entirely. If that responsibility was part of why you had a hiatus, ensure that you don't end up in a similar position again.

There are many more suggestions I might make, but I'll leave you with one final one. Don't expect the project you re-join to be the same project you left. In your absence things will have progressed with respect to the project, others in the community, and yourself. Don't be saddened by this, instead rejoice in the diversity of life and dig back in with gusto.