coder . cl

I don’t use recipes to ensure the quality of my software. Most of those development tasks to make the software a reliable tool are techniques learned along the time, without considering the methodology behind the software development. I can’t stand for any methodology as the better methodology that you can use. I just follow few commandments or rules on software development, and all of them bring me good results.

1. "request well specified requirements"

   Request well specified requirements. Even if you are using one of those dynamic methodologies. Never let your boss to set ambiguous requirements, this will be your hell and nightmare, and request a formal requirement in the proper email and documentation. I do not mean a word document with tons of lines, I’m talking about requirement clarifications, where you are responsible to request the proper clarifications if you are looking something ambiguous. Also your boss is responsible to write well specified requirements, both technically and functionally. There are well known gay bosses who send ambiguous requirements and usually they are changing those requirements every day… Yeah! the same ones who are delivering your application with the initial deadline even when they are taking new ones! If the client do not have the proper knowledge about software, the client do no have the proper knowledge to evaluate deadlines, the same happens with your boss.

2. "formalize your progress"

   Formalize your work progress, by using mails, the proper VCS comments, and source code documentation, even is that is required by your boss or not. You need to register properly your work progress, and you must create the proper sub-milestones for each project milestone which is assigned to you.

3. "forget that job without a technically skilled boss"

   Do not work on company where your boss is not capable to define properly what he wants and even on a company where the boss is not capable to catch the client requirements. A boss must be capable to charge every new requirement to the client, if your boss do not do that, your boss is giving away your time and your life. If your job requires you out of workday, your job sucks, and even your boss, since he/she is not capable to handle new requirements and make the proper charge. Also, a good manager knows that you need the proper time to do all those tasks listed bellow ;)

4. "clean code"

   Clean code, legible code and well indented code will allow more developers to handle it. If work on a company where real teamwork matters, everyone will be capable to support your development if you are busy in other task. Clean code is that one which has few ugly modification — most of them regarding software performance — and follows well known coding standards, such as naming conventions, indentation rules and documenting techniques. Regard a 7 bit US-ASCII encoding, and never use accents — simply because some editors, compilers, and coding tools do not support other encodings and most software is compatible with 7 bit US-ASCII encoding. For localization use external packages, such as property files in Java, gettext files with C and C++, and related tools.

   You always must have in mind that your code will be taken into the most ancient platform and the most newbie coder — just someone what happens to some environments when you setup UTF-8 encoding on the project and you add a non UTF-8 file in it, and the headache that you get when you are not conscious about WTF is happening. Your boss will be entirely happy with the lost time…

5. "commented code"

   Well documented code is not that one which holds poetry inside it. Useful and descriptive comments are those ones which allows the developer to understand which logic is contained in your functions. Also you must comment every modification separately, for example if you change a b * Math.pow(2.0, a); operation by a << b to get more performance, comment it!

   There are well known commenting techniques. Take a look on known documents, such as manual pages to have wide perspective on how to comment the code — manual pages have the best documentation structure that I’ve ever seen. I think that toy documentation, like javadoc, really sucks, since it is poorly redacted and non descriptive. Do you really know someone who is able to develop an entire Java application just by looking at the javadoc without looking for examples? The same happens with C# and .NET documentation.

6. "use annotations to track your project"

   Classical annotation, on your VCS or code comments will help you to track pending tasks, enhancements that may be done and will allow you to pass messages to other developers. There are classical ones TODO: and XXX: for example. You can use TODO for all your "To Do" tasks in each file and "XXX" for precisely document modifications and enhancements that may be done on the code. This will ensure that pending tasks will never be lost in some ugly word document on an erased mail which tries to poorly describe a required task. Also you can support those tasks by using Issue Tracking and Bug Tracking systems, but are like those ugly lost documents and you can not explain in detail with the code itself which task is required where ;)

7. "check for null pointers"

   Before using an object, check if it is null, otherwise use an error catching mechanism. This rule do not needs more explanations, and is a well known issue and spotted the right title: The Billion Dollar Mistake.

8. "do not trust user input".

   I do not trust the user input, never. I’m always trying to validate the user input, since the common user is doing mistakes using applications. The user input and generally the input in your functions require certain validation, from the data type to expected values, such as range or length. Validation in Web Applications should be made in both sides too, the Web Browser — using JavaScript and HTML attributes — and the server side. The most important one is the server side validation and it is a must. On other kind of applications, user input must be validated too.

9. "apply debugging".

   Do not stay comfortable with the code working. Debug your applications, tracing each step. Remember that you can modify variable values in your code inside your debugger, so you can do more code hardening tests. Learn about your debugger the better as you can. Read books on debugging techniques: "Debugging" and "Code Complete", for example. I’m conscious about the fact that every language and every debugger works different, but debugging techniques are always sharing common tasks and checks.

10. "apply static analysis".

    Apply static analysis to ensure that your code is clean and using better practices. Indeed, those kind of tools will help you to discover more bugs. Some of them can do code path checking and Boolean evaluation checking. If the language that you are using do not have support from static analysis tools, it really sucks. There are well known tools for doing static analysis and source code checking, and also are well known bugs discovered along the time with those tools. You must combine debugging and static analysis together.

If you do not work on a company where you do not have the proper time to do each of those tasks listed above, your job sucks. Surely you are delivering bad code, sometimes with those invisible bugs that appears when you are not expecting them. Falling one time and another on the same bugs and the same project that may not be released at time.