My job is good too

This blog is our group blog. Sometimes, however, we beg to differ amongst ourselves. This is one of those times. I generally don't, as a rule, attack people for their opinions. At the end of the day, its after all, their opinions and its worth just 2 cents. Some things in the recent blogs here needs to be set straight. Here goes nothing:

I work with the best people in the industry. I wont justify that. I don't need to. I work on one of the most revolutionary products around in the industry in the product's field. Again, I cannot talk about it right now. I will soon though. I work in a team where the product manager is a hard core techie, the author of Frankenstein. The delivery manager and tech lead is the same person who can do both, while delivering stories! The senior developer is one of the best developers and more, thinkers I have had the pleasure to meet. Same goes to the tech lead. 2 remaining developers are senior to me and kick ass in technology - one, geek to the core, other, intellectually so. 2 QA's - both with more experience than others I have ever met, analytical in thinking, kick ass at their work.

Now, that was just for your information. In fact, each and every team in my company are like mine. Why do I even mention all these?

To build a revolutionary product or a company where all the best, not just in technology, in the world want to work is not an easy task. You cannot just attract them with money nor with just technology. However, the main reason I see people staying in my company is because THEY LOVE IT and THEY HATE IT. But isn't it obvious? You have to have both the feelings or else you will be bored. At least, I would be. I hate it because my company is not perfect. It is perfect for me. I wouldn't compromise on that. But it still isn't perfect. I would settle for nothing less from it, because, if not us who else?

There is this story about 2 workers building a wall for a temple. I am sure you remember the story. According to me, its obvious. I am sorry if I sound cocky, but its obvious that you need to understand that you are building the temple. If you are just following rules and doing what you are told, you cannot be the best. But I work with the best. The best can,
1) Build walls
2) Know that they are building a temple and
3) Build the temple finally

I think it is also done in the same order. Everyone who can think for themselves would be able to do (2). That's the part about having a big picture. To be able to do what I do day in and day out, to be able to work on each and every project we work on it is an implicit requirement that you understand the big picture. Nobody tells you what to do. You decide what is to be done. You and everyone else in the team. The thing that motivates everyone at where I work is that single idea of big picture.

I agree code is details and implementation. Someone has to do it. I believe in hats. I will explain the whole theory in some other blog, but for now, just think of each role as a hat. So, I analyze something wearing my "big pictures person" hat and implement it wearing my "developer" hat. Then show case it and sell the idea wearing my "marketing" hat. I am still one person doing different roles. I would rate myself good too. I may not be a great public speaker, but apart from that, I am pretty good at what I do. I know that was naive but was called for.

I think working on dinning tables is one of the best things ever. What you have to understand is you are given freedom. Nobody would eavesdrop on you. Also everyone you ever want to interact with, with respect to a project is around that table. Imagine removing all the cubicles and corner offices in your company and think of the whole of your team made to sit on dinning tables in a manner that makes sense. How many IM/Mails/Phone calls do you think you would save? And how much time? It may seem claustrophobic - completely lacking in privacy. But you cannot judge it unless you follow it. I, for one, have been in both kind of set up and have chosen my favorite. Don't you think you need to do the same before dissing either one of them?

We, in fact, do not care if you produce million dollar contracts, unless it is to our standards. If I were allowed to, I would have talked about our sales process. I am not. So, I wont brag about it.

We have been in the business from 16 years. We are not a publicly held company. I don't think that will ever happen to be honest. I would be very sad if it does and people at work know it and share the same feeling. We are truly employee owned. I am sure you can imagine why this is. We don't give a damn about quarter results. Actually we do. A lot. But I don't think we will ever do things so that our stocks would go up. We are way too egoistic for that. Also, most of us are green capitalists and socialists. I am the former.

I have a job which is currently perfect for me in a company which is truly the best in the overall sense. Hands down. ThoughtWorks is the best.

Frankenstein - Swing Testing Tool

I am a committer on the open source project Frankenstein. Its a swing testing tool. You can go through this presentation by Vivek Prahalad. You can also watch this talk at GTAC to see more about the tool.

The tool came into existence as a necessity on one of the projects at ThoughtWorks. Vivek had done the crux of getting the tool ready. Some cool features:

1) Testing mutli-threaded Swing App without a need for explicit waits due to threading.
2) Identifying all basic components present in AWT, both for playback and recording.,
3) Ability to record and playback both in Ruby as well as Java.
4) Ability to test applets.
5) A fall back naming strategy to identify controls which aren't named appropriately.
6) Assertion API in the driver interface for Thread Safe assertions.

The most important among these which makes tests from being flaky is the implicit waits. One needs to follow a naming convention, which can be obtained from the doc, when naming their Worker Threads which carry out some operation in the background and Frankenstein monitors these threads and waits till they are done. This means there is no need for explicitly adding sleeps in your Swing test code which otherwise makes test very flaky.

One thing to keep in mind is that Frankenstein uses AWT Robot. So, one has to keep the application in focus for the components to be identified.

Currently, I am working on the ability to remotely drive Frankenstein through Java. Frankenstein takes care of bootstrapping your Swing application which means both the testing tool and the application under test will be in the same process. Sometimes, for various reasons you may want the test itself to run in a different process. This is how the Ruby Driver works by default.

If you are interested to know more about this, leave a comment here. Do visit the OpenQA forum. Vivek or I will indeed answer any queries you may have.

Random Newbie Stuff

This post is strictly for people who have just entered into the software profession. I have jotted down some random things that I have faced myself or seen other people do wrong here. The solutions may seem to be pure common sense or banal, but I take that risk of being obvious because I know a lot of people who lack common-sense.

When I was coding in Fortran and C just to get something working, first days as a programmer, I never bothered about anything. I just wanted to get something done, by hook or by crook. Then, after joining a formal course on Computers, I had this notion of a good programmer being someone who spews out code which works on the first go. No errors, compiler or otherwise. Just works. Now, when I recollect what I used to think in those days, I almost feel its so lame that I shouldn't admit to it. But then, you learn soon after shooting yourself in the foot enough number of times that its just not worth it. You have to start coding and face the problems as they come. What I have found out over the years is that it is not only insane to try to write error-free code without actually coding, but also totally unproductive! I agree that human brain is a marvelous thing, but why waste it on stuff which a computer is kick-ass in doing. Don't sweat a lot about syntax and stuff. You anyway have Google, if nothing else. I suggest you, of course, learn the syntax and stuff, but there is no need to memorize it, like a lot of people I know try to do. You will remember stuff if they are important enough. Others, you can always look them up.

A lot of people like to talk about high level, abstract, potential "solution" to a lot of problems. They think and analyze for a long time and fear getting their hands wet. I know I used to do it and I know people who still do. All I can say is that its sheer "balls". You cannot just talk about problems. You have to get down to code at sometime and actually solve them.

Something I have found out is people don't learn the right things at the right time. If you are learning Java, there are reasons why you should, I would suggest you start from the command line and go through the Java classpath hell before you start doing stuff in an IDE like Eclipse or IntelliJ. You need to know how things work under the covers, irrespective of what it is that you are learning.

Something that boggles people down is the size of a code base, either when they join a project middle way or when they have to understand how something works. One thing you need to understand is that it is written in a language, I assume, that you understand. Just think of it as a novel or a text book that you need to read. The chances are you cant digest everything that is there in a day or even in a week. Just like reading a book, you need to start from the beginning, logical i.e., and then move deep into the code base. You will surely finish it, sooner or later! Just like a book, some code appeals to you and some don't. Its up to to you if you really want to work with some code or not. You can always do this. Or bail out.

A few things that I can think of which are done blatantly wrong and which can be fixed easily, with some mental effort.

Redesign the World

As a professional programmer, one of the things I constantly crib about is the fact that NOTHING fits my current requirements. No single tool, no open source library, no neat application, no nothing. I just get frustrated. Something that I want is automation. I don't want to be bothered with repeating something more than twice. I get all pissed because I have to do it. If its repetitive a computer got to do it. Why in the hell would I want to waste my time and effort??

Sometime back we were using Antlr as a Parser on our project. Given the simplicity of our grammar, we thought Antlr would be a perfect fit. But turns out, it was not! It was so painful that we replaced it with a hand written parser in about a day. With complete test coverage.

Given this attitude of "Redesign the one tends to redo a whole lot of things. The most important thing to keep in mind when you want to replace something that already exists and is very irritating is that it solves the problem. Doesn't matter if its not done well, if its slow etc etc. Because the chances are, by the time you reach where that tool/library is, you would have inadvertently ended up making some compromises or hacks every now and then yourself. Unless of course, there is a very strong reason such as the project productivity/velocity is getting screwed etc. to replace the tool.

What's more important is to be wary of what I call the "Quick-Win" syndrome. When you want to replace, lets say, Cruise Control or Selenium RC, its easy to get carried away thinking, "Its just a freaking while loop" and start off. The chances are you will get the basics quiet right, in fact may be better. But there are so many corner cases and issues that something like CC takes care of which were shielded from you that you just wont be able to "hack it" away to glory in a weekend. You will get a quick win in the sense that it works perfectly well in the happy path and feels Oh-so-close-now to the solution that you wont be prepared to give up until the contrived corner cases start biting you. But its just normal that you think its just one of those things or lets just hack this one away quickly which ends up in something "enterprise" like Selenium RC.

All I am saying is, when you want to replace something once and for all, don't think of it as a weekend hackday thing. Especially if its something big. So, take your time and make some wise decisions before starting off.

Mundane Problems

I have an IOC container with some beans which are listeners. I have a POJO which is in itself a listener to some events. I want to notify my beans when the POJO gets notified of some event. But, because of some intricacies in how my container works into which I won't go, I have to get the list of all beans only at the time when my POJO gets notified. Kapeesh?

Well now the problem is I can hack my way out of this by passing an instance of the IOC container to my listener which will then get a list of all the listener beans in it and notify it away to glory. But then, my POJO now needs to know about an IOC! Damn. So, I won't want to do this. This is how we solved it:

We created an interface which provides the listener beans to anyone who wants to notify them. Then injected this interface to the POJO. This is how it looked:

public interface BeanListenerProvider {

   List getBeanListeners();

}

public class POJO implements SomeListener {

  public POJO(BeanListenerProvider listenerProvider) {
      this.listenerProvider = listenerProvider;
  }

  public void getNotified(SomeEvent event) {
      //Do Anything...
      foreach (BeanListener listener : listenerProvider.getBeanListeners()) {
          listener.notify(new AnotherEvent());
      }
  }
  //Whatever follows...
}

The good thing about this is that I now have the POJO decoupled from my container. This may be a rookie thing to do but it is easily lost when you are working on a Friday afternoon after working a lot with Eclipse code base. This led to an interesting conversation with Hakan, my teammate, about being a pragmatic coder as against being an idealist coder.

A lot of problems are mundane. Its only what you do to solve them in a clean way is going to make your work interesting. A clean code indeed gives one a kind of satisfaction which nothing can beat. OK, may be sex, but that's about it.

Code Poetry

When you listen to good music, anything that you perceive is soothing or whatever qualifies music as good to you, you will feel a sense of satisfaction. Even though the music itself is not yours, you can always enjoy it. Ever read a piece of article which is crisp, to the point and yet drives the point in such an affirmative way that you are just happy that there are people who write without bull-shitting? Then there are the sculptures, the paintings and a whole lot of other arts which require an artist to create them but even more, people who appreciate the art itself. I am going to write about a form of art which is lost among a lot of people. The art of writing code, the cosmetics of it rather. Some of the key things to keep in mind if you want to write code that appears like poetry:

* One thing I think is the key to art is that there should be nothing redundant in the your work. It kills the genius behind the art itself. In the same way, there is no place for something which has no purpose in your code. Get rid of those variables and fields which you have because you think they may be useful in the future. Get rid of private/helper methods which are not used anymore. They are like random noise in a symphony.

* Claustrophobia is not something that only humans suffer from. You can't expect to write "The Prey" by Michael Crichton in 3 pages and expect people to read the whole thing. At the same time, I won't read a 10,000 page version of "The Prey" either. I enjoyed reading the 400-odd paged version thoroughly. The content mattered only after the spacing was properly. So, keep in mind to leave spaces as required by the conventions of the language that you are using. Like a space after an "if" and before the start of the parenthesis of the condition in Java, etc. When you write code, don't be prodigal in leaving white spaces and empty lines. They don't add value. They are a distraction. More often than not, people wonder as to why there is a new line and if they missed some logical separation marked by the demarcation. Follow the conventions all the time and be bold only when the situation calls for "dire" measures, and even that only when it comes to leaving a new line.

* Don't initialize local variables on one line and use it in the next line alone and nowhere else. You don't need such variables. For example:

int length = someList.size();
doSomething(length);

Here, there is no need for you to use 'length'. In fact, I would argue that the intent is much clearer when you write something like:

doSomething(someList.size());

Here you know, without an extra level on indirection that you are "doing something" with the size of the list. Traditionally, having a lot of variables was advised because function calls were very costly. But there is such an advancement in processors and compilers that there is virtually no difference between using a variable and a getter method of the variable. Given this, I would write something like this:

foreach(String name : getNames()) {
//whatever
}

This is a nice way to write "for each" statements without using local variables for the lists/arrays and you will appreciate it once you start using it.

* If you are programming, say in Java, make sure you choose an order in which you want to import stuff, so that it is consistent over the whole of your project. This keeps things neatly. For example, I would have all the bundled java classes be imported first. Then other stuff which are, say, javax stuff. Then I would import stuff which are from my project. This way when I, say, create a patch between my older version of a file and a newer version, I can be sure that if there is a change in the import, its because of a change in the code that affected it and not the order in which stuff are imported. In fact, I think this is a really important code cosmetic if you are using code versioning.

* Try avoiding the use of comments for private methods and variables and instead use a name which suggests what it does. The use of a good name is something that is emphasized the most by almost everyone but is something which is either not leveraged or abused beyond any use. Don't keep a constraint on how long the name should be. At the same time avoid using articles like 'a' and 'the' and try making the method sound like a sentence when it is read with the argument that is sent to it.

Most of the stuff here are in fact built into IDEs for the language you use. The options to do these may be obscure or obvious, based on the quality of the IDE itself. Its important to use them to write clean code.

These are some of the things that I think which makes a code appear clean and pure, like an art. I have seen some seasoned OO programmers who use these rules and many others and just to see them spew the code out is like watching someone paint. And the code itself reads like poetry.

Hacking

I know the media has hyped up the word "Hack" and "Hacker" so much and so bad that the true meaning of the words are lost among the masses. But what really ticks me off is that even a lot of people in the industry think I "broke" into a website or some network where I am not supposed to go and got my work done when I say, "I hacked my way around this stubborn problem". Illegally. Yeah, right, if I were a "Black Hat" I wouldn't dare write stuff with my identity so blatantly given away!

So, here's what Hacking means - HACK
And here's what Hacker means - HACKER
And the actual word which stands for "hacking" as people conceive is - CRACKER

I hope this makes a difference. Thank You.