Home

Map

OS++ Down Load

Doco_A

Youtube

Chat

News

Shop

//#! Declaration: http://osplusplus.org/2022standard/Technical_deficit

TLDR; The top line, is a standard declaration using the format (CODE.org/STANDARD/GRADE). You are using this declaration to notify future readers that the following code is written in OS++, with the 2022 syntax standard. This is the declaration you use when you need to fix something, to meet a deadline. It means we will come back and fix this properly later.

The declaration just happens to be an HTML link, which has more information.

For a list of standard declarations and a better explanation. Please visit http://osplusplus.org/2022standard/professional
To see the Language documentation for this language. Please visit http://osplusplus.org/2022doco

Technical_deficit standards and grades

TLDR; Technical_deficit, Declaring cancer

If you make this declaration, it is important to outline the nature of the technical deficit so it can be corrected, if need be, later. A quick REM at the top of the code is sufficient. After all you are the expert in this area and you need to alert other stake holder as to the nature of the situation. It is important to document which category the technical deficit falls into. For example Technical_deficit/ Category 3. Other info that is helpful would be the authorising party (usually project manager) and the time frame for its correction.

This procedure allows a professional programmer, who knows they are “turd polishing” (*1), to vent and warn future programmers and stake holders that they were only doing as directed by the business. Or by some other constraint. (Such as time, money, or interest)

What is this?

Technical_deficit is where procedures / standard are not maintained for a “reason”. The reason usually is due to time constraints and the need to meet deadlines.

There are three categories of Technical_deficit.

1. Benign technical deficit. It’s bad but it does not grow and will eventually be rewritten anyway. Example include the odd goto or block of code which has not been properly documented. Variable names which offer no explanation. eg “NOT_again” or “Baddog2” is not a helpful variable name. (Resource overhead is minimal or non existent)

2. Malignant technical deficit. A breach of the rules that extracts a ongoing human or resource cost. Example: Too many gotos creating an unreadable mess of spaghetti code and therefore requires each generation of programmer who comes into contact with the project, to spend time picking apart the project to see how it ticks. (Resource overhead is constant but not growing)

3. Interest bearing Technical_deficit. A breach of the rules that gets progressively worse as time goes on. The Pain of fixing it is slightly more than the ongoing issue and so it just builds. Eg Recyling unused columns in a database with the wrong name and data type. eg “Postcode2” char20, is reused to store “new_feature” big int. Each generation of programmers has an overhead of learning this “quirk” and converting the data type back and forth slowly infects the code, as more features are added that use the column. As the database grows the time it would take to correct the issue becomes longer and more complex. And the business rational to make the changes in the code and database become progressively more expensive and therefore harder to justify. (Resource overhead is expanding exponentially)

(*1) Turd polishing. This is where a programmer takes an absolute turd of a program in a code base and fixes issues and adds features. IE the programmer polishes it. But no matter how skilful the programmer. The code is still a turd.

Site summary (added to bottom of every page)