Saturday, November 30, 2013

Emergency landing.

Recently I was flying on IndiGo. The pilot announced, "We are expecting to land before schedule, thank you for flying with IndiGo". Somebody had a heart-attack! The air-hostesses started running around with Oxyzen cylinders and First-aids, the pilot again announced, "If there is any Doctor please let us know." I was thankful I was not a Doctor.

Then the dreaded, "We need to make an emergency landing at Lucknow to deboard the patient." Ah, there, we were expecting to land before time and now it would be delayed by like 10 minutes. Land, deboard, fly again. Yes, right?

No. After the patient was deboarded,  a set of process started. The engineers inspected the plane with their usual colorful forms, the agents checked every hand baggage to check whose who, the air hostesses made a detail report over the patient heart-attack and steps taken. I think even the air-plane was wiped clean and refreshments were quality checked. After 1 hour of impatience waiting of the customers, finally the pilot announced, "We are clear to take-off."

The point? A business is not run by couple of competent employees or sharp decision makers. The business runs on a "systemetic process". If you don't have every step of your business operation and process documented and transparent, you are running a hobby not a business. The number one rule of growing your business is to have a process and follow it. No matter how inconvenience it is to your employees or the customers, or yourself. Following the steps while minute to minute product versions or "patched" builds are given to end users, will ensure a turbulence free flying of your business.

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 

Monday, March 18, 2013

Are we lazy programmers?

When we were young programmers, someone said they are learning programming HTML. Now, some might not understand it - but its the biggest LOL moment for anyone. Dude, HTML is not a programming language. Without much change in earth magnetic fields, the world is upside down now, HTML5 is now a mobile app development language. You can really make apps that sells in AppWorld for BlackBerry and other devices programmed in HTML programming language.

The other habit that we programmer have formed is of pressing the Run command almost as a nerve reflex, written a function, build&run. Added a blank class, build&run. Declared a variable, Build&Run. The habit to try to run the program and see fast results, is, well making us do do quick fixes than doing it right. Again, running compiling and running programs were just a lot harder in old days. And hence it was more welcoming to actually review the code with eyes and ensure of resolving bugs before doing a compile and link.

Getting to market was even more harder, required budget. When we used to write programs for Visual Basic, it created SETUP than spanned to multiple floppy drives (VB has an option in installer to support multi-disk spanning). The disks were labeled in order and shipped to customers and reviewers. Don't get me started on how many disk failed during transitions, even after putting Handle With Care on the envelopes. Now we have the AppMarket concept, just build a fart app and upload it online.

So are the new generation of programmers actually lazy?

Actually programmer is becoming a more broader word, we need to create new words. Like the way we differentiated coders and developers. A developer has to analyze a problem, design a solution, implement with code and test his work.

The question also depends on the Company you are employed in, if you are working in a company making "Flashlight" app you might do well being a lazy programmer. If you are in one requiring Tzinga every hour, your better off going more traditional.

"So do you want to be a lazy programmer all your life, or join us and change the world?"

No offense intended for HTML... programmers, ah cr*p.