Talking with a Lisp

I may be going out on a limb here folks but bear with me – the situation lends itself to such a treatment. As a disclaimer, all proprietary and personal pointers have been duly elided to protect the privacy of the parties involved. This should not be misconstrued as a mere rant. It is not. This should be viewed as the exasperated response of a technologist who’s had it with these pseudo-managerial passive-aggressive type weirdos who shamelessly flaunt their lack of tact and the distasteful overindulgence in wannabe corporate-speak but which ultimately strangulates them in a pile of meaningless rhetoric and makes them appear like a PHB fanboi. It is. Trust me.

I believe a bit of information about the parties involved would be highly useful. Let’s start with me. I am a technologist (ain’t that classy-sounding?) who loves to code and who believes undue processes only hamper the simple, beautiful and elegant flow of the whole software cycle. Not that I am against all processes – I’ll gladly eschew them till I take reins as a manager myself (in a “proper” management-oriented company, not any software company). Call me ‘z0ltan’. Then there is this colleague who does programming because it is part of the job. Duh! Moreover, she fancies herself as a future manager par excellence (well, in the spite department she is already there!) and thereby has more faux pas than Dilbert’s boss on a bad hair day. Oh, by the way, she has ‘over’ three years experience more than I do (gosh!). Let’s just refer to her as ‘Wannabe’. That brings us to the third and youngest actor – a fresh, impressionable and totally stubborn ‘n00b’. That sounds fine. Finally, there’s ‘Gandalf’, the venerable and highly experienced technical lead. There you go, onto the play itself!

Title: Wherefore thy aggression whilst I prefer thy passion?
( A play in three parts )

Act I, Scene 1 – The n00b asks for information. Innocent enough.

From: n00b
Sent: Thursday, June 26, 2008 9:01 AM
To: z0ltan
Cc: Gandalf);n00b
Subject: Regarding VMWare GUI

n00b

Act I, Scene 2 – z0ltan responds with the requested information.

From: z0ltan
Sent: Thursday, June 26, 2008 9:10 AM
To: n00b
Cc: Gandalf, n00b
Subject: RE: Regarding VMWare GUI

Act I, Scene 3 – n00b responds.

From: n00b
Sent: Thursday, June 26, 2008 9:59 AM
To: z0ltan
Cc: Gandalf, n00b
Subject: RE: Regarding VMWare GUI

n00b.

Act II, Scene 1 – Wannabe jumps into the fray

From:n00b
Sent: Thursday, June 26, 2008 4:04 PM
To: n00b; z0ltan
Cc: Gandalf)
Subject: RE: Regarding VMWare GUI

Act II, Scene 2 – z0ltan responds to passive-aggressive thrust by Wannabe in similar satiro-sarcastic tone.

From: z0ltan
Sent: Thursday, June 26, 2008 4:28 PM
To:n00b; n00b
Cc: Gandalf)
Subject: RE: Regarding VMWare GUI

Act III, Scene 1 – Gandalf jumps in and shows real tact in dissoluting the tension with a simple, direct approach.

Thanks everyone for sharing your views. I see a communication gap here. Let us fix this issue here itself.If you remember, we used to work on the common branch and with that we never had any issues. I think n00b can adapt to that. Since z0ltan is still developing it may not be very stable.But she can proceed with her work and if there are any issues we can fix it.

Gandalf

Closing comments:

The interesting part is this – If I look back now and read through this blog and compare my emotional response to the one I had when the incident occurred first, I am amazed at the difference that I see in my own judgements. At this moment, I would not consider the situation as horribly messed up as I had felt at that time. One reason is the passage of time and the change in conditions. Apart from this, for the reader, the context might be lost to a great extent. So before anyone goes “Oh! This is no big deal! Just a simple exchange of formal intra-team communication”, I would like to put things in perspective. Here we go:

Imagine yourself being given a considerable amount of responsibility in the upcoming release of the product. Say that responsibility is supporting your product on the VMware Enterprise Server platform. To have an even rummier time, consider that your product is not exactly amenable to conglomerating with such drastically different architectural models. Also assume that you have given prior notice to the team on the amount of effort and time it will entail (safely downplayed by the technical lead as well as management). Being the young, restless and bring-it-on kind of programmer (after all, the second youngest in the whole team!) you take up the challenge and work your backside off for a couple of months and ultimately prove through a POC (Proof of Concept) that the whole shenanigan will work after all (one reason why the technical lead did not take up the task himself was because he was certain it was not feasible!), you are faced with the task of integrating your code with the team product. Again, in a Dilbert-esque fashion, your estimation of the coding and testing effort is downplayed by the whole senior players in the team. Worst of all, you have to depend on the GUI (Graphical User Interface) team (read Wannabe, n00b) who are loathe to start work on it until the last minute. Again consider that Wannabe brings up her own confabulated Design best-practise (‘The Business Logic (Server) should decree the structure of the GUI(frontend)’) whereas even to a relatively new programmer like me (perhaps I need to be grateful that it is so?) it should be the GUI driving the design of the Server. The unkindest cut of all is that Wannabe is someone who, while I am hardpressed to take even a day off, barely makes it to office twice a week. Twice. No questions asked, no reasons given. Need I say anymore than this – scroll up and read the whole play again and if does not make any sense to you, probably you should not be reading beyond this line anyway!

Respect!

Feynman has often been described as a raconteur and I am sure he deserves that epithet without me justifying it or otherwise. The reason he was called so was because of his extremely direct manner of explaining, in the simplest of terms, some of the most complex concepts of advanced physics. His video lecture series was one of those myriad events which further reinforced his stature as a clear-headed genius. Now, that is not as trivial as it may seem at first. In my opinion, and arguably in an objective sense as well, the true measure of genuine understanding of any subject is the ability to express it without equivocation or self-doubt. No doubt eloquence, directness of approach and pithiness are characteristics which are often innate (and cultivable to a great extent through practice) but these attributes notwithstanding, the skill to present the matter at hand in a fluid and intelligible manner – caressing the topic with the confidence and prowess of a professional and actually putting forth all the salient points without diluting the content, is true raconteurism. Feynman was adept at that but recently I discovered another genius who actually surpasses him in this regard. Come forth, Joshua Bloch!

To the true technologist, Joshua Bloch requires no further introduction. He is the master and creator of the Java Collections framework (which is one of the finest components of the Java platform), the java.lang.Math package, the ‘assert’ mechanism (amongst others) and indeed has gone on to greater stature and achivements as Principal Engineer (with special emphasis on being the Java guru in-house) at Google. I had heard of him before through his publications such as Effective Java, Java Puzzlers and Concurrency in Java and yet had never had the inclination (call it laziness if you will) to actually read past the titles. The thought that came to my mind was “Yet another Java book… how many of these darned things am I supposed to read before I actually master this constantly mutating platform?”. This bring to mind another powerful concept that made sense to me long after I had been exposed to it. It is called the ‘Paradox of choice’. The video is available here. It is an excellent talk by Barry Schwartz. Quite non-technical but I feel it has begun to be more pertinent to this industry than any other (and will only continue to be more so!). As it so happened, one lazy afternoon when I was casually browsing through some Google Techtalks online, I came across this rather innocuous sounding title – “How to design a good API and why it matters”. It would be a whole six months before I would watch that video!

When I finished watching that hour of pure technological operatic genius, my first reaction was that of dejection. Yes, dejection at seeing the video end so soon! The whole hour had gone off so smoothly and everything in the meantime just made such clear sense that it was nothing short of amazing. I had been deeply engrossed in some major coding work in my current project and wished that I had seen this video two months back! Uncannily though, I discovered, to my own smug contentment, that I had already followed most of the principles that were enunciated in the talk. Some of the pertinent points that he puts forth are as follows and struck me as particularly useful are as follows:

1. Whenever in doubt, leave it out!

This makes perfect sense. As he says, every programmer who develops at least a module is an
API developer because the methods and the public components of his module form the contract
for any clients that actually use his module. This maxim follows the logic that a component can
be added to an API later on, but can never be removed without breaking
existing functionality.This also implies that any ‘doubtful’ functionality can always be harnessed
on later.

2. The ideal size for a method paramater list is three or lesser. If there are more, split
them and/or use helper classes

The example that he provides (of a Win32 API call to draw a simple window) in the video says it
all. I found this principle very useful (in retrospect) when I was designing my modules (I will
have a series of blogs on that very soon) and was often in a bit of a quandary about the exact
scope of my utility methods. The requirements at that point of time were pretty
much solidified and yet the use-cases were not yet finalized. So it was more of a trade-off
between usability and genericity which leads us straight to the next
point.

3. If the API makes everyone equally happy and leaves everyone equally unsatisfied,
it’s done its job

It’s always a tight balance when designing an API – whether to make it extremely powerful (and
invariably for a select group of stakeholders) or to make it powerful enough (and
thus for the majority of the stakeholders). The latter is always preferred irrespective of the
scope of the applicability of the API. The case which is moot in this regard is the VMware API -
generic enough to be almost bloated and yet powerful enough to be used by any client. More
on the VMware APIs in upcoming weeks.

4. Exception handling is not just an escape mechanism but a means of controlling
the system flow

Now this is one part of the talk where Joshua could not allocate any time at all. Considering
that the whole hour-long talk was filled with absolutely no pauses and no wastage of time, this
goes to show how the topic deserved more time than the standard hour allocated for Google
Techtalks. Nonetheless, in my current project, this was the hardest nut to crack. Exception
handling is an even finer balancing act than the design of the contract of the modules (i.e., the
methods) as there is a huge state-space of possible control flow/ processing paths. The sad
truth is that this is often the part which is most often neglected. I, however tried to have a
fairly robust and generic mechanism whereby there was a Exception class
with a corresponding ERROR code interface, which was placed in a common module so as
to allow clients to access and throw specific error codes. The level of granularity is still being
refined as I find more use-cases and corner-cases. In my opinionated opinion, the design
of the exception handling mechanism is the true measure of good or bad design.

5. Document! Document! Document!

Joshua recommends documenting every class (what an instance of it represents), every method
(this forms the contract of the class after all!), every parameter and return type (mentioning the
types and units of the parameters). How important this is can be estimated by this
example – In my current project, I have over 400, 000 lines of Java code modularized into a
dozen projects and hundreds of packages and sub-modules. The real eye-opener is that there is
absolutely no documentation whatsover. Okay, that sounded harsh. Let me rephrase it thus -
There is not a single line of useful documentation. If it were not for my considerable
intellectual gifts and a generally consistent design, it would be impossible to decipher the whole
mish-mash much less augment the functionality!

6. Watch the video paisan!

In closing, I could go on about how profound my experience was watching this video and I could ramble on about about the merits of the whole experience (gosh, it’s almost sounding like I had a technological seance… which wouldn’t be far from the truth! ) but this post has already gone on too long and I am tired! Just kidding… I am busy in my epiphanic reading of ‘Effective Java’, ‘Java Puzzlers’ and ‘Concurrent Programming in Java’. Peace!

So here I am, victorious at last after two agonizing days of waging battle against what seems trivial in hindsight (and is indeed trivial in truth!). Two whole days of flirting with a simple logically illogical mess created by, surprisingly, not SQL but by my official tool and favorite punch-bag, Java!

This just goes to show that the more banal the bug, the more anguish and torment that it causes! In the end, the problem turned out to be so ridiculously obvious (again, in hindsight) that I wonder if this indeed even wtwtf! … Well, I cannot recover those two days of wasted effort (well, actually partially wasted as I did a lot of bypassing around it and could well afford to, since I am working on a huge feature for my product) but I can  at least try and salvage some honor from this humbling experience. Here is the code snippet (redacted for reasons twofold – proprietary software and ease of reading. The spirit of the mind-numbingly irksome bug still remains) :

import java.sql.Connection;
import java.sql.PreparedStatement;
import java.sql.SQLException;
import java.sql.DriverManager;

public class StructuredQuirkyLanguage {

	public static final String VMSERVER_TABLE_NAME = "VMServer";
	public static final int VMSERVER_ID = 0;
	public static final int ENCRYPTED_CREDENTIALS = 1;
	public static final String[] vmServerColNames = { "id",
			"encrypted_credentials" };

	public static void main(String args[]) {

		String tableName = VMSERVER_TABLE_NAME;
		String columnName = vmServerColNames[VMSERVER_ID];
		String updateColumnName = vmServerColNames[ENCRYPTED_CREDENTIALS];

		String encryptedCredentials = "3C8C537B6F88501F";
		String vmServerSystemIdString = "cba73408-261f-47c8-9e15-83f1c4c74598";

		encryptedCredentials = "\'" + encryptedCredentials + "\'";
		vmServerSystemIdString = "\'" + vmServerSystemIdString + "\'";

		String updateSql = "update " + tableName + " set " + columnName + " = "
				+ encryptedCredentials + " where " + updateColumnName + " = "
				+ vmServerSystemIdString + ";";
       try {
		 Class.forName("solid.jdbc.SolidDriver");
       } catch (ClassNotFoundException cnfex) {
    	   cnfex.printStackTrace();
    	   System.exit(-1);
       }

		String databaseUrl = "jdbc:solid//localhost:1315";
		String username = "dba";
		String password = "dba";

		Connection connection = null;
		PreparedStatement stmt = null;
		int numRows = 0;

		try {

			connection = DriverManager.getConnection(databaseUrl, username,
					password);
			stmt = connection.prepareStatement(updateSql);

			numRows = stmt.executeUpdate();

			if (numRows != 1) {
				throw new SQLException("Could not update the database");
			}

			connection.commit();

		} catch (SQLException sqlex) {
			sqlex.printStackTrace();
		} finally {
			if (connection != null) {
				try {
					connection.close();
				} catch (SQLException sqlex) {
					sqlex.printStackTrace();
				}
			}

		}
	}
}

So let it be known that that was the last and final humiliation of z0ltan by anything lesser than z0ltan…. well, at least till next monday!

Fist!

(Note: The real wtf could be that you could fall for the same trap! See if you can find the problem. And oh yeah, the error dump wasn’t very helpful either -
[SOLID Table Error 13037]: Illegal DOUBLE PREC constant

Happy? HOHOHOHOHOHOHOHOHOHOHOHOHOHOHOHOHOHOHOHOHOHOHOHOHOHOHOHOHOHOHOHOHO

*wtwtf = worse than ‘worse than failure’!!! You saw that one coming, didn’t you?