Financial bonds in IT jobs should be made illegal ASAP

coffee_compThere’s a practice among many IT companies (at least in India) to solicit financial bonds from freshers during recruitment. Some of them take it a step further and demand the academic marksheets and certificates of the students as mortgage. What’s more unfortunate is that these include Indian companies. Continue reading Financial bonds in IT jobs should be made illegal ASAP

What the Tech Industry has learned from Linus Torvalds


Some unbelievable facts about Linux. Some emerging ideas on technology. The closing lines are priceless.
Linux Foundation Executive Director Jim Zemlin at TEDx, Concordia University, Portland.
Don’t aim for success if you want it; just do what you love and believe in, and it will come naturally.

Computer Engg. in India: fire the interest

coffee_compComputer Science and Engineering has been a lucrative stream to many aspiring engineering students in India. But once they join an engineering institution to study it, the course structure, regularities and trivialities sway them away from the actual goal. To begin with, most of them don’t even master a single programming language in the first year. Till the third year they don’t have any idea of the practical application areas of Computer Science and Engineering. When it comes to the grand final project, most of them are mugging up textbooks and preparing for GATE or examinations (which is good but not at the expense of the learning from the final project) or routine interview procedure. Many of them end up copying or even buying the final project. When they leave college they are just balloons of technology waiting to be burst aloud. I have seen the same even during my MS course from one of the première institutes of India: this course has mandatory papers each for database, data mining and data warehousing for some godforsaken reason; as if software systems are just about writing database applications. The irony – Data Structures and Algorithms are rushed through in a single paper!

A major restructuring of both the course and the outlook towards engineering education is essential to produce computer engineers en masse who actually know what the subject stands for:

  • Basics first. Pay for faculties who have a good hold of the subjects they teach, enough to demonstrate practical applications of some of their significant aspects. Examples and explanations matter.
  • Keep the core subjects like Data Structures, Algorithms, Compiler Design, Computer Architecture compulsory. Make subjects rather loosely coupled with Computer Science and Engineering optional. In my experience I have seen many suckers who used to score huge numbers in those but couldn’t handle thread priorities even in the final year. Subjects like Mechanical Engineering and Workshop, Operations Research, Control Systems and Electrical Circuits should be optional. If a student is interested he will opt for it. Add more optional subjects like AI or Embedded Systems or Genetic Programming and even Game Design.
  • A programming language of choice (and still having relevance) should be compulsory in the first semester and make sure they can write a small daemon with it which can service asynchronous requests.
  • Give practical assignments and spread those throughout the year. Explain the assignments first. And oh yes, practical assignments do not mean develop a full game in a week’s time. It means RESEARCH and develop strong algorithms for any of the tricky aspects of it and implement it. When you teach object-oriented, ask them to break it into classes. Search Google and take a look at assignment papers from première institutes of the world.
  • Throughout these course years, interest them enough to keep themselves continuously busy with real and useful projects, not just semester results, like contributing in collaborative real projects going on. And award some credit at the end of the final year for that. As a start, once they are done with a programming language, give them the URL to SourceForge. Many of them would handle it themselves from there.
  • Each student is different. When you take money from each of them, it is your responsibility to find out their areas of interest. Yes, for each one of them. Put groups of students under each faculty from the first year to find it out. And order your faculty not to do politics with students to start a project under them around the third year. If a student is interested in creating web pages, help him nurture and cultivate his interest. He may one day come up with something like the Wikipedia. Show them the possibilities and encourage them to do what they love to do.
  • Stop encouraging them to join external coaching centres to learn .NET and JAVA. For true knowledge which they need, those are rotten useless tools. Read the third point above. They pay you to learn how to write those, not merely use.

I accept the reality: opportunities for good and real applications of Computer Engineering are very less in India and the huge number of students passing out each year makes it worse. When they graduate most students dream of doing amazing things but unfortunately they are not skilled enough and they are not strengthened enough to hold on to those dreams for long. Most of them adapt with maintaining decade old stagnant applications for years and lose interest in even trying something new or enhancing their existing skills (and I am not thinking paid ‘professional’ courses and interview preparations for switching) because the institutions fail to instill that interest in them at the right time. In most cases, their thirst for technology dies out in 2 years tops and this huge energy vanishes in the trivialities of technological oblivion.

Documentation for human beings

coffee_compI am not going to bore you with – you have a good product and an incomprehensible documentation… blah blah blah. Let’s talk about the case where you do have an excellent product and an excellent (at least that’s what your technical architect thinks) documentation to go along with it. The product sold reasonably well but then, all of a sudden, your developers keep getting bugs from the customers those are often invalid. To your surprise, things are actually explained as far as possible in the documents (I mean it literally). Your developers keep whispering to each other – don’t the customers read the documents?

I realized the problem when I was going through a document of a product. When the developers who wrote the software were working on the inputs for the document, they did their best and provided every possible detail to help out customers. However, the only thing they missed – the documentation was no longer humane. While that goes well with manuals for small utilities where the bulk is much lesser, it doesn’t play well with products.

Your customers are human beings and 90% of them will have no patience to keep reading through the document if you can’t keep them glued. Most people love to learn on the job as they have confidence on their technical capabilities. So they don’t like to read through hundreds of pages of documentation. And when there’s a mismatch between your developers’ reasoning and your customers’ expectation you have a new issue filed.

So how do you avoid it? First things first – don’t make your developers write the documentation. Robots can’t make love as a general rule. So don’t take the risk with your business at stake. Have some expert write it with inputs from them. Next, keep it a jolly document, not a huge list of DOs and DON’Ts. Another wrong notion is – corporate documents must be very formal. NO. Try being a bit informal, add light humor to it occasionally. Finally, try your own potion: make people in the organization read it – testers, other teams, busy managers… and have the feedback.

One of the manuals/documents I absolutely love is man top and I think it’s a great example of how documentation should be. Run quickly through it till the end and you will see what I mean.

A seasoned developer's nightmare!

coffee_compJust trying to recollect and put together some instances of hellish developer experiences – personal as well as of colleagues I’ve worked with. I will refer to Mr. X, (an accomplished and very senior developer with a high passion for quality work) to keep the mood light. Enjoy and add to the list!

  • 10 testers come with the same issue that got introduced last night (and was too easy to find) and Mr. X has to explain the same thing to all of them to the point they understand and agree. Sometimes it would be too difficult to simplify the technicalities. This has almost vanished nowadays due to advancements in bug-tracking systems – Mr. X just marks duplicates of the first issue and explains in a single place.
  • Some idiots who don’t understand their own modules try to dump their garbage in Mr. X’s bin. They won’t come with any analysis or logic, just guess-talk and assumptions. Basically they want the analysis to be done by Mr. X and gifted to them. Problem is, Mr. X’s time is much more important and he doesn’t wanna waste it.
  • Some member in Mr. X’s team can never handle his lot by himself. The guy wastes time of others (his doesn’t matter as his whole life was wasted the moment he chose programming as a career) and brings in issues every other day. If he fixes one issue, he adds 5 more.
  • After years of development, Mr. X tends to be choosy about the quality of the work he does. When his boss tells him to look into some install or update related issues ASAP, he freaks out.
  • A tester talks nonsense and tries to prioritize each and every issue he finds citing all sorts of trivial or hypothetical reasons. Mr. X tries to reason but is unable to convince in any logical way.

Fixing 'em bugs!

technicalWhile development needs a methodical approach and a good developer can always be in control of what he is coding, bug fixing in most cases appears to be a more dynamic activity. There are several reasons – the original code may have been written by someone who is not available, an unfamiliar component, non-reproducibility of the issue, vague or even lack of information, too much unrelated information, hard to meet deadline and the list goes on… However, in my experience of fixing (or killing) hundreds of software bugs I have seen that in most cases one can apply a methodical approach to fix issues.

1. Do not be afraid of bugs, or rather, code that seems obfuscated to you. If someone could write it, you are capable of understanding it. The only factors are time and honest effort. Some bugs need more than usual time and effort to understand in the first place. Put the word through to your boss stating the technical difficulty as you understood it. There’s no shame in taking time to fix a bug if you can build a confidence on your capabilities (through your track record) that you seldom fix the same bug twice.

2. Read through the problem statement multiple times till you understand the scenario. If you are not familiar, discuss in the team to understand what else you need to understand the scenario. Request to get the information and try to get it in one shot. In many cases, customers or testers get irritated when a developer asks repeatedly for different sets of logs, tests etc. Understand that they have their own work which is equally important to them as your work is to you. If feasible, ask for the original setup so that you can get what you want remotely and independently.

3. Once you are done with the scenario, now it’s the time for the analysis. There are two kinds of bug fixers – patchers and pros. Patchers look for quick solutions and are prone to break other things or leave behind related issues while fixing one thing. Pros fix all related issues once and for all. The best way to start is to identify which part of the code is related to the problem (the problem region). Then track back to the places where that code is invoked (fan-in) and understand why. Next go through the problem region, go through each line checking for the root cause and at the same time mapping is to your brain. If you find the root cause, great (and for most issues you will find it in this step, for example – condition misses, segfaults, wrong logic etc.); otherwise move on and get and idea of the fan-out of the problem region. Do this until you get the whole flow mapped to your brain. This exercise also helps you in saving time when the next bug in the same area comes and develops your understanding of the design of the whole product – issue by issue (in addition to the development you do).

4. Now it’s time to think. Start eliminating the fan-ins and fan-outs based on your observation of the logs and symptoms you checked in step 2. At one point of time you will be left with a subset from which you can’t eliminate anything. Time to get your hands dirty – add more logs, reproduce, use the debugger if needed and isolate the scenario. This needs patience, sometimes a lot!

5. Once step 4 is over, you know where your problem is. Now it’s time to think of code changes to fix it. Go back to the flows you understood in step 3 and think of the best possible solution that won’t have any side effect. Think on what else might need to be fixed along with the issue in hand. This judgment comes with experience. If not sure, discuss with your team. Make changes only when you are confident.

6. The fun is not over yet! You need to do your testing. Based on your analysis in step 3, think of the scenarios that you may need to test. Take your time, make a list and write them down. It’s often a great idea to add this list in your bug tracking tool before you change the status to FIXED. Test the scenarios. If you find time is insufficient to test the full list, take help of the tester involved in the issue or even the customer. In most cases they will be more than happy to help you when they know that you are doing your best. Once you are confident of your changes, check-in and post it.

Throughout this phase, be driven by a single motto – no problem should ever have to be solved twice (from How To Become A Hacker). This will give you enough energy to fix a bug the correct way – the pro way! In addition, as you keep fixing bugs your knowledge of the product design will keep increasing which will help you learn how to design as well as how to enhance weak designs.

Companies today: standards and ethics

coffee_compHaving worked with some truly global MNCs and being associated with many more due to work, collaborations etc. I have observed something which stands out – their standards and values. They remain strictly professional wrt. ethics and are earnest in creating an image which boosts global acceptance. They even adapt to the countries where they do business trying to learn their culture and endorsing products, services etc. accordingly. When employees are concerned, there are a set of guidelines which employees should strictly follow while acting officially.

Recently, there has been a surge in companies thriving on the web. And we see more and more sites allowing free speech and letting people express themselves. Many of these companies are not “huge” by revenue but they are popular. These companies thriving on mass popularity sometimes tend to change the very definition corporate standards. To become popular, they are sometimes officially encouraging nuisance. IMHO, it is grossly unprofessional and against corporate ethics. If you are giving a weapon to the masses, you are the one responsible to keep a check on whether they are using it in unethical ways. And if you can’t do that, at least don’t encourage it officially.

Today when checking my stats, I found an official Automattic post (under FROM OUR BLOG) which leads to a post “10 Things That Suck About Being a Guy”. Automatticans found it most interesting. Yes, not only 10, guys might have 100s of issues, everyone has. We go to consult the doctor and we go to psychologists and I can’t remember a single guy I knew in the past 29+ years who spoke to his “shrink” that way. This kind of expression may be OK for friendly banters, but not in public and definitely cannot be encouraged as an “interesting” blog by a technological organization of some reputation. I understand the target blog post in question is popular because there are many people out there who have the time to read and enjoy this kind of humour and the blog abounds in similar posts. But when you are a company, keep a tab on your quality and standards. How are we supposed to justify the selection of this entry – endorse anything that sells?

I am a vocal supporter of freedom of justified speech and knowledge but not the abuse of it. As they say – with great power comes great responsibility.