Code Rating System

I would like to propose a rubric of classifying code with regards to its completeness and maintainability. This system will have two parts, separated by a dot '.', both of which are ratings from 0 to 4, 4 being the best. The first part or the part before the dot rates the objects and methods that perform the work, and the second part, or the part after the dot, will rate the quality of the automated testing. With this scale 0 would indicate that the code exists in some manner, but it is not working, and a 4 would mean that the code is in an optimal state for long term maintenance. So code that rates as 1.1 would mean that the code and its test work, but it is in a poor state for maintenance. While code rated as 4.4 would mean the code and its automated tests are in an optimal state for maintenance.

The elements that this system will rate are:

• +1 Does the code work as intended.
• +1 Are sufficient comments and documentation in place.
• +1 Are sufficient logging statements in place.
• +1 Are coding standards followed.

This code rating system is intended to be customized by each organization. As an example perhaps there is an organization that has no coding standards and they would just use a a 0 to 3 scale, or perhaps an organization considers on schedule to be important so they add an on-time and an on-budget item and use a 0 to 6 scale.

Logging

Logging is often underutilized in development companies. When an organization really understands the value of logging it will reduce the maintenance cost of code dramatically.

What is a log? A log is a short message that an application stores to give a maintainer information about what is happening behind the scenes (behind the user interface). Logs are generally stored in a file or a database so that they can be read and/or searched to find information about the running system.

Logging should be broken up into levels; each level having a specific and distinct purpose. In general those levels are as follows:

1. Unrecoverable Problems: When something occurs that causes the entire system or application to cease running unexpectedly. When this occurs the log should get as much information about the state of the system and, if possible, the factors that caused the problem. This is generally difficult or impossible to capture because if a contingency plan was possible to implement it would be a level 2 problem.
2. Undesirable but Recoverable Problems: When something unexpected occurs, but the system is able to recover, and return to normal operation. This type of problem is often caused by a necessary part of the system becoming unavailable. If a recovery is possible it is usually done by waiting, reinitializing part of the system, or switching to an alternate of the element that failed.
3. Normal System Operations: While the system is running it is often useful to get information that allows a maintainer to verify that the system is running as expected. This is often information about periodic state of the system, or significant operations being completed.
4. Major Module Operations: This level is used to monitor the normal operations of a module. It is generally not included in normal operation logs, but is useful to monitor the operation of individual modules while the system is being tested.
5. Major Feature Operations: This level is used to monitor the normal operations of a feature. It is generally not included in normal operation logs, but is useful to monitor the operation of individual features while the system is being tested.
6. Minor Feature Operations: This level is used to monitor the fine details of a feature. It is not included in normal operation logs, but is useful to monitor the fine details of a feature while the system is being tested.
7. Line by Line Changes: This level logs information about each non-trivial variable change. This is generally only useful when attempting to debug.

Ignocharlabidding (Cheat 'em to Win 'em)

Charlabidding is the act of underbidding a contract, landing the client, and then over the course of the project asking for more money to cover the costs of what the customer really wanted/needed.

Ignocharlabidding is doing this ignorantly.

While ignocharlabidding is not as ethically wrong a charlabidding it is still very devastating to the community. This usually occurs when a contractor ignorantly underbids a project, and by the time it is recognized by either party the money is gone and the customer has to decide whether to put more money into the project or try to find another vendor. Since this is usually a small business transaction, the owner doesn't have the money to start over so he puts more money in hoping that will be the end of the over-run. This cycle usually repeats itself until a poor product is release or the customer becomes too frustrated to continue the engagement.

The harm done by ignocharlabidding is usually two fold: It sours the customer, and it puts money in the pocket of an ignorant charlatan rather than a legitimate knowledgeable contractor. So the bidders that knew what they were doing, and could have produced a good result, are left with nothing. The ignorant contractor has just survived for another couple months to live and bid again. And finally there is poison in the community that prevents or discourages other business owners to try to enter a new technologicaly realm.