Advantages of working on Decent Code

I recently switched employers for the first time in my working career. After spending six and a half years with a huge (tens of thousands of employees) software services company I recently moved to a much smaller product company. After the initial few weeks getting acquainted, trained etcetera, I recently started hacking away at the code base. It came as a surprise to me that after three days spent adding enhancements to an existing (mostly Java) application I was no where near as stressed as I would have been in the past. I realised that this was mostly thanks to the decent code base that the application's developers had created in the first place. The code did nothing extraordinary; it was merely well structured, cleanly packaged and came with a good many automated tests. And boy, what a change it made. No need to spend days merely building the app; no more personal source code repositories (I have been forced to install CVS in my machine on several occasions in the past thanks to general ignorance about SCM tools).

The contrast with what I have been through while with my previous employer could not have been starker. I have worked in half a dozen 'legacy' applications for my previous employer and not once have I not been frustrated by poorly written code. Adding insult to injury were the indifferent "developers" who had created the monster in the first place.

The moral of the story is that good code goes a long way towards stress reduction and boosting employee happiness. Should I need to change jobs in the future, I will ask any potential employer to show me their existing code base. If the code sucks, I will politely bow out.

Speechless

First they ban Blogs. If that wasn't bad enough, the bureaucrats - who get paid by taxes people like me pay at the rate of 33%, deducted at source - have the temerity to say "We would like those people to come forward who access these (the 12) radical websites and please explain to us what are they missing from their lives in the absence of these sites."

You f~!@#$% morons! Ever read the 'Objectives Resolution' of the Indian Constitution? The part where it says that "All people of India shall be guaranteed and secured social, economic and political justice; equality of status and opportunities before law; and fundamental freedoms - of talk, expression, belief, faith, worship, vocation, association and action - subject to law and public morality"?

What would you babus propose next? Filter search results like our neighbour? I agree with Ravi Mohan. It is time to think about leaving.

Presenting 'Blog Packager'

• Are you a would-be 'insightful blogger' who has the ideas but just cannot get the right words to express them?
• Are you a would-be 'hot blogger' craving the attention of a thousand raving fans?
• Are you a would-be 'celebrity blogger' who craves publicity but cannot merit even a hyperlink?
• Are you a would-be 'blogger-columnist' aspiring for a multi-thousand dollar contract from WashingtonPost.com but just cannot get noticed?
• Are you a would-be 'blogger-turned-author-turned-screenwriter-turned-director'^**?

If you are, rejoice! Salvation is at hand. I am starting a new company, the first ever Blog Packager in the world. Join up, offer me your ideas and before you know, I will be signing a contract with Washington Times and you will be basking in the limelight.

** Blog Packager will only take you as far as step 1, i.e. blogger. You will have to rely on a "book packager" and possibly a "screenplay packager" and a "directorial packager" to go any further.

So what is the deal?

Simple.

• You, the aspiring blogger, will approach me with your ideas and USD 250 (or Rs. 10,000) as retainer.
• I will hire jobless experts related to your field from wherever they can be found.
• The experts will then add flesh and sinews to your idea skeleton, in the process internalising (and thoroughly obfuscating) the ideas from all the bloggers they can find using Google.
• I will sign a contract with the first party interested in the blog and offer you a percentage of the contract money.
• In case you are too ugly to be photographed, we will supply you with photos to use in the blog.
• You can write about anything under the Sun. However, our market surveys indicate that narratives of the experiences of a non resident Indian teenager are in demand right now.

Some conditions apply.

• If the venture flops, it is solely your fault.
• If the venture fails and nobody hears about it, you can try again by paying an additional retainer fee.
• If anybody alleges intellectual theft you alone will take the blame.
• My name, the company's name or the names of any staff members will not figure on any apologies that you might be required to make.
• Copy editing is forbidden. All materials we choose to show you (which is rare) will have to be used as-is.

********

In case you are wondering, this entry was sparked by an article in the New York Times on the recent 'Opal Mehta' fiasco. The following paragraph from the article caught my attention:

In a statement yesterday afternoon Michael Pietsch, senior vice president and publisher of Little, Brown, said the company would not publish the second book under its contract with Alloy Entertainment, the "book packager" that helped Ms. Viswanathan develop the concept for "Opal" and shape its first four chapters. Alloy, rather than Ms. Viswanathan, signed the contract, believed to be worth $500,000 for two books, with Little, Brown. (Italics added)

Taking the Joel Test

Recently I had a chance to read Joel Splosky's article 'The Joel Test: 12 Steps to Better Code' After reading through the article I took a few minutes to evaluate a software services company that I am familiar with using the 12 questions that constitute the test. I have reproduced the questions and my answers below.

Do you use source control? - No. Most projects that use source control tools do not use them the proper way. Archiving and taking back-ups is NOT Version Control.

Can you make a build in one step? - No.

Do you make daily builds? - No. Build process starts several days (or hours) before delivery. It starts 'offshore' and continues 'on-site'.

Do you have a bug database? - Not in all projects. In fact only a minority of the projects use any kind of bug tracker.

Do you fix bugs before writing new code? - No!

Do you have an up-to-date schedule? - Not really.

Do you have a spec? - Yes.

Do programmers have quiet working conditions? - No!

Do you use the best tools money can buy? - No. (Tools?! *Buy* tools? Are you crazy?)

Do you have testers? - Yes.

Do new candidates write code during their interview? - No! (Code?! Are you crazy?)

Do you do hallway usability testing? - What's that???? Oh you want an answer? Well, the answer is No.

According to Joel, A score of 12 is perfect, 11 is tolerable, but 10 or lower and you've got serious problems. The truth is that most software organizations are running with a score of 2 or 3, and they need serious help, because companies like Microsoft run at 12 full-time.

This particular company rated 2. It would rate 3 if I grudgingly treat a partial 'Yes' as a full 'Yes' for Question #4 (Bug Database).

Try this for yourself. Be honest. Look long and hard at the results. If you are employed in the Indian software services industry, you have permission to weep.

The Reverse Truck Factor

The speaker at a recent technology user group meeting introduced me to the concept of "Truck Factor" of software projects. The Truck Factor (TF) is defined as the number of people who would need to be hit by a Truck to seriously jeopardize the project. It is a measure of the number of people the project cannot do without; the higher the number the better. Interesting.

I quickly did a mental exercise to find out the TF for the projects that I have worked in. It dawned on me that not only was the TF very small, there was a Reverse Truck Factor (RTF) in play. I define RTF as the number of people who need to be hit by a truck (or several, just to be sure) for the project to stabilise and have anywhere near a decent chance of achieving what it is supposed to. The lower the RTF, the better are the chances of a project to succeed.

Unfortunately for me, the RTF has been consistently high in almost all the projects that I have worked in as part of the software "services" industry. With just one or two notable exceptions, Managers could always be counted while deriving the RTF.