I've gathered some information about AXE, (Advanced heX Editor) that is a great tool for exploring
how information is encoded and stored on a computer. AXE is shareware and it might be interesting
to know what kind of effort is involved in creating a product such as this.
You can download it at www.jbrowse.com.
Here is some additional information about AXE that might give you a little more insight into
the software development process.
Development Time:
[From Benjamin Peterson, the devoper of AXE]
Creating the core codebase for AXE took about three months, four days a
week, about six hours a day. Remember that AXE is written in MFC, which
is staggeringly inefficient in terms of developer time and complexity.
The change from AXE 2 to AXE 3 (which took place at least 3 years later)
took about four months, two days a week, four hours a day. Small
versions have taken 20-80 hours each. However, this is only *coding*
time; as you know, the time spent to create a project is far more than
just the coding time. I would estimate that creating web pages and docs
took several hundred hours, and testing (including finding and
communicating with beta testers) takes an unknown but perhaps larger
amount of time. However, the schedule is very flexible.
LOC:
[From Benjamin Peterson, the devoper of AXE]
Axe contains about 45,000 LOC in about 150 classes. Of these, about
10,000 LOC are not by me (modified public domain code) and not all the
code is actually used (some is experimental, some is public domain code
files that I only use partly). The use of PD code significantly reduced
the time taken to develop AXE, and I release PD code back to the
community (although not the AXE code).
Because of the ugliness of MFC, the code in AXE is distributed in a peculiar way and is longer than it would be in almost any other framework. In C#, AXE would only be about 2/3 as long.
Development Environment:
[From Benjamin Peterson, the devoper of AXE]
AXE is MFC, because that was the standard Windows framework when AXE was
started and at that time I worked as an MFC programmer. I would never
start a new project in MFC now; I'd almost certainly use C#, which is
what AXE 4 will use. MFC is hard to maintain and sometimes requires vast
knowledge to do the simplest things. AXE supports windows 95/98/me but
this is a legacy thing and the price for supporting them is really too
high (e.g. no unicode). AXE was begun with MSVC 5 and is now built on
MSVC 6. AXE4 will use VS.NET or possibly just the raw C# dev tools.
Documentation:
[From Benjamin Peterson, the devoper of AXE]
AXE is usually heavily-commented, using the following standards:
- Comments are versioned (i.e. comments show what version a change was made in) and the version numbers can be grepped easily
- 'FIXME' and 'TODO' comments are used to mark areas that must be changed
- Areas that don't do what you expect contain a readable description of what the problem is and how it is being worked around
- Non-trivial classes have a brief overview at the top of the file
- Long methods are commented step-by-step
When AXE was started there were no internal documentation products like NDoc and Doxygen, but if I were starting a new project now I would certainly use one. AXE uses Visual Source Safe. I would like to move to Subversion at some point.
Maintenance:
[From Benjamin Peterson, the devoper of AXE]
I know I will want to replace AXE some day, so maintenance is carried out on the assumption that it is
okay to become unmaintainable at some point. This is a policy; projects
have life cycles and AXE is now at least 6 years old and toward the end
of its life cycle. Version 4 will be a new start.
Some of the earlier code, for structures in particular, is just awful
and I'm not sure why. I must be imperfect :)
Creating a "REAL" Product
[From Benjamin Peterson, the devoper of AXE]
AXE is not a *real* real product. The challenges of a project like AXE
are very unlike those I meet in my day job. AXE is developed (almost)
singlehanded, with no deadlines and no fixed requirements. This doesn't
necessarily make it easier, just different.
If I had to give some advice on projects like AXE, it'd be:
- Even with a private project like AXE, coding is still only about 3/5 of the total effort and skill set
- People will circumvent any anti-piracy system you put in, so don't bother
- When you finish the program, that's when you start the hard part: web pages, search engines, payment systems, users, advertising, beta testers, packaging, uploading, versioning... you never really finish, you just reach a stable level of maintenance.
- Even if (like me) you decide to charge for your product, try to get involved with free/public domain/GPL software. It's an important community and you can learn -- and contribute -- much.