The perils of Java companies

Joel Spolsky writes on the perils of Java schools.Read it. It is an excellent article.

Now dwell on the fact that many of the same conclusions could apply to you if you have never developed a piece of software in a language other than Java or C#. Have you ever created a 5000 line + program in a language other than Java/C#? Do you know (as in wrote some decent programs in) any paradigms other than OO? Do you really know OO? (If you've learned only Java you probably don't). Do you work in a Java(C#) company?

With a new year dawning, it is a good time to make a resolution to improve your programming skills. Alternatively you could just "climb the ladder" and slump into "project management" or "iso/cmm".

Year End Retrospective

Over the last year or so, I have worked alone. This was a nice change from being part of a "globally distributed team", attending stand up (and other) meetings, endless 'pairing' sessions, and other "agile" practices.

As the year draws to an end, I think it maybe worthwhile to explore and clarify what I learned and how I changed.

First, I am now utterly disgusted with 'off shored enterprise' coding. I was never really comfortable with the bland projects that wash ashore in this domain. Too often the projects were utterly boring, in spite of working with some of the best companies and people. The last year has been fantastic in terms of the challenge and complexity of programming and I hope I never have to work on a leasing/banking/insurance/blah database-to-web-and-back, C#-or-java, offshored-to-save-money-by-hiring-tonnes-of-cheap-coding_bodies project in my life again! So help me God!

Second, working on some extremely tough problems have taught me to tone down my enthusiasm for (a) "OO" and (b) "agile". Don't get me wrong, there is much that is valuable in both but these days I see their limits with painful clarity. Now, I see Objects as one (vs the only) way to tackle a problem and while I still follow some of the agile practices (like unit testing and Continous Integration), I am very skeptical of the value of "pairing" etc, outside the simplicities of the "enterprise app" domain.

Third, I am now very focussed on three major themes - (a)learning to create "tough" programs(kernel hacking is tough, creating a normal insurance app in j2ee is not), (b) applying "deep theory" to practical ends (applying Bayesian Classification to spam filtering vs design pattens/mock objects/what have you in a standard business app) and (c) working towards being *really* good at programming, in global terms (and not just be another cheap Indian offshore programmer, or even worse , manager).

More concretely, in the coming year I plan to deepen my knowledge of AI and Compilers and also learn to hack hardware,besides acquiring more mathematical understanding.

2006 looks glorious! Happy New Year all.

Update: Thanks to Teju's comment, I've thought about this a little more.Here is a quick checklist of questions

1. Is your project interesting? Do you feel exhilarated or bored when working on your project?
2. Are the people on your project there because of their expertise or are they there to increase billing? If you left the project would it be hard or easy to replace you? How unique are your skills?
3. Do you learn new things every day or do you just do the same things over and over again? (this is characteristic of most offshored "enterprise" work, imo)
4. If you had all the money you wanted, would you still choose to work on this project? Or would you do something else?

Update: Vivek Singh makes an excellent point. He says that complex enterprise systems that scale to m(b)illions of users are hard to create (well). I agree (while still believing that most apps that are outsourced to Bangalore have nowhere this level of complexity and are boring jsp/orm/db, "repeat these 3 steps a 100 times" type projects).

What Mr Fowler Really Said

Martin Fowler's post on "Humane Interfaces" has set off a maelstrom in the 'blogosphere'. (He has referred to some of the more interesting posts in his updates to his entry).

As is typical in the world of software, the original points were soon lost in a cacophony of arbitrarily drawn battle lines (java vs ruby, open vs closed class systems, Java's List interfaces vs LinkedList class etc).

This is what I understood from Martin's post. (Heavily paraphrased. Don't blame Martin for any butchery I commit on his prose)

...There are two approaches to designing interfaces. One I (Martin) label the "Humane" approach. Another is the "minimal" approach. Here is an example..{ } .. The distinctions between these approaches are worth thinking about. I (Martin) lean toward the humane approach...

As readers of this blog know, I am all in favor of subjecting opinions to logical scrutiny. But I fail to see how this can be any clearer. It seems fairly obvious that (a) the example used is just that - one example and (b) either approach can be used in any language. Where did "Java vs Ruby" come from? What am I missing?

[rant] I am getting fairly irritated at the lack of clear thinking prevalent in the software world. Aaargh! [end rant]

Why a Lexus is Not An Acceptable Ferrari

Eric Kidd explains on his blog why he thinks 'Ruby is an Acceptable Lisp'.

His thesis is debunked very effectively in the comments section of his blog entry. What I find fascinating is the thinking behind this position.

Let us look at how Eric tries to assert his position that Ruby is as dense (or occasionally denser) than Lisp. He first creates an example of a lisp function , then writes a ruby equivalent which is marginally shorter, while brushing off the capabilties of lisp (reader macros in this case) because "it is not commonly done"!

First , this thinking is fallacious. The fallacy is called "Biased Generalization". From the Nizkor Project,

Description of Biased Sample

This fallacy is committed when a person draws a conclusion about a population based on a sample that is biased or prejudiced in some manner. It has the following form:

1. Sample S, which is biased, is taken from population P.
2. Conclusion C is drawn about Population P based on S.

And this is the error. Eric takes a lisp function that can be expressed concisely in Ruby and simultaneously dismisses Lisp's built in capability to match and exceed that brevity. He ignores lisp functions that can not be expressed as well (see the sentence "Yes, yield is a special-purpose hack, and yes, it only works for functions which take a single lambda but.." -- recreating "yield" in Lisp is trivial anyway-- ) making his conclusion suspect.

Blindly equating conciseness to "power" is also suspect( I used to think this way as well, not too long ago) as is the (unsupported) argument that Ruby is 'more powerful' than Python.

The deeper problem is that, when you say "X is an acceptable Y", what you are saying is "Y is superior and we all know that and we would like to use Y, but because of reasons a, b and c we make do with X".

As someone who uses Ruby and Lisp every day (the days of hacking "enterprise" code with Java and C# are gone! Praise the Lord!), I prefer to think of them as distinct tools in my tool kit. A screw driver can be used as a hammer in an emergency but that does not make it an "acceptable" hammer.

Now I'll stop dissecting Eric's arguments (he has a right to say whatever he wants to on his blog. My irritation stems from seeing some ruby zealots (here in Bangalore) make ridiculous claims about 'the power of Ruby' while having no clue about its limits or alternatives) and focus on my notions of what makes Lisp 'more powerful' than Ruby (and vice versa!).

I consider a language superior to another based on what is possible in one that is not easily possible in another.

From this perspective the power of Lisp stems from the "code is data" concept. Thanks to the s-expression notation (the regularity of the syntax is what powers macros), code is malleable to a degree not possible in Ruby. Yes, you can jump through hoops to get some of the same effect in Ruby (e.g the ParseTree module) but nothing Ruby can do can match the full power of Lisp to manipulate code and the environment just like any other piece of data.

Thus if you are working on domains or projects that need this kind of raw power, use Lisp. Also, contary to what most "enterprise" or "agile" people might tell you , "Object Oriented " is just one paradigm amongst many. In Lisp, one can seamlessly switch from one paradigm to another and can mix and match pardigms to precisely map the problem at hand. While one can approximate some of this in Ruby with enough effort, the language leans unashamedly towards OO with a pinch of functional programming.

The more interesting question, of course is how Ruby is more powerful than lisp. The answer has 3 parts - libraries, community and ease of installation and use. Yes, from a strict 'linguistic' view point things like ease of installation are not language features, but from a user's point of view a language that is theoretically powerful but in practice needs days of configuration and compiling to get a substandard version of what Ruby offers out of the box is unusable. (compare Ruby's Rails framework with the patchwork of CL-SQL, Uncommon Web, etc frameworks). I have little sympathy for "but it is better in theory" arguments. The Lisp community, as compared to Ruby's, is extremely arrogant and unhelpful and hypersensitive to any criticism of their language. Harping on "ANSI standards" doesn't help when an easy to use, open source (no I am not willing to spend big $$ to buy a closed source implementation) implementation with comprehensive, bug free libraries for networking, database access and other "low brow" tasks is non existent.

Thus I think Eric's conclusion ("In 2005, I’d think long and hard before choosing Lisp over Ruby.") matches my experience, though for different reasons. You could substitute "Python" for "Ruby" and it would still be valid.

I don't think "ease of hiring" is an issue unless you are writing crapola "enterprise" code, in body shopping (oops make that "consulting") mode where "plug compatible programming units" is the reigning concept, "agile" rhetoric notwithstanding. If the programmer you hire can't get upto speed in either Lisp or Ruby in a couple of weeks you are wasting your money anyway. But that is the topic of another entry.

Thus the sensible thing to do would be to learn Lisp and Ruby (and Python, and Forth, and smalltalk , and C )well.They are fascinating languages and will teach you different things. Alternatively you could study one and use that exclusively. The utility of a language (and thus, its "power") depends on what you the programmer can do with it, not on some abstract notion of "power".

In other words, learn to use Ruby to maximum effect. Learn to use Lisp to maximum effect. Learn to use --your favorite language-- to maximum effect. This will give you an awareness of what each is good for and where each falls down. Whether Ruby is an effective (whatever that means) Lisp or vice versa is irrelevant. A Lexus may suit your needs better than a Ferrari but it is not an "effective Ferrari" (though it may be better than that overhyped Ford (I did not say "Java/C#" :-P ).

Availability Update

I am not available for consulting assignments till (at least) the end of March 2006. Before writing to me to enquire about availability, do read this first.

I have just started a very interesting project which attempts to integrate machine learning into a massively successful product suite.The size of the data sets and the business requirements make this fairly challenging.

This, when added to my existing commitments (including some very interesting Open Source work), leaves me no time to take on more work till end of Q1 2006.

How Agile Dies

Bill Caputo writes

Perhaps the Agile of today -- represented by things like the Microsoft TDD article, the attempts by many consulting firms to make Agile a methodology (instead of set of principles like it used to be), and the increasing adoption of "Agile" by big IT -- deserves this criticism, but the Agile movement I remember held their observation as a premise.

*That* agile movement seems to already be dying out, but its echoes might still carry the message (if not recognize the messengers)

When you see people offering to "enable" half wit teams for outrageous amounts of money, and "agile" becomes another merketdroid buzzword on the same level as 'ISO 9000 certified' or 'CMM Level 5', you know you'd better call for a priest to administer the last rites.

Many companies in Bangalore are eagerly "developing an agile practice", which (but of course!) goes hand in hand with ISO 9000/CMM Level X /Whatever other BS 'methodologies' are already in place.

One of my friends, who works in 'Big IT', recently responded to "So what do you do?" with "I work in Organized Crime. I am part of an international syndicate that cons businessmen out of insane amounts of money and delivers little value in return".

Heh!

Tech Company Caste Systems

From Businessweek

The suits inside Google don't fare much better than the outside pros. Several current and former insiders say there's a caste system, in which business types are second-class citizens to Google's valued code jockeys. They argue that it could prove to be a big challenge in the future as Google seeks to maintain its growth. They deem the corporate development team as underpowered in the company, with engineers and product managers tending to carry more clout than salesmen and dealmakers.

So a 'caste system' in which 'business types' are second class hurts?

How about the 'caste system' in place in most companies where the suits are on top? I guess that is the 'natural order of things' ? :-)

The outlines of the 'caste system' in place in most 'India Development Centres' can be deduced by examining one expense item - tickets for international flights. Most 'business types' fly first or business class while the 'India Developer Assets' are packed into Economy Class. To see something even more interesting, examine what kind of tickets are bought for Caucasians vs Indians.

Do I mind any of this? Not really. Any game is played in a particular fashion because all players agree to play it that way. It is upto people playing the game to make sure the rules are fair.

What bothers me is the intellectual dishonesty in the implication that "business types on top" is natural but "techs on top" is not. I would have thought that the effectiveness of any company's internal structure would be judged by how successful it is. And by that metric Google is outstandingly successful. So may be the 'new caste system' is 'valid' after all?

I wonder if anyone is working for a "casteless" company? What would such a beast look like?

Update: Slashdot has picked up the businessweek story

I Love China!!!!

From mini-msft

"... Shanghai: the same week various posts come out discussing working with Microsoft engineers in China, also noted by Dare, I took a moment to do a deep dive understanding how things are going over there and what kind of work is getting done. Seems as though most people are very happy with the high quality, hard-work, and ability to deal with Microsoft-Redmond's capricious rearchitecture du jour coming out of China. I haven't heard much in the way of complaints at all, as compared to working with Hyderabad. Microsoft India had best watch out - you guys might get outsourced to China, lending a whole new modern usage to Shanghaied. ..."

Go China go!!!!!!

Conversations and Deeper Issues

Brian Marick writes about Story Cards which contain only the name of the story, thus encouraging developers to talk to the customer before writing code.

This resonates with me for two reasons.

1. I have seen "agile" projects start out by writing story titles on story cards, then add "supplementary" MS Word documents, then write even more bloated documents etc, and then people start saying "but that is not in the document" ,"let us update the document" etc.
2. These days, I am very leery of what I see as an artificial split between "analyst" and "developer".

Don't get me wrong. There are people who know particular domains well and if you are lucky to have such people on board, they are worth their weight in gold. But, and this is very important, an analyst is NOT the same thing as a domain expert. The set of genuine domain experts and the set of so called "business analysts" rarely intersect.

What turns me off is the blurring of the distinction between a genuine expert and someone who comes in and "models" the domain. The idea that someone can become an analyst just because he has an MBA and then spend his time writing ever more baroque MS Word documents/Excel sheets etc, with no real responsibility for the code is ridiculous. The person who analyses the domain and the person who writes the code should be the same. If a software "engineer" can't do this he has no business coding a solution for that domain.

Now, a lot of developers don't care about how business works. This is often because the domains dealt with in "enterprise" software (insurance, leasing) etc, particulary the dreary parts that wash up on the shores of India, are desperately boring to a technically focussed developer and so he refuses to look more deeply into the domain and then pays the price by having to work off an endless stream of word documents.

The easy way out for developers is to work only with domains/clients they are interested in, but in these days of "distributed agile with optimized resourcing " (english translation == outsourcing half baked projects to the cheapest vendor with over staffed, over managed teams), that is perhaps easier to say than do.

I personally find some domains interesting and find innovation and effectiveness in economics just as fascinating as innovation and effectiveness in programming and, these days, work only on projects that interest me. On the other hand I don't have the security blanket of a 9 to 5 "offshore cheap software 'engineer' " type job. Life is more refreshing this way. :-)

Update:- Bill Caputo makes the "Analysis as a separate activity from programming is meaningless" point (in a slightly different context) brilliantly on his blog.

DabbleDb Dazzles

DabbleDb "combines the best of group spreadsheets, custom databases, and intranet web applications into a new way to manage and share your information online". It has smalltalk(Squeak ? ) and Seaside on the backend and is simply mindblowing. Watch the dabbledb movie(warning 113 Mb .mov file) if you haven't already.

An Exercise In Writing Part 2

I have taken the rewriting for clarity exercise one step further.

The original paragraph is

"We have seen how interpreters can be used to model and explain the behaviour of programming languages. The explicit treatment of environments serves to explain scope and identifier lookup rules and the modelling of procedures as closures explains how procedures use lexical scope to make their behaviour independent of the environment in which they are invoked. Our interpreters are written in scheme, but are suitable for implementation in many other languages because they use ordinary data structures and procedure calls."

My best effort so far (without adding any extra information) gives

"We write interpreters to understand how programming languages work. How we design the components of an interpreter determines how the corresponding features of the defined language behave. For example, how we implement environments defines the rules of scoping and identifier lookup. If we model a procedure as a closure, we can grant it lexical scope, freeing its behaviour from its invocation environment.

All our interpreters use ordinary data structures and procedure calls. So we can implement them in any language (including Scheme)."

An Exercise In Writing

(comments are still off)

I am making an effort to improve my writing. Here is a sample of what I have been doing.

In the following exercise, I take a murky paragraph(from EssentialsOf Programming Languages, First Edition,Chapter 8, "Continuation Passing Style") and try to systematically make it clearer. (The technical content of the passage is irrelevant. I am concerned here with sentence and paragraph structure).

The original paragraph

1."We have seen how interpreters can be used to model and explain the behaviour of programming languages. The explicit treatment of environments serves to explain scope and identifier lookup rules and the modelling of procedures as closures explains how procedures use lexical scope to make their behaviour independent of the environment in which they are invoked. Our interpreters are written in scheme, but are suitable for implementation in many other languages because they use ordinary data structures and procedure calls."

Getting rid of the nominalizations and passives gives

2." In previous chapters we learned how interpreters model and explain programming language behaviour. First, we focussed explicitly on environments to understand scope and the rules for identifier lookup. Then we modelled procedures as closures to understand how lexical scope enables procedures to have behaviour independent of the environments in which we invoke them. So far, we wrote the interpreters in scheme, but we could use many other languages because they all use ordinary data structures and procedure calls."

Splitting off the "writing in scheme" idea is into its own paragraph, and eliminating the irrelevant sequencing gives

3."Writing Interpreters is the best way to model programming languages and learn how they behave. When we focus explicitly on environments, we understand how scoping and identifier lookup works. If we model procedures as closures, we can understand how lexical scoping enables a procedure to have behaviour distinct from the environments in which we invoke them.

So far, we wrote the interpreters in scheme, but we could use many other languages because they all use ordinary data structures and procedure calls."

Now there is a concept gap evident between the first and second lines. Plugging that gap and rewriting the 3d sentence to eliminate the irrelevant "we", we get

4. "Interpreters model programming languages and explain their behaviour.To understand language features we need to study the structure of interpreters implementing those features.If we focus on environments, we understand scoping and identifier lookup. Modelling procedures as closures clarifies how lexical scoping makes the behaviour of a proceudure independent of the environment in which we invoke it.

So far, we wrote the interpreters in scheme, but we could use many other languages because they all use ordinary data structures and procedure calls."

I don't like the phrases "(lexical closures) make the behaviour of procedures independent" and "environment in which we invoke". So I replace them.

5. Interpreters model programming languages and explain their behaviour.To understand language features we study the architecture of interpreters implementing those features.If we focus on environments, we understand scoping and identifier lookup. Modelling procedures as closures clarifies how lexical scoping frees a procedure's behaviour from its invocation environment.

So far, we wrote the interpreters in scheme, but we could use many other languages because they all use ordinary data structures and procedure calls."

Now the paragraph is as clean as I can make it, but so far I have treated it as a standalone chunk of text with no relation to the rest of the chapter. I fix that (these modifications depend on understanding what the author intends to teach in this chapter), and smooth away the abruptness of the second paragraph, and remove an ambigous "they" (they = interpreters? languages?) to get the final version

6. Interpreters model programming languages and explain their behaviour.To understand language features we study the architecture of interpreters implementing those features.

If we focus on environments, we understand scoping and identifier lookup. Modelling procedures as closures clarifies how lexical scoping frees a procedure's behaviour from its invocation environment. To study recursion, exceptions, and other language features involving transfer of control, we should study an interpreter that explicitly maps control flow using continuations.

So far, we wrote the interpreters in Scheme and they all use ordinary data structures and procedure calls. So we could, in theory, use many other languages. In practice, we .."

At this point, I can't think of anything else to do (well I could change the rhythm of the sentences to avoid a staccato effect. But here I am concerned with sentence clarity not rhythm). So I stop.

Blog Lockdown

I have disabled this blog temporarily.There will be no new posts for about a month (or two) and comments have been turned off. Mostly, it is because I am too busy and will often be away from the net during this period. I also find myself increasingly dissatisfied with the pathetic level of my writing skill. Maybe a short break will give me some clues as to how to get to the next level..

I am available by mail. If anyone writes in, I will (eventually). respond.

Balloons, Pins, Ego

A thought experiment.

Picture yourself holding a set of helium filled balloons, of various sizes and colors. They all have a string tied to their base and you hold all the strings in your hand.

Each balloon has a label on it which names one of your "attributes". Say "Indian","American", "good programmer", "employed", "iit" (;-)), "thoughtworker", "ai hacker", whatever.

Now ask yourself if you are holding those ballons very tightly , to the point where you can't let go (or can't bear to see others jab it) or do "you" exist independently of the balloons you hold?

I just did this experiment for myself , and found that I get irritated when people prick a balloon labelled "rational" . In other words, I get irritated when people accuse me of behaving irrationally, accuse me of implying things I didn't etc.

Of course this is stupid. My rationality or irrationality has nothing to do with whether people say I am irrational or not.

Fairly obvious huh?

I found this "which of my balloons is being pricked?" a valuable question to ask myself whenever I start feeling irritated, angry, cornered etc.

And then prise those fingers apart and let the balloon float free.

or confidently wait, knowing the ballon is unassailable and unbreakable.

Or just enjoy the "pop" and smile

IIT Grad == Excellent Programmer?

This is something I have never been quite able to resolve. Logic says (hey the IIT BTech guys apparently work through SICP early and if that doesn't upgrade your programming skills I am not sure what will) they should be better programmers. And Google India apparently hires only IIT Grads, so there is probably something to that argument.

On the other hand, in my experience, this "superiority" of IIT grads never really showed itself as a real world phenomenon. Most (but not all) of the really good programmers I see, seem to have a BSc (or other non-BTEch-CompSci) background, and are almost uiversally self taught programmers.

While I was in Thoughtworks, I even went through this strange phase in which TW interviewed about 40 IIT Grads after a company that used to hire only IIT grads went bust, and ended up making an offer to one guy (and he was very very good. I knew him from my Aztec days. He eventually went to July Systems)

It is all very puzzling. Because I do know many bright people from IIT but they are almost all in the USA. So maybe that is one explanation? The best folks from IIT go to the USA and the people a Bangalore based company interviews are probably the "lesser" ones of a batch? Especially in the "enterprise" space? I really don't know. But is there really such a huge difference in the capabilities of people who studied in the same batch?

Of the 40 or so people TW interviewed,(and didn't hire), one interview really stands out. There was this guy who claimed a lack of knowledge of "enterprise" coding but was, in his own words, a "specialist in Compilers and Mathematical/Scientific Programming". The interview team consisted of me(very very interested, and fairly knowledgeable in compilers) and a colleague, JK Werner who graduated in Mathematics.

Those days, In Thoughtworks, one of the guidelines for interviewing was "If people don't know something, that's fine but what they say they know, they better know and know well". So the candidate not knowing "enterprise" stuff was fine(It is all fairly simple anyway and an otherwise competent programmer can pick it up fast).So JK and I proceeded to have a conversation about compilers and math and the interview was .... terrible. This person was just mouthing "buzzwords" without having any deep knowledge.

question(me):- "Ok so after lexing and parsing you get an AST what do you do then?"

answer:- "hmm... I am not sure.." (his cv claimed he'd written a full fledged "parallel compiler")

question (jk): "Your cv says you have worked extensively with Vector Spaces, so here is simple question to start off. What is an Eigen value"?

answer:"hmm well I never got that far" (!!). (as per his cv he did all sorts of fundamental Linear Algebra related stuff)

This was the most disappointing interview in my life. Other interviewers narrated horror stories of "Senior Architects" who didn't know what "classpath" was!

So I am forced to conclude, being bright, and getting through IIT(those entrance exams are tough) and even working as "Lead" or "Architect" or whatever on large projects does not necessarily make you a good(forget great) programmer.

Also "enterprise" work and that too in India is probably not attractive to the average IIT graduate who has so many more interesting options.

So these days I just dismiss the educational background and look at coding skills exclusively.

Still, it is all very strange. If anyone has any insights, please enlighten me!

Update

Joe Williams was kind enough to point out a possible misinterpretation (you can see Joe's comments in the comments section).

What I am saying

1. I used to think IIT graduates (and students) were way above average in programming ability.
2. I expected, given a fair (but tough) interview, about 35 (of 40) or so would get through. When only one did, I was forced to re examine my belief (see above)
3. When I examined the best programmers I knew and their schools, I found that most(but not all) were BSc/non comp-sci graduates.
4. This is possibly a perception issue. I am asking for clarification
5. Logically , I now believe that programming ability and schools are not correlated

What some people think I am saying

1. TW(India) is an uber cool company
2. Anyone who doesn't get through in TWI is a poor programmer
3. Most IIT folks we interviewed didn't get through
4. Therfeore IITs suck and any IIT ians are poor programmers

Needless to say what I am claiming is the first list of assertions. Anyone who claims the second list as "true" has no clue.

Thanks, Joe.

Now I have more questions, if 40 MIT graduates interviewed (say in Google), how many would get through? The question remains, does your school have a correlation with the number of people who are excellent programmers?

Hopefully now things are clear.

And Miles To Go - Part One

This post could be titled "How Paul Graham's Writing Makes me Weep With Frustration With Its Elegance And Conciseness" but that is probably too long a title.

The point is still valid though. In his latest article, I find he has articulated in simple, crystal clear sentences, ideas I have been wrestling with in wretched futility for months.

Here is a simple example. When I went back to Thoughtworks for a visit recently, someone asked me "You have been doing some interesting ( == non j2ee, non enterprise) work for a year now So what did you learn?" And I said (among other things) "Math is important.". But then the thoughtworker asked "But isn't Math just another domain for the "analyst" to master? Any domain expert who deals with a domain will know what exactly he wants calculated and how. Why should we developers delve into the underlying theory? In other words isn't Math just a domain? "

I instantly saw that there were deep chasms dividing the world of enterprise software from the kind of code I write these days, but I couldn't find the words to bridge those chasms. I mumbled weakly that "Understanding math somehow makes your thinking better". Neither the questioner nor I were satisfied.

Now see how elegantly Paul expresses it(emphases mine). After saying that letting your mind wander is often a good source of ideas, he begins to wonder why that is so.

"....What happens when your mind wanders? It may be like doodling. Most people have characteristic ways of doodling.....Perhaps letting your mind wander is like doodling with ideas. You have certain mental gestures you've learned in your work, and when you're not paying attention, you keep making these same gestures, but somewhat randomly.In effect, you call the same functions on random arguments. That's what a metaphor is: a function applied to an argument of the wrong type....The habits of mind you invoke on some field don't have to be derived from working in that field. In fact, it's often better if they're not ... Are some kinds of work better sources of habits of mind than others? I suspect harder fields may be better sources, because to attack hard problems you need powerful solvents. I find math is a good source of metaphors good enough that it's worth studying just for that."

And there is what I should have said when people asked what good Math was. Math gives you more "primitives" to operate with and more ways of combining them. So do programming languages like Erlang and Lisp (which I was forced to turn to when the problems I was working on got too hard to handle with Java or Ruby). Math (and some programming langauges) are indeed "powerful solvents" that give you more ways of perceiving a problem, more choices on how to deal with those problems and overall a much richer field of possibilities.

Duh! I had to wait for Paul Graham to write that up and when I read the above quoted sentences I was shouting at myself "Exactly!! That is what I wanted to say"

Here is an ultra simple example of what I experienced. I needed to build a fairly complicated Neural Network with avery abstruse Training Scheme. For a long time I used the habits of thought I had picked up in years of "Object Oriented Thinking" and thought of a neural network as an "object having properties X and Y , with behaviours A and B , consisting of n Layer objects, each having properties blah and behaviour foo.. A Training Method is a Strategy Object that decides ..." and so on.

The people who I was talking to were primarily mathematicians and scientists and soon a communications gap yawned and we were all getting frustrated. Now I could have insisted they grok Objects or I could just learn the underlying math. I chose the latter and gritted my teeth, clenched my muscles and jumped into the Linear Algebra and Calculus needed to understand neural networks and .... found it quite interesting. Nothing like the nonsense poured down our throats in college. I was now using the best books, written by the most talented folks in te field, to learn, and I was applying the knowledge I gained to solve a very tough problem. And soon I saw that understanding Vector Spaces and Differential Equations allowed me to see neural networks in a new way. As I told a friend sometime later, a Neural Network is a set of Equations and every training scheme solves a problem in Topology. There is no way I could have come to that understanding without harnessing the underlying math. No amount of "Domain Modelling" or "Extreme Programming" or whatever would have given me the understanding needed to tackle the problem.

And that is why today when some people look at the work I do and say "dude , I don't want to study all this math stuff. Too dry for me. Lisp is too hard as well, leave alone all this concurrency stuff. But I want to learn AI too.I will just use TDD and Java", I just smile to myself. Unlike most "enterprise" work, in production strength AI (and most other "tough" fields I would imagine), not understanding the underlying domain deeply enough to acquire an intuition for what will work and what will not, just wastes time. Without the new perceptions opened up by grokking the "powerful solvents"(and it will take about a year of work to get to that point), one is just as blind as ever.

And it needed Paul Graham to make it all clear in about 5 sentences.

I have also come to see that the Analyst/Developer split is very dangerous, even in 'Enterprise' software and leads to substandard software. But that is a topic for another post.

Yet another "apprenticeship pattern"

Earlier, I wrote about an 'apprenticeship pattern' I discovered.

Here is one more .

Be good at something other than Programming

If you plan to be good at programming, take up the practise of another discipline- music, painting, a martial art, woodworking, it doesn't matter - just pick one that interests you.

Many top notch programmers are very good at other things. Paul Graham is a painter. Peter Norvig is a mathematician. Eric Raymond is a Pistol Shooting expert.Richard Stallman says "My hobbies include ... international folk dance, flying, cooking, physics, recorder, puns, science fiction fandom, and programming;" (While I have never seen Stallman dance, people who have, assure me that he dances very well indeed)

While there are exceptions, (more on this below), I would be very skeptical about someone who claimed to be a good programmer ('hacker', if you will) and who is not skilled at something else as well.

Many people have written about this from different angles. Paul Graham says,

"...Hacking and painting have a lot in common. In fact, of all the different types of people I've known, hackers and painters are among the most alike.

What hackers and painters have in common is that they're both makers. Along with composers, architects, and writers, what hackers and painters are trying to do is make good things."

Eric Raymond says in How To Be a Hacker,

"... Train in a martial-arts form. The kind of mental discipline required for martial arts seems to be similar in important ways to what hackers do. The most popular forms among hackers are definitely Asian empty-hand arts such as Tae Kwon Do, various forms of Karate, Wing Chun, Aikido, or Ju Jitsu. Western fencing and Asian sword arts also have visible followings.... Develop an analytical ear for music. Learn to appreciate peculiar kinds of music. Learn to play some musical instrument well, or how to sing... "

The one apparent exception I have seen to this 'pattern' is when truly exceptional programmers seem to have no hobby (besides programming). My friend Anand Babu, would seem to be an example of this.

Anand spends significant amounts (or all) his free time writing code and is the creator of truly significant programs. If, like Anand, you are the author of code that makes a significant difference to millions of people, then you probably don't need this 'pattern'. Geniuses don't need to follow rules or patterns anyway.

Otherwise, in my experience, serious practice of music, for example, might help you become a better programmer than grinding through yet another J2EE app.

Gloom And Despair

Eight years ago, I was writing code like

public class PaymentProcessor {...}

A year and a half ago, I was writing code like

public class PaymentProcessor {....} (oh yeah, this time there was a class PaymentProcessorTest backing this up)

I was gloomily reflecting on those wasted years when I came across this snippet (from news.com)

"... Stanford University's Racing Team has accomplished a historic feat of robotics, finishing first in the DARPA Grand Challenge, a 131.6-mile driverless car race that no artificially intelligent machine has ever conquered before. ... Onlookers were wide-eyed watching the vehicles work their way through the extremely tricky course even though much of the race they could see only by wide-screen TVs in the spectator tent or by a real-time mapping tent.

For example, people in the spectator tent watched on with awe when Stanley drove over and down Beer Bottle Pass, which has 1,000-foot drops and hairpin turns. The packed crowd cheered when the car made it around the first switchback and then began chanting "Stanley, Stanley" as it drove down. .... "

Now that is real programming. While Providence was kind enough to set me back on track, I still can't get over how many years I wasted on "enterprise" code, essentially writing the same web->db->web routines over and over and over.

I am depressed.

Back to Step One

I have played (ok, fiddled with) a steel string guitar for several years now. While I have a classical (nylon string) guitar and have worked through a good part of book 1 and book 2 of Federick Noad's classical guitar series, I never became very good at it. While I could play some pleasant sounding tunes, no matter how hard I tried, I could never sound like Julian Bream or Segovia. Their playing had a richness and lushness which I could never match.

So I put away the nylon string guitar and never used it much. I thought I was doing something wrong and even went to a teacher, but that didn't help very much, because while he gave me some good advice, I still didn't get the guitar to sound like I wanted it to. Gradually, the pressures (and the monotony) of a fulltime job meant that I ended up not playing very much at all.

Recently a friend sent me a copy of the Pumping Nylon DVD. I also happened to read George Leonard's fantastic book, Mastery. Combining Scott's guitar advice with the "Mastery" notion of maintaining total awareness and relaxation transforms the simplest steps into a discipline of fantastic depth.

Consider the simplest possible action on the guitar, that of plucking a string with a finger nail. Before, I would just pluck it and the note would sound. Scott suggests a four part motion - place the finger on the string, apply pressure, pluck, and "empty out" or consciously relax the plucking finger, each to be practised to perfection before combining them. Performing this as four distinct steps with the "mindfulness" advocated in Mastery is a very challenging exerscise.

Relearning the guitar is simultaneously easier and harder than learning for the first time. On the one hand, you know quite a bit already - how to move from one chord shape to another, how to play staccato or legato and so on - but on the other, everything you know is ever so slightly "off" or just plain wrong and thus demands a totality of focus to train your reflexes in the new grooves.

So there I am, plucking the same note over and over again, marvelling at how small changes in the angle of attack or pressure yield infinite variations on a single note. After a few dozen (hundred?) repetitions, there comes a moment when everything "clicks" and my finger flows on and off the string and a perfect, golden note shimmers in the stillness.

And for just that one moment, I do sound like Julian Bream.

I.need(true).someMoney();

The "code should be readable" principle, like any other, can be taken to extremes.

Recently, someone advocated replacing (junit's) assertEqual(5,obj1.getValue()) with Result.Of(obj1.GetValue()).ShouldEqual(5);

Yet another suggestion I heard was to replace assertTrue(x > y) with Should.be(true).that(x).greaterThan(y) !!!

A class called "Should" with a method called "be"?

The best reaction I heard was from a friend who said,

"I can write a program to substitute spaces with "." and put a "()" at the end of requirements written in English. That would be better than this lunacy. Thus I.need(true).someMoney() :-p"

Remember the language where you could just "express business requirements in English" without "developer speak" coming in the way? Yes, COBOL.

This ridiculous notion that code should look like English comes from a misunderstanding of the "Objects model the domain" principle.It also makes sense to those who have only (an imperfectly understood) Object Oriented Paradigm in their bag of tools and frequently those who can only "speak" Java (although I have seen this happen to some self proclaimed "smalltalk experts").

I once worked on a project where the "Chief Designer" was Object crazy and we ended up creating Objects that replicated all the components of a relational Database imperfectly. Thus we had classes like "Table" and"Query" right in the code, with all sorts of fancy tree creation (and tonnes of Visitor classes)to create simple "Select *" queries as objects. We even had a ridiculous "FieldedBusinessObject" class that was essentially a glorified Hashtable, with well over 300 fields and methods with the interrelationships laboriously hand coded. All in the name of "OOD" (and in a "100% pure XP" project too !!!). I pity the client who paid good money for this hogwash.

Genuinely understanding a paradigm means knowing what it is not good for, just as well as how to apply it effectively when it is suited.

Using an object structure to create a poor man's version of a very ambigous spoken language like English is a warning that the practitioner probably shouldn't be programming live systems in the first place. Doubly so when this misunderstanding is couched in terms like "Ubiquitous Domain Language", which have very precise meanings and context, totally unrelated to such foolishness.

If you must have a totally unrelated language embedded in your code, it is far better to learn how interpreters and compilers work and and how to embed sublanguages in your code (no,XML is NOT a good way to do this!) Yes, that means learning some "esoteric" computer science theory.

If you ever find yourself contemplating classes like "Should" with methods like "be" (coming soon to a framework near you! I am NOT joking), find the nearest wall, bang your head thrice on it, very very hard. Do this enough and you'll be ok! Or at the least you will soon not be able to do much harm.

Alternatively, the nearest walmart is probably looking for checkout clerks.

A Foobject is Made of Green Cheese - Sense And Nonsense in Technical Discussion

I have been hanging out on certain "technical" mailing lists recently.

This is a sample of the type of argument I hear.The actual concepts have been replaced with fictitious 'FooBars' etc to protect the guilty (and more importantly, the innocent).

" ...I hereby proclaim a new style of programming. State and Behaviour will be consolidated in one entity, these will be called Foobjects.No, they have nothing to do with Objects, though this may sound similair to uninitiated ears. Don't ask me for exact differences; but if you unwashed heathen must know, here it is - allFoobjects are named with a name that is exactly 17 letters long. Now coming back to more important things, Foobjects will be used to model the domain.

Before you name a foobject, touch your nose to the floor and draw the holy name "foo" on the floor 3 times. The contact between the tip of your nose and the floor will put you into the right mental state to perceive the behavioral characteristics of the Foobject. And woe betide anyone who dares to name a foobject without doing this Holy Rite Of Naming. And of course this is just my opinion. Nobody can ask me questions or ask me to justify this logically. But this is of course better than all existing methodlogies of designing software systems.I won't show you any code but of course any code thus produced will be superior. You'll just have to take my word for it. Any challenges to this will be treated as a personal attack.I will soon write a FooFramework and FooBook. Keep your wallets ready. ..."

Now in contrast, some extremely useful stuff.

Dale Emery On Naming Test Methods(slightly paraphrased to remove context)

" The primary principle I use to organize tests is The Principle of Rapid Fault Identification:

If one or more of these assertions were to fail, what organization would lead me as quickly as possible to the faulty code? ... I might want three separate test methods so that if one fails, the others can still run and give me further information. If I write these as one test method, the first failed assertion aborts the method, and I never find out whether the subsequent assertions pass or fail.

A sub-principle I use is The Principle of Independent Utility:

If the results of the assertions might be independently useful to me in identifying the fault, I organize them into separate tests so that one failure doesn't prevent me from getting the useful information from the others. If the other results are likely to be just noise, I organize the assertions into one test method so that the first failed assertion precludes the others and suppresses the noise.

I use The Principle of Rapid Fault Identification also for naming: If this test were to fail, what name would lead me as quickly as possible to the faulty code? As an example , I might name three test methods something like this:

GameIsNotOverWhenFirstCreated() CurrentFrameIsNotOverWhenGameIsFirstCreated() NoScoreWhenGameIsFirstCreated()

I might come up with better names with a little more thought (or at a time of day other than 5:30am). For example, I'd like to write "NotOver" into a positive. Perhaps GameIsInProgressWhenFirstCreated().

The best test namer in the universe is Brian Button. I've studied his test names, and they tend to have three parts:

For example: GameIsNotOverWhenCreated() - Desired Result: Game is not over - Coordinator: when - Conditions: first created

These few principles have given a big boost to my testing."

This gem of a post justifies putting up with all the nonsense you have to wade through. This has already improved the quality of my testing 100%. The condition-connector-result naming format is extremely useful in coming up with good test names.

SourceDiving into Nethack

Manoj's recent post woke sleeping demons and they compelled me to fiddle with nethack.After winning the game(ascending in nethackspeak) a year ago, I forced myself to leave the best game in the world aside and get on with life.

This time though I wanted to hack the game a bit.So I downloaded the source version and started fiddling with it. The idea was to create a couple of new characters. For 20 year old code, the nethack source code is certainly well laid out. After years of OO coding it takes a while for the brain to adjust to C 's intricacies. The codebase has a fairly simple structure and once you wrap your head around all the #ifdefs, hacking becomes easier(though never really easy).

I've added a new dungeon(called the TWI level :-P) peopled by some new monsters. Manoj the VC throws gold around in abandon. Owen and Fiona, the Canadian Tourist Monsters attack you with blinding cameras and throw gobi manchurian at you, Rajesh the bookseller hits you with new books and steals gold from you.Naresh the Organizer randomly teleports you into several ASCI conference dungeons. And if this doesn't strike you as particularly funny, don't worry. These are all inside jokes that makes sense in my world.

Now I'm trying to add a new player class -the Ninja - combining about 70% of the Samurai's fighting skills with about 80% stealth of the Rogue with a few Monk spells. The "logic distributed all over the place" nature of C makes this difficult.If the code base was of a well factored OO design or the authors had used a language like Lisp, these changes would be trivial.(If anyone has a year or so of time to port nethack, let me know).

Having said that though , I wish "real world" software was as much fun to modify.

You will have to excuse me now. My Wizard character just ran out of spell points in the Gnomish Mines, with a horde of nasty gnomes and Giant Ants descending on him.Ravi the Wizard broke his Wand Of Light but managed to inscribe "Elbereth" on the floor and the power of that word is keeping the monsters away as the mana slowly builds up. However there is a Werewolf who just entered the Dungeon and morphed into human form Nethack Lore says such humanoids are not impressed with this protection spell.

Deep Trouble.

To add to all this there's a nymph waiting to seduce me and steal my Magic Cloak and a Floating Eye watching impassively....

If Linux Had MBA s

I don't like blog posts that just point to another page on the web and don't say anything original.

But just this once , I'll make an exception.

I've always liked the Mini Microsoft blog and the recent coverage by BusinessWeek (and Slashdot) has given it a lot of exposure. If you ever wondered what it was like to work for the Borg, read it first. Be sure to read the comments, which are mostly posted by people inside Microsoft. The comments are way more fun than the articles, which are themselves very good.

If you want a feel for what the blog is like, look here.

Snippets

"Oldskool MSFT managers wouldn't be afraid to say "no" to upper management or tell Bill or Steve to fuck themselves. Seriously. They better have a point and ammo to back themselves up, but they wouldn't be afraid to say it. The new managers don't like waves. You are punished if you criticize. That's why we end up on blogs instead of yelling "Bullshit" internally like we used to. Does Steve throw chairs? Heck yeah, so does Bill, most architects, etc. We used to have holes punched in walls around NT. But I would rather have that than the passionless yes-men corporate Dilberesque managers we have now. And there is no accountability at MSFT anymore because of this. No manager dares to point a finger because they are afraid of a finger being pointed at them."

More fun .. "For the people bitching about test, this tester says you can f'ing bite me. If you guys could ship code that worked, heck, code that even COMPILED PROPERLY without a buddy test and a test pass, Microsoft wouldn't be employing us. The growth of QA is specifically because developers cannot be relied on to write functional code."

Someone complained that "When I started, my first manager gave me a project by pointing me to the PM who essentially sold it to me as 'this is why we need it', and I started on the library and delivered a fully functioning project two months later... Fast forward to the present: I won't know what I'll be working on until a PM delivers a fifty page spec with pixel measurements and colors...Then I get to start on a document describing all technical aspects of the implementation in detail, together with a daily schedule of what I will do when. All of this will be debated in many more meetings. Then I start writing code."

A PM responded with

" ...An increasing number of PM roles are filled with top CS students from top schools that are looking to have a broader impact on the product, enjoy design, and can work with people (this was how they sold me the PM role). The result is more control being placed into their hands, often times turning the dev into a blackbox that inputs specs/PM direction and outputs coded features. ..."

to be floored by

"..What a load of bull. The PM positions have traditionally been filled with techies that couldn't handle code. They are a good dev's worst nightmare: someone who knows just enough about software to throw out the words, but a complete lack of depth to understand what they are saying. Combine that with the fact that their job title includes the word "manager" and the vaguest job description I've ever seen in my 20+ years of software development and you have a walking, talking, time-wasting disaster. Feature direction and design? Yeah, it's called today's whim.

"...the PM's I work with have backgrounds in CS, and would proudly call themsleves engineers.."

I'm sure they would...fortunately, no one would believe them. "

Hilarious!!! Of course there are more insightful posts too .

"..Regarding all of the recent comments about PMs, my opinion is that there are some great PMs that really help improve the product. The problem is that I think it is *MUCH* easier for a talentless PM to escape notice than a talentless dev. If a PM sucks, dev and test can ignore him and the feature still gets written. If a dev sucks, he can't hide the fact that the feature is late, always crashes, etc. .. "

More ...

"..Testing as a concept is fine. Testing as the accumulation of the political and inept employees is not. ..."

The part I liked best (and where the title of this post came from) was

So, when you think about it, MSFT used to be like the open source community. A bunch of engineers writing a ton of code. And, the engineers were motivated by the same thing. It wasn't about cash, it was about making something cooler than the competitors, just like the Linux guys want to make something cooler than Windows.

That was the root of "crushing the competitors" just like the Linux guys want to crush Windows.

So you open source guys should at least appreciate that. Imagine going from the environment you are in now to having a boss sitting there with charts and graphs, with people who don't code telling you that you need to go to idiotic meetings, etc.

We used to be like you except working on closed-source. In fact, I used to be big on FreeBSD and had conversed a few times with Linus when we were both in school and Linux was still a hacked Minix.

All things considered, engineers are engineers and want the same things whether they work on Linux or Windows. They want to write screaming code that is better than anyone elses.

But now, we've been Dilbertized. We've been internally infested by professional managers who don't know how to engineer.

If Linux had MBA's with no coding experience telling developers what to do, what do you think would happen?

Well, that's what's happening at MSFT. Put yourselves in our shoes for a minute, and I'm sure you'll be able to understand the disgust, frustration, and outrage. "

Bwaaaa ha ha ha ha ha!!! That's the funniest thing I've read in years ! And remeber all this is from just one post in the mini msft blog! Read ! Weep!

Manoj Evokes The Nethack Magic

My friend Manoj Govindan started blogging after some ..err.. encouragement from Yours Truly.

His first post is about how he got addicted to NetHack , a game Yours Truly pushed on him.Very nice post too, hopefully we'll see more posts on piano playing, wargaming and other hobbies of his.

Meditations on Mastery: Ethics and Transformation

I just finished reading George Leonard's book, Mastery . I've heard a lot of praise for this book and it is well justified. This is one of those rare books that seem very simple and obvious but then it grows on you and you find yourself spinning your own lessons out of it.

Most people who comment on the book emphasize that it teaches you to "love the plateau", in other words to keep on the path of practice even in the absence of any visible progress. So it does, but others have spoken on this so I won't. Instead , I will focus on something I learned from it.

In Chapter 11 (Tools For Mastery ), Leonard says "Acknowledge,but don't indulge your Dark Side" . He goes on to say ...

"...(We have a lot of)energy locked up in the submerged part of our personality, in what Carl Jung calls "the Shadow" ... (Poet and StoryTeller Robert Bly says),

'A young child can be visualized as a lively ball of Energy that radiates in all directions. But the child's parents don't like certain parts of this ball. In order to keep the parents's love, the child puts the parts of him they don't like in an invisible bag he draws around him...Then our teachers have their say 'Good Children don't get angry over such little things', So we take our anger and put it in the bag.'

By age twenty, he (Bly) says , only a thin slice of our original energy is left".

This is a metaphor that makes sense to me. The image of people who glimmer with pale flickers of uncertain light, while dragging along a huge invisible bag that thrums with "forbidden" energy but is firmly locked, is fascinating because throughout my life I have been fascinated with the notion of why(with exceptions) good people are so ineffective.

The people who get ahead and get things done are very worldly wise and know how to manipulate the systems around them and thus "play the game". But at the end of a lot of this game playing they find that their efforts have been meaningless and the rewards of what they gain are not as satisfying as they hoped. Thus politicans are very effective in the world but very very few of them are nice people, and few of them live meaningful lives or die content.

On the other hand are those who have a lot of idealism and caring but are stunningly ineffective in life. These folks have all the right ideas of what the world should be like but seem unable to move the world from here to there and are dismissed (rightly so) by the "players of the game" as insignificant or "idealistic". .

Thus on the one hand we have people who have an excellent sense of direction but no power, and on the other, people who have (or know how to get) power but are not clear on what to do with the power and end up either preserving the status quo, or worse changing it to a one of increased Tyranny and Evil.

The myths of our age show these archetypes very clearly. Thus in "The Lord Of the Rings", (I speak of the book version, the movies are a pale shadow ), the Dark Lord, Sauron, is impossible to defeat at the height of his power. Even with the loss of his Ring Of Power, he is frighteningly effective in drawing to himself massive armies (dwarfing anything the "good guys" can manage) and even his subordinates (The Nazgul) are almost unstoppable. What makes him a "dark" figure is that if he were successful, he would impose an Age of Tyranny and Terror on Middle Earth. In other words, if he were to be successful, all that terrifying force of will and ambition and cleverness would be applied in the wrong direction.

On the other side we have a motley band of "good guys", each of whom is no match for The Dark Lord individually,but collectively manage to defeat him. The Ring Bearer, Frodo has almost no heroic qualities except that his heart is in the right place. Frodo is the epitome of the "idealist", a guy who wants peace and calm and radiates "Good Will to all", but will essentially, if left alone, while his days away with his tobacco in a corner of the idyllic Shire.The other "Good Guys" all epitomize the perfection of one major "good" quality (Gandalf has Wisdom, Aragorn has the Leadership), all of whom have to work in concert to defeat the Dark Lord, who combines all "dark" qualities in one person.

Another Modern Myth , Star Wars , offers its own parallels.There are these "good guys" , the Jedi who shun the "Dark Side", and work for Peace and Goodness. And the Sith who are focussed on dominating the known world and stamping it in their image.What is often missed is that the Sith are tremendously more effective, with two Sith (there are always only two) matching and often defeating hundreds, if not thousands of Jedi. And the Hero is a kind of clueless Everyman, and really does not evolve very much through the story except to somehow mysteriously become a Jedi Master in a very short time.

Anyone with some common sense would know that becoming a Jedi Master would take decades of very hard work. This bending of the rules, where the "Chosen One" doesn't have to work very hard to achieve superhuman levels of mastery (Neo of the Matrix is another example) has its own dynamic in modern story telling but that is a subject for another post.

So here is the formula for creating a (modern) myth. First create a Bad(make him really really bad) Guy who has immense Power and is frighteningly effective. Bring him into conflict with an "Everyman Joe" kind of figure (so your readers/viewrs can empathise with him) who is nonetheless somehow the "Chosen One". Sorround this Good Guy with pseudo Masters who are all old and past their prime and speak in riddles. Throw in a "True Love" Aspect if you want to get the women to read the book/watch the movie. (These days it helps if the main female love interest is very feminist in her views and "just as good as the men". Thus the Leia as Jedi (bwaa ha ha ha) theme or Arwyn the Elven Princess facing off against the Nazgul (thankfully not in the book, only the movie).

Back to the main point. Leonard's analogy of the 'person with the bag(containing the Shadow Self)' is very apt and while his subsequent advice to harness the Dark Side(thus when you feel Anger rising, he advises you to not give into the Anger, but to harness its energy to do something useful) is easier said than done, it points the way to a different-from-expected but truer kind of Mastery.

Thus in my personal cosmology(feel free to whack away at this) a Master would not be some wimpy hero (like Frodo or Luke Skywalker), but a genuinely powerful being who could go toe to toe with the most powerful "bad guys" without any Deus Ex Machina popping in to conveniently save him just when the villain is about to make mincemeat of him. And one step to achieving this kind of power would be to consciously "empty the bag" and be Master of both Light and Shadow and be both worldly wise and idealistic.

Even in History(and not myth) the "good guys" are those who combine tremendous pragmatism with tremendous idealism to defeat the "bad guys" who are very very talented or powerful but pull in the wrong direction. (e.g. Roosevelt Vs Hitler, Abraham Lincoln vs the Confederates,Gandhi vs the British Colonizers).

Thus to go back to George Leonard's(or rather Robert Fly's) analogy, a true master will be neither a glowing child, nor a weary everyman figure with a huge bag of Darkness, who mysteriously becomes a master because he is "chosen", but an unencumbered figure with a consistent, calm sheen of power,who walks the line dividing Light and Dark,able to draw on either, and to transmute all the energies he harnesses or encounters into various combinations of light and shadow as appropriate to the environment, but chooses steadily move towards an idealistic end.

Thus , in my opinion, Leonard's advice would become,"Don't indulge your Dark Side. Acknowledge it.Then harness it".

Sounds tough? oh well, No one said mastery is easy !

Darth Ravi, Jedi Rajesh, And The Craftsmanship Manuscript

Dave Hoover blogs about getting feedback on his book. Rajesh and I have been reviewing Dave and Ade's forthcoming book.

At one point I said,

" ...Rajesh probably is more suited to chime in here than me. The standing joke amongst us is that Rajesh is the Jedi - basically a good guy focussed on people and I am the Sith - focussed on pragmatism and effectiveness ...We Sith have to be with two of us against an army of wimpy Jedi

And then, after seeing some of my "tear apart the material and point at every hole in the structure and logic " style reviews and Rajesh's more "softly, softly" approach, Dave started calling me "Darth Ravi" (and Rajesh, "Jedi Rajesh").

I like it! Now to get one of those shiny Vader masks to breathe through ...

The Meanings Of Mastery

Recently I was startled when I heard someone say "Linus Torvalds is not a "master programmer" because he doesn't 'mentor' people ".

My first reaction was "bwaaa ha ha ha ha ha !!! yeah right ". To me whether someone is master at an activity has nothing to do with any behaviour on his part but is a function of the degree of skill he has.

While commenting on my last blog entry someone else picked up on the same theme. The reasons given didn't stand up to scrutiny since they were based on an arbitrary religion (Hinduism) and what a particular view into that religious system claimed was "true" and "divine", but the phenomenon was interesting.

Two people making similair claims about something that was to me, "obviously" nonsense. My friend Manoj chimed in with a sharp mail that claimed "master " is used in contexts which have nothing to do with either skill or students (e.g. Post Master ; Thanks Manoj, that was good feedback)

Time for a closer look.

After looking up various meanings and usages of the word (a good idea Sriram), I find that the word expresses three distinct concepts, applicable to three different situations.

The first is "An expert in a topic" as in "He is a Master of 3 languages". In this case the "of" in "master of" is followed by a skill set, a non living thing. I will call this "variant 1" or "skill based" mastery. Here mastery arises from being able to do things in a certain "field of operations" that none else (or very few other people ) can .It is in this sense that Linus Torvalds is a master programmer.His mastery is over programming and only very indirectly over people .With or without people he is still a master of programming.

The second has to do with power relationships (however established). In other words "master" means " One that has control over another or others " as in "the dog ran towards its master". This is the sense in which "Post Master" (a person who controls other workers and processes ina a post office) or "master of a ship" (a person who dominates and has authority over other people on a ship) is used. I will call his "variant 2" or "people based" mastery.

In other words, this variant of "mastery" is present only in a context that includes dominating other people. This domination could be granted involuntarily by the dominated person (as in a master - slave relationship) or voluntarily (as in a master disciple relationship ). The fact remains that this mastery involves the exercise of power whether benevolently or not.

There is a variant of this meaning which comes from the Guild system in Medieval Europe. The twist this adds is that the master has to be "licensed" by some process, usually involving the approval of other similair "masters" to teach. Anyone who is not so licensed by some form of "guild" is not a master. I shall call this variant 2A or "guild mastery".

Thus, while Jesus Christ was a "Master" by the variant 2 meaning, (people accepted him as master and he had disciples) and anybody who became his disciple voluntarily granted him a dominance in certain areas of life, by the guild variation, Jesus would not be a master unless approved of by other "masters". Given that only John the Baptist "approved of" or "licensed" Jesus (and John himself does not seem to have any kind of "guild" approval) we will have to infer that a self proclaimed "guild of religious teachers" would have rejected his "mastery ".

And if you look carefully you will see that the positive versions of variant 2 would also depend on variant 1. In other words, Jesus was looked up to as a "Master" (by his disciples), not because some guild or bunch of people said he was a master because he could do things (clarify deep moral dilemmas , answer questions, work miracles) that no one else in his time and place could.

So now the question becomes, which of these models is appropriate to software development? To a certain extent this is a subjective question. However, that being said, There are people who want variant2 (a master and his disciples) or 2A (a "guild" which "sanctions" or "confers" mastery).

In today's world which is essentially egalitarian, networked, democratic and open, I stand with those who believe that mastery in programming (or anything else) is of the first variant, based essentially on the degree of skill. If you can develop programs in a demonstrably superior fashion, then you are a master. If you don't have a single disciple you are still a master. If you don't have a "guild" sanctioning you ,you remain a master. In other words, a Master first becomes a master and then may choose to teach in whatever manner he thinks appropriate (Sriram's idea. Thanks Sriram!). He is not forced to teach to claim masterhood or be "conferred" masterhood by onlookers on the sidelines. Thus Linus may or may not be choosing to teach by letting his code be open source. It doesn't matter. His mastery is self evident from the skill with which he writes code.

Martin Fowler is a master technical writer and speaker because he can speak better and write better than (most) other people can. Not because he is part of the Agile Alliance or Chief Scientist of Thoughtworks or any other "title" based attribute. These other memberships and positions flow naturally to someone who is a master by the "skill based" meaning of the word.

The main problem I have with the Guild meaning is that its essential purpose seems to be to satisfy some kind of psychological craving for certainty in an uncertain world, in an attempt to assuage an inner shakiness by formulating fixed levels and labels. You don't need a three fold, "peer sanctioned" guild like stratification to recognize someone better than you at programming and learn from him/her. Any programmer worth his salt does so all the time. And so I reject McBreen's book as half baked.

And anyway, whatever model you want to follow, invoking arbitrary religious principles or nostalgia for a romanticized view of the past to justify that choice is sloppy thinking. The solutions for the problems of this century are to be found here and now, not in the past.

So if you want to be a master programmer, focus on how to improve your code skills . Don't bother with whether some arbitrary group of people like those found on say Advogato "rate" you. If you must have these "strokes" from other people to validate your self-worth, be aware that the ratings as "Master" too will automatically happen when you have attained the appropriate levels of skill. And by then you won't care what other people say your "level" is.

As Eric Raymond says in his loginataka, (a parody of a guru-shishya dialogue),

"Rather must you Become, and Become, and Become, until Hackers respect thy Power, and other Wizards hail thee as a Brother or Sister in Wisdom, and you wake up and realize that the Mantle hath lain unknown upon thy Shoulders since you knew not when."

[Thank you Manoj, Rajesh and Sriram, for helping me clarify my thinking. Prakash too, though I absolutely reject your "guru/hinduism/indian culture/the Bible is divine" argument]

A Nostalgia for Guilds And Other Dangerous Ideas

After some thought provoking conversations over email with Dave , Ade and Rajesh recently, I read Pete Mc Breen's book on Software Craftsmanship .

The book's fundamental thesis is interesting. It says that the "software engineering" way of creating software is broken (I agree) and it posits a "craftsmanship" approach to software as the solution .(I disagree).

Let me clarify that statement.

I don't disagree with the idea that viewing software development as a craft rather than some kind of factory process will yield insights into how to progress along that craft.

The basic problem with the book is that it proposes what is essentially a medieval socioeconomic structure as a solution to a 21st century problem ,and selectively focusses on the virtues of the old "guild" system where practitioners of a craft were classified into 3 categories - apprentices, journeymen and masters .

Now let us examine how Mr McBreen proposes to solve the "software engineering problem" .

he says, (all emphases mine)

"Rather than attempt to industrialize and deskill software development, the software craftsmanship approach looks back into history to see how the problems of expensive labor and arcane skills were handled. " ( Chapter 5 )

While the book doesn't go into too much detail on which nation's history of what period is being "looked back at" , it is fairly obvious from the sorrounding context and talk of "Apprentice, Journeyman and Master" that he refers to the guild system that flourished in Medieval Europe.

So Mr Mc Breen, on the one hand says that a methodology originating in the 1960s and continously evolving since then (software engineering) doesn't work for software development in the 21st century so we should go back to the 14th , for solutions ! Interesting !

There are two ways to use labels like "apprentice", "journeyman " and "master".

One is that of a rough guide to where on a skill spectrum a practitioner of a craft falls.In any time period, in any craft or art, there will always be a fairly consistent ranking of people in terms of skill and it sometimes helps to mentally divide that spectrum into n categories and name those categories whatever you want.Yes, if n ==3 you can name the categories , "apprentice", "journeyman" and "master" .This is only a way of seeing the progress along a craft .Those labels have no real validity .

The second way is to use such terms as rigid unchanging classifications of people(however derived) and attaching separate privileges to these labels .

Thus you couldn't run a craft based business in medieval Europe unless you were a member of the appropriate guild and presumably of an appropriate "rank" to do so . Today anyone can start a business and thrive or crash based on the economic logic of the business. Which system would you prefer to live under ?

the fact that Pete Mc Breen supports the second ,"rigid label", way is evident from a paragraph that states

"A master craftsman may learn a new technology from an apprentice, but it does not mean that she is no longer a master. If anything, it reinforces her mastery because it illustrates a willingness to learn from everyone."

Hmm thus, irrepective of whether a so called "master" is demonstrably expert *in the technology being worked on * or not, he is always a master .And the poor fool who does, in this case, know enough to "teach the master" is still an apprentice . The labels are rigid .Once someone becomes a "master", even a situation where the practitioner fails totally does not remove "masterhood" .Nice!

You might think it would make sense to say that in this context where the new technology is relevant , the "master" and "apprentice" labels are reversed .Thus if an acknowledged superior programmer, say Linus Torvalds and I are pairing on creating a j2ee leasing system ,(I presume Linus will kill himself before he has to do this , this is all hypothetical, bear with me ), then, in the context of j2ee, logic would seem to indicate that *I* am the "master" (or "journeyman " or "Lord and Master" or "King Skeletor" .. use whatever labels you think cool ) and he is the "apprentice" (or "teeny weeny toddler" or whatever , as long as the label is "lesser" than mine ) .But no! Once a master always a master! it doesn't matter if you don't have a clue.

The more significant question of course is "does this kind of labelling make any sense" ? hmmmmm....

Other paragraphs in the book identify mastery with "peer recognition" . There is a very subtle fallacy here .In other words,as per the book , Bruce Lee was not a master martial artist because he could fight better than anyone, but because he is *seen* to be a good martial artist by his peers . This confuses cause and effect .

To see the fallacy embedded here, you can drop each condition in turn. Suppose Bruce Lee never became famous but retained as much of his fighting skill as he did . Is his "mastery" now non existent because he was not recognized ?

Now let us try it the other way . If Bruce Lee was much much more famous amongst "peer" (of course it is not defined how these "peers" would be selected. maybe they are people with the same label from the guild? ) martial artists but could never demonstrate his skill in combat (an analogous situation would be a large number of book authors having no really significant software to back up their supposed "expertise") would he still truly be a "master" ?

This labelling based on irrelevant attributes is the least part of the nonsense embedded in the book . More tragic is the notion of a whole set of practices to solve the "software crisis" built on this "labelling". Some of it is just common sense. Most of it is just misguided, intellectually unsound rubbish.

Thus two separate concepts of "apprentice, journey man and master" --one, a rough measure of skill , and two, artificial "labels" used to recreate an outmoded economic system-- are conflated. Now let us look into the guild system from which this terrible classification scheme is borrowed .

From the wikipedia entry for "Guilds" ,

" The guild was made up by experienced and confirmed experts in their field of handicraft. They were called master craftsmen. Before a new employee could rise to the level of mastery, he had to go through a schooling period during which he was first called an apprentice. After this period he could rise to the level of journeyman." This is almost a word for word description of the system McBreen wants us to replace present day practice with . Let us read further (the wikipedia article, not the book ) . " Apprentices would typically not learn more than the most basic techniques until they were trusted by their peers to keep the guild's or company's secrets. ".

Duh ? secrets ? "Journeymen were generally paid by the day and were thus day laborers. After being employed by a master for several years, and after producing a qualifying piece of work, the apprentice attained the rank of journeyman and was given a letter which entitled him to travel to other towns and countries to learn the art from other masters."

duh right . Does anyone else feel an increasing disconnect between the socio economic situation in the 14th century vs the present day ?

Continuing to quote "After long periods of apprenticeship to a master" ( an apprentice had to pay for this privilege !What do you think of having to pay a "master" or "journeyman" to learn programming? ) "and after producing a qualifying piece of work, the apprentice attained the rank of journeyman and was given a letter which entitled him to travel to other towns and countries to learn the art from other masters."

entitle him to travel ? a qualifying piece of work ? duh?

Now let us give Mr McBreen's ideas the best possible interpretation and decide that your "level" in software needs to be demonstrated, say by showing samples of your code , maybe your contributions to open source, before you get a job. Will this miraculously improve the success rates of projects ? Not at all, because the problem is that the need for programmers is well above what can be met by the "truly skilled" minority . If less than say ,250 people worldwide are truly "masters" and say another 3,000 or so of "journeymen" status in, say, Tennis (going by ratings and being generous) why should there be a greater number in software development ?

The difference is of course most people who play tennis do so because they at least minimally enjoy the game! To think that adopting some half baked scheme based on an ill defined outdated idea will raise these numbers(which is about the only way to "solve" the software engineering "crisis") is , at best , self deception and at worst .. hmmm ...let us not go there .

In other words the "software problem" is economic, not technical in nature . Unless a compelling economic argument can be demonstrated for this switch to an out moded way of "improving" programmers , the only readers of this book are likely to be the mediocre programmers who fantasize about achieving "master" status and earn 250 k $/year (as Mc Breen reccomends) .

Note to Mr McBreen . People who are that good are already earning 250k or more!! so what was the problem again ?

Pete has written another half baked book on "Questioning Extreme Programming ".Far be it from me to say that XP needs no challenging , but this book does such a shoddy job, setting up and destroying a sequence of strawman arguments that wouldn't stand up in a high school debate,that you'd be surprised publishers would let this through their editorial board .

Anyway if you want some good ideas on how to become a master programmer , go read this article . It has more wisdom in it than Mc Breen's Book of Mumbo Jumbo.

So what is my take on this "apprentice,jouneyman,master" trichotomy ? Well I believe that in these days of universally available internet access and open source software any half way decent programmer is aware of where on the skill scale he (and any of his fellow programmers) falls , in any given context . Taking these "rating" labels seriously (for eg: on a site like Advogato,where you can see comments like " hey i became a journeyman while i wasn't looking !! wow ! " ) is, at best, like wearing your karate belt over your street clothes, to advertize your fighting skills .

As Bruce Lee said ,"On the street, no one asks you your belt before they hit you " .

Translated to the software development domain, that means

"shut up and write code" .

Mack on Management

My last post drew a very articulate comment from Chandrakant .

Chandrakant brought up the idea of being an XP Coach as being the right way to do management .

This is a very intriguing idea . But in my experience the people who were excellent xp coaches formed a distinct set with little overlap with the set of really good managers.

I think Chandrakant is on to a good idea here .It is just that I was unable to articulate where an XP Coach crosses the line and becmes a manager . So i did what i usually do when I'm stuck. Ask someone who knows .

Mack C Adams,who I had the pleasure of working with in TW and is a really good manager, comments on this whole "how to judge a manager" meme . (liberally paraphrased from a yahoo messenger conversation, with Mack's permission )

" Me: ahh just the person I was thinking of .. you got a couple of minutes to spare ?

Mack : shoot - just got back from an hour of military fitness training...so, if things go quiet, then I've passed out in my chair! Me: --- explains what's been happening -- asks mack to look at the comments etc ...

Mack: hmm...both comments (Chandra's comment and your reply) on your post are quite good

Mack: for me, I would definitely distinguish between XP Coach and Project Manager ("manager" is a very vague term). XP Coach is akin to an Iteration Manager - in my view, the best ones are technically competent process tweakers

they spend half their time coding, and half their time tracking though, I suppose a coach doesn't have to be the IM

me: and what does a manager really do ? I have a hard time pinning this down

Mack: Conversely, the whole "manager" thing is tricky - I think you should try to get away from "manager" as a role, and see it more as an activity along with facilitation; planning; communication; organization

For me, as someone who's not technical, I get scared when I'm too close to heavy work, as I'm flying blind - I need to depend on trusted technical people not to screw me over, and so I build an intrinsic desire in the team to succeed - I work on the team first - feeding it, protecting it, directing it, and letting it do its thing

Mack :Once I got myself intro trouble since I'm actually not very good at meticulous planning (Grinding out a project like a good tech pm should do [Ravi's comment :- Don't you believe this. Mack si the most organized person i have ever seen ] ). I'm trying to use the word "orchestration" to describe my skillset - broad base of knowledge, big picture, looking/anticipating for opportunities and enabling (sorry about that word) the team to succeed .I think great managers create high performance teams; good managers try to do the work.

Me : so i guess one way of judging good managers from bad is to look at the sucess or otherwise of their teams ?by success i mean not only project out comes but also things like how happy they are ??

Mack: : ultimately, that's the only baromter.

it should be holistic - a happy team that doesn't deliver is going to get fired; and a delivery team that isn't happy is going to quit "

ok so there you have it from a guy who actually walks the talk . The success criteria for a manager is the same as the success criteria for a team including the happiness of the team in their work.

Now when you are hanging in there, grimly holding on for your green card to come through ,"quitting" isn't really an option i guess, but that arises from an exported desi's chosen response to a bureaucratic rule .

Given that 99 % of IT projects are terrible for the client , the team , or both, I think it is self evident that there aren't that many good managers around .

Also I wonder how much sense this definition of management makes in the "outsourcing == terrible projects" scenario ? A manager is bound to fail if the happiness of the team is a factor . Hmmm . more questions to ask Mack ..

Mack went on to say

" man, I need to get a blog! really have no excuses, as I do have much to say...so lazy...London makes you weak with its vices! "

yeah Mack you should tone down the partying and start a blog !

How shall I judge a suit - Part 2

In a comment to another post on this blog, Sundaresh asked,

"Ravi......i give you a problem statement and a laptop and ask you to write a piece of code and looking at that, i gauge your worth. Thats an excellent/good/bad programmer. What is a good manager ?"

And that is a good question. I have not been able to articulate a satisfactory answer for this and that is scary .

There's no way to judge a middle manager and they are all over the place ! Anyway this was my reply (slightly modified to include a few post-reply thoughts ).

" Sundaresh, That is a very good question.

There is a lot more to judging programming skill than handing a laptop + a problem statement to someone .

But I digress .

The gist of your question of your question seems to be "is there an objective, externally verifiable way for judging a manager's ability ? "

Except in the case of frontline managers like CEO's and marketing/sales managers or operational managers of a factory floor, who can be judged by numbers attached to their performance (market share, eps, operational efficiency ) , the answer is no, there is no externally verifiable measure . In other words there is no "laptop" you can give someone and ask them to display their skills.

This is precisely why a lot of people can get away with what , in Thoughtworks India jargon was called "PM giri"(a word approximating "PM ing " for non hindi speaking readers of this blog) as in "PM giri is no big deal".

Having said that ,there are a few heuristics(by definition a heuristic is not infallible) that I look for when I judge managers.

1.Is he/she extremely good at any activity beyond "managing" ? Of the truly excellent managers I have met, all of them without fail were skilled in something besides "managing people " (as in the movie "Office Space" :-) )

One is a decorated Combat Helicopter (Apache LongBow) Pilot. Another is a world class writer and athlete. One is changing the model of how charitable organisations work .Another is an excellent musician . Somehow the habit of excellence and the consequent ability to recognize it in other fields seems to make a difference.

Some examples from the outside world. Larry Ellison is probably an excellent manger .He is a world class sailor.

Krishna Bharat (India head, Google) is probably an excellent manager . He wrote Google News.That gives you a lot of confidence in his understanding of programmers and programming.

Now this doesn't always apply. Linus Torvalds is good at coding but by his own account he tried "managing" a project and was a big failure.But then he "manages" the kernel development effort very well. hmmm...

This is why this is just a rule of thumb.

This pattern is surprisingly persistent though .Even managers who are not yet at the height of their powers but are climbing the ladder show this trait . One of the managers i most respect was in IIT grad(says something about his intellect ) ,and ex techie who was put in charge of the India Office of his company. He used to say with genuine regret " I am losing my technical skills" . Yet another was fanatic about physical fitness and superbly organized. His projects would run like clockwork and he would sit quietly in a corner filling up crosswords !

2.They are highly spoken of by the people they manage .

Invariably the best managers are those whose subordinates worship the ground they walk on . This is not about popularity but about respect .

If a programmer rolls his eyes and looks heavenward when speaking about his manager, that is a strong warning sign . The age of the "command" paradigm in management is over. Nowadays , to effectively manage, People have to willingly give you their best . Again using my Thoughtworks experience there were managers who were so effective that the team thought of them as "one of their own" and others about whom people would make snide comments when they were not around .I am sure this is true worldwide and not just in Thoughtworks.

3. In the software industry , most (but not all) of the best managers are ex hackers or people who like technology .The top grade managers who are not techincal genuinely respect the wisdom of the technical people

4. Good managers *always* protect their team from the politicking that goes on .If a manager being added to the team *decreases* the politics , that is a good sign.

5. Not a single good manager in the software industry I know likes ISO/CMM style processes.They may quietly live with the process and work around it when necessary but if someone likes and enjoys these heavyweight processes I would be very wary of hiring him .

I could think of a few more characteristics but you get the idea . There is no sure fire way of determining the worth of a non frontline manager but in any industry or company there are thngs to look for .

I am interested in your heuristics for judging managers .What do you think ? what are the characteristics of the best managers you know?"

Sundaresh replied

"That was an excellent analysis. In my experience, i have worked with 11 project managers, out of which all but one were perfect charlatans or incompetent. Few things i have noticed in the one person whom i would rate as "very good" were,

1. As you said his subordinates "worshipped the ground" he walked
2. If anything was slipping out of our hands we could always call him and he wud run to us in a jiffy
3. The place he hated the most was his cabin. He could be seen walking around, sitting with developers and in some cases even testing the application
4. He made the strict hierarchy look very fluid.
5. I worked with him for 3 months ( he came in to replace a PM when the project was in crisis and left after 3 months when the project was delivered successfully.)
6. We were never in the firing line. He was the shield
7. He even used to participate in the technical meetings and showed a keen interest there in.
8. One thing that is common to the worse managers i have seen is that they remain cloistered in their cabins and always try to impose the feeling that he is the boss.

Sundaresh identifies a "pattern" (sorry Dave, :-D ) I missed. I'll call i "Cabin fever" .One of the most impressive things about Thoughtworks was that when Roy( the CEO) visisted Bangalore , he would avoid all the "cabins" and just find the first empty chair and plug in his laptop and go to work .A very refreshing change from the Indian habit of alloting cabins, "corner cubes" etc to "senior " people.I didn't even know he was the CEO the first time he came in . He started questioning me about how things were going and what I as new recruit thought of the company ,and i wondered "Who is this crazy old man ? " .Later , when he climbed on chair to address the staff meeting I asked someone who he was and was told he was the CEO.

For all the "Indianization" of the Bangalore branch, if you haven't worked in Thoughtworks, you should ! If anyone reads this blog and applies to TWI , please tell the HR folks i'll be around to collect my recruitment bonus !

I once joined a company (which shall remain nameless) where the first day I reported to work , the receptionist and a few other people stood up , snapped to attention and said "Good Morning , Sir" in unison (like kids in kindergarten greeting their teacher! ). I was shell shocked and asked them what was happening and they said they were under instructios to treat me as a "senior" person . Later I was taken aside by the owner/ceo who informed me that we have to make the whole office aware of seniority for "increased discipline". I quit the same day (though i didn't have a job in hand ). Thankfully I had a friend in Aztec who forwarded my cv to their HR and i got a job there the very next day .-- wiping sweat from my forehead-- Thinking of this event still gives me goose bumps.

To finish, I will ask the question i asked Sundaresh

I am interested in your heuristics for judging managers .What do you think ? what are the characteristics of the best managers you know?