.Net blog of Sijin Joseph

Maybe the salary theorem will shed some light on the matter.

Death of the command line - A.P Lawerence puts down his thoughts on the command line. Frankly my head is so full of other CS stuff that I could barely fit in command lines and their arguments. Command line tools tend to be less discoverable and need constant reinforcement to remember than the GUI counterparts simply because you can see what can be done if the GUI is designed properly. But when it comes to automation and chaining tools together nothing beats command line tools.

I have been using WinDirStat for quite some time now to visualize my hard disk usage and to clean up when disk space was low.

But it was just yesterday that I realized that the cool visualization that is used by WinDirStat actually has a name "Treemaps" and has a lot of interesting history behind it.

I recently moved into my new house and wanted to setup a wireless LAN for my home. So I read through some sites on how to setup a wireless LAN and for the router I decided to buy the Linksys WRT45GS.

Patrick has released version 2.0 of his absolutely cool code analyzer NDepend .The VisualNDepend tool is looking slick and Code Query Lanaguage looks damn interesting. Also be sure to take a look at the metrics that are generated by NDepend, very nice.

Also while you're at the site be sure to check out his excellent and very well written book Practical .Net and C# 2.0

I've been managing a small team for the past 6 months now, when I was just a developer I always used to wonder why is that people who manage people get paid more than people that actually build the product and bring in the moolah. Ideally pay should be directly proportional to difficulty of task. If that's the case let's compare the relative efforts involved in programming vs. management. Since we developers understand programming very well, let us try and think of management as a programming activity where people are analogous to computers, getting a computer or group of computers to do what you want if similar to managing and getting work done from a person or a group of people. The dominant language style is different in both worlds, computer languages are dominated by imperative languages which require explicit instructions on how to do a particular task, whereas people programming is dominated by declarative(SQL like) languages where only the intent of the task is provided and not the actual steps.

When you don't have experience with managing people it's hard to imagine why people programming is hard, after all humans are logical and intelligent entities(with some exceptions - http://www.darwinawards.com/) capable of making their own decisions and carrying out tasks based on just the expected outcome, sweet!! this is Object-Oriented utopia. Compared to computers which need to be told in very explicit terms what to do programming people should be a walk in the park.

Once you start managing people you realize that things are not so rosy, to put this in perspective, lets imagine that we were to design programs for a new set of computers that had human like qualities, here are some issues off the top of my head that you would face in programming this new breed of computers

- You could never predict the output for any given input, the output would be different on each machine and it would be a function of

    1. Past programs -  knowledge, experience, culture, ethics, attitude etc.
    2. Physical conditions - physical health, fatigue etc.
    3. Mental conditions - stress, family issues, inter-personal issues

ThoughtWorks India had held a Master Class on Agile development in Bangalore on 8th April, the highlight of the talks was obviously Martin Fowler and the reason I think most of the attendees had come. It was held at the Taj West End hotel on Race course road.

The agenda for the talks where
1. SOA
2. Talk by Martin Fowler on Agile development
3. Cruise Control

The session on SOA was good although there was nothing new if you've been tuned into the hype surrounding SOA. The only additional thing I was able to learn was the difference between RPC and Document style web service calls. In RPC style of communication it's just as if you're making a method call by passing the name of the method and it's arguments, whereas in document style you just pass the information and the desired operation in the form of an XML document, the actual mapping of the operation to the underlying method is abstracted away.

Then came the most interesting bit that everyone had been waiting for, Martin Fowler himself. He is quite tall and is an excellent speaker. Interestingly he does not use powerpoints for his talks, rather he keeps an index card on which he seems to have a rough outline of what he wants to talk about. Also he walk on the stage from left to right and the audience gaze obviously follows him, it's like the audience is watching a tennis match slowed down 20x times :D

So he started of by talking about the Agile manifesto and that it never talks about testing as a corenerstone of Agile as many may think, also he said that tools are given secondary importance in the manifesto but in reality they have a kind of inter-dependency wherein the tools affect the processes and vice-versa.

He took a side track and talked about the how the agile ideas sprang from mostly smalltalkers and because of their unique environment where they could be inside the system and tweak things from the inside they got into the habit of trying something and tweaking etc. This philosophy of not doing a Big Design Up Front(BDUF) but rather taking an iterative approach to software development eventually gave rise to the ideas found in Agile development.

Coming back to the tools he talked about Ruby on Rails(RoR) and how it's "convention over configuration" approach basically says that this is the kind of problems we solve and if it does not suit you then this is not the right tool for you. He went on to say that harnessed frameworks like RoR were much more effective than big designed frameworks, he cited the example of EJB 3.0 looking a lot like Spring.

Also while on the topic of tools he said that it's very difficult to develop frameworks when you are not going to the end user, and which is why software developed by organizations that do not actually use the products tend to be of lower quality, the example he cited in this case was Rational. One company that he said did make good software for software developers is JetBrains.

He did talk a lot more about tools but I can't remember any of it after a week. But overall it's amazing the kind of talk that he delivered, I think he had just thought of the things he was speaking about on the plane, it was very spontaneous.

Then came the questions, one guy who seemed to be particularly interested in showing himself off came up with two really stupid questions that did not make sense at all and Martin Folwer just said that he could not understand the question at all. This really shows a big cultural difference between India and US. In India this kind of candor would have been considered rude but not in US. Which is totally great, that guy truly deserved what he got :)

We took a break for lunch and I could not ask Martin Folwer my questions as we had run out of time, but I saw him sitting alone a little later and went up to talk to him. First I asked him something that has bothered me a lot, testing GUI intensive apps, for simple data entry screens there is hope via the techniques described in "The humble dialog box" but for other class of apps like photoshop etc. there is little available knowledge. Martin Fowler was not much help either he just said that he would have to take a look at my app in more detail (typical consultant answer me thinks :))

Next questions I asked him was how long it takes for him to write on of his articles as I've always been amazed at the amount of good thoughts that go into his articles. He said that he had no idea as he did not keep good track of his time. Strange!

As a person I think Martin Fowler is a great thinker and he's got an amazing experience in developing enterprise apps. I also suspect that he is a good programmer despite his claims otherwise :) The only negative trait in his personality is I think his arrogance (I didn't interact with him much at all but that's what I got from what little I did)

The session on cruise control was quite boring for me
1. It was post lunch
2. I had already done all that before, so there was nothing new.

One thing that was pretty apparent is that ThoughtWorks is no exception to the general quality of developers
i.e. few stars, mostly mediocre and few bad apples as well. So I guess everybody needs to learn to work with the mediocre programmers as well and it's a utopian vision to expect an all star team.

When working with SQL Server it is easy to get access to database metadata like tables, stored procedures etc, by using the sys* tables. I was doing some work with Access and wanted to do something similar, turns out that it is quite easy to do.

Basically the OleDbCommand.GetOleDbSchemaTable() method allows you to get as much metadata you want about the DB.

Pretty obscure but a God send when you really need it :)