Sunday, June 16, 2013

5 Commandments for Programmers

If you are in the business of software, under layers and layers of encapsulation you are selling a program. A program that couple of programmers has made for you, the brightest of your sales people can only get the program into your customers computer, and make them pay for it. But what if the customer says, my computer is in kitchen and the heat is making your software not work. Your sales people blanks out, and you start looking inside the contract you made with the programmers who coded it - did you take care of this situation?

Programmers are smart and sharp people, they think logically and king at solving problems. Here is the deal, everyday they are not the right smart, sharp, logical or in the mood to solve the problem correctly. They would use the above four qualities to make the program pass quality control. If you are betting your business and hence your life in the programs made, spend a little time ensuring your programmers are not sinners and following following commandments:

Thougshalt write secure programs

This world is divided between two categories of people, good people and bad people. Bad people make sh*t happen to good people. They make illegal copies of your software, break into your databases, causes havoc on your web applications and just for the fun of it.

Programmers can at least make the job a little difficult and hence less fun for them to crack into. Not only can your prevent illegal distribution of your software, you can prevent the sensitive data of your users from leaking online.

Web applications are the most easy to hack, look over XSS, SQL Injection, XSRF, Phishing, Web servers/MySQL security holes and more.

Software reengineering gives your competitors advantage to look in to your programming logic to copy the features more easily, specially if you are using languages like C# or Java. Look for tools that can make that difficult.

Thoughshalt design better

Design your architecture, and then design again. And then go back and design it yet again, and once you are coding everything and done everything. Dump it and do it once more. Don't rely on the programmers experience, rely on the Design Patterns. Programmers are going to write the software that makes it run on your test devices, and run perfectly. But a year down the line, you can't sell the same software, your cheapest competitors has the same features. You need to add and modify things, and you open the dusted svn repository, and voila not even the same coder can figure out whats going on.

Here is the good part, programming practice is here for almost three decades. The knowledge has been passed from generation to next, and only for the fact that programmers don't have this knowledge doesn't make it obsolete.

Learn what are the design principles and follow them.

Thoughshalt test

No matter how much truthful the statement is that every line of code need to be tested as soon as its compiled, I can't end up seeing coders who don't test. Where and how they get the notion that programmers write code. No! Listen, programmers test their programs as well.

Programmers test their programs.

Got it? You need to write code to test code, simulate and call the methods that you have just written. Just because it has compiled doesn't end your job. Don't punch the attendance now. Wait, run it, see the log output - you are doing debug.print, aren't you? Your testers don't have the privileges to dry run your code, set breakpoints, see these logs or use your IDE's swords. You do. Use it. Cut some bugs before it passes to people who are handicapped with just your program and a test environment. Start testing or leave programming.

Thoughshalt communicate

Great software are not made in solitude. No Mark Zuckerberg didn't coded Facebook from start to end, sooner he had Dustin Moskovitz, followed by many interns. And then a whole group once Peter Thiel invested in FB. The idea is simple, you need to discuss over the design issues you face, code that you write, the algorithm you implement. Technical discussion over the implementation details is not a waste of time, its savior for the later maintenance issues. 

Thoughshalt handle exceptions

There is an interesting method called assert(), it ensures the condition passed is correct and abort there if it fails. The assumption made with assert() need to be correct for your program to work correctly. But guess what, its a debug tool. Your help guide is not coming with a print of your assert statements, (which are already removed if you have defined NDEBUG). The file which is suppose to be there, is not there on that computer. Usernames can have ', users have meaning to e, ē, ĕ, or ė. Network connections can't be relied, users behavior can't be relied. Please do not let your program crash, with technical jargon printed over the screen. Think whats the best you can do in the exception block other than printing an error.

There's the rules I can think from the top of my head, don't end here. There are many good books to look into, check out:

97 things, pragmatic programmer, code complete, hf oops.

Want to work where advocacy of beautiful coding is followed? Check us @ Retina Software 

No comments:

Post a Comment