I've started this page to collect materials and comments from people interested in the idea of Solo Software Engineering.
Whilst the emphasis in Software Engineering is on large systems I think there's a lot of scope for personal improvement. In particular, solo contractors need every advantage they can find to build more robust, maintainable systems, as they often don't have the margin to swallow significant debugging efforts.
Jo Walsh makes some good points more in the style of the Design Decisions diary, in August 2004.
Download the following Sample diaries and this summary of the Diary-Driven process, in
The entire OOFILE development diaries are available from our downloads page, comprising over 46,000 words in the database decisions diary alone. These show the evolution of a cross-platform database API including links to GUI forms, report-writer and graphing engine.
These notes describe a simple approach to software engineering originated by Andy Dent (firstname.lastname@example.org) and refined over several years of single programmer and small-team projects.
The essence of this approach is that it is simple enough that people WILL follow it and yet can contain enough information to significantly improve a project. Most importantly, this method tracks the THINKING in a project, where fancy graphical methods often only show the RESULTS of the thinking.
More info can be found in the April 96 edition of Software Engineering magazine, where the 'Solo Software Engineering' cover story mainly discusses this approach. Update: 10 year retrospective
A simple chronology of events affecting a project, completion of milestones, software upgrades etc.
This is the place you record all your random ideas. If you come up with an idea whilst working on something else, just put a quick note in here and think about it later. Often, rough entries here will migrate as full-fledged debates into the Design Decisions diary.
The key is to avoid breaking your train of thought by seriously considering something unrelated. Make a date with yourself to come back and review the ideas later. Often, if you leave it overnight, your subconscious will have clarified the original idea and you can rapidly expand on the entry.
Why you made decisions, what alternatives were considered and why they were rejected. This is the safety net that stops you repeating thinking a year down the track. It also helps you choose a pragmatic 'hack' now, and have simple pointers to where you need to improve the code later.
Go back and annotate Decisions later, if better reasoning comes along.
As detailed as you can get, sometimes down to line-by-line descriptions if you are making minor changes to a complex app.
Works best if you group your changes together under a simple one or two-line heading, particularly if that heading occurs in the Design Decisions or Thoughts diaries. Using these headings in your version control package helps bundle sets of changes.
Back to the A.D. Software home page
(c) Copyright A.D. Software 1994-2002
(All Rights Reserved).
Last Updated: 20th July 2006