I have been writing a lot of core, framework-style code lately. I realized that I there are a lot of different people who may end up using the software I write. These people include:
- Customer end users
- In-house end users
- Customer support staff
- In-house support staff
- Fellow developers
- Me
If I had to order this list by importance, I would probably put the “Customer end users”, and then “In-house end users” at the top, but after that I am not sure who the most important audience is. When writing any software, one should keep the end user in mind. After all, it is that group of individuals who will actually be using the software. If your software is difficult to use, performs poorly, or is buggy, the end user group will be the ones most directly and severely impacted. And when developing for *customer* end users, you can actually loose money for yourself or your company with software that the end user will not use (read: buy).
All but the simplest software has bugs. Software may also under-perform in the field. This is where targeting the support staff comes into play. Software that is easy to configure and monitor makes the jobs of support staff easier. I have been trying to build software that auto-configures or is very easy to configure. I am also building in a lot of logging using log4net. Using a config file, support staff (or I) will be able to turn up or down the amount of logging. I consider logging like writing comments. In fact, log statements can take the place of some comments in code. With heavy, customizable logging, it should be easier for support staff to find problems. I have even found myself writing extra logging functionality to make is easier to log all of the activity in my code.
The last group I mentioned are the group of individuals I work with: developers. Other programmers should be able to dive into my code and understand it. I try to name my variables, functions, classes, basically all of my software components with very explicit names. A variable called “dirRecC” is easier to type than “directoryRecordCount”, but the second is self-documenting. Lots of commenting, especially meta-data commenting so that function and class commenting shows up in Intellisense and can be added to documentation using automated tools like Sandcastle.
The point is to keep in mind *all* of the users of your software. If you do that, you are going to build a lot better software and make a positive impact on the lives of a lot of other people.
