about the AXE hex editor
axe screen

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. 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:

For a project that spans years and years, and may have gaps of years and years in development, this sort of thing is essential. Naturally, some parts were done in more of a rush than others, but in general there's a lot of commenting in there.

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: