Protos' Musings

"In the long run men hit only what they aim at" — Thoreau

Professional Programmer and Domain Knowledge

with 4 comments

I have been working as a programmer for a little over 5 years now, and it was with great interest that I read the article What is a Professional Programmer, written by Sarah George, and hosted at DeveloperDotStar Magazine.

I think I can say that I have been on the right path so far when I evaluate myself on the various parameters she has mentioned, viz., trustworthiness, teamwork, leadership, communication, constant updating of skills, an interest in minimizing risks and accountability.

However, there was another theme running right through that article, the theme of “how much Domain knowledge you need to do good Software Development?”. It was triggered by this comment by Mario Van Damme, to which Andy Tegethoff posted a great reply. But Andy didn’t just stop there. He followed it up with this wonderful post on this topic.

I have been of the opinion that Domain Knowledge just cannot be the be-all and end-all of Software Development. Yes, one needs to know enough of the domain to make sense of what one is doing, and what the client is saying. However, the current trend in the Software market in India (and probably elsewhere) is this: an average candidate with average-to-good domain knowledge is a better bet than a good/great programmer with almost zero domain expertise. During screenings and interviews, I have often experienced this line of thought in action. The argument is something like “programming anyone can do[!]; but to get guys with domain knowledge is very difficult”.

So, one is considered a better/worthy candidate if one is having previous working knowledge in a domain. And sometimes, the programming skills takes a clear back seat since this new guy is average-to-good at domain. Of course, domain is where the money is (meaning you get paid more).

What these recruiters forget is the basic fact that you are recruiting people for doing software development, and not to look after your domain/business. In fact, as established by Extreme Programming school of thought, it is much more valuable to have a true blue Domain guy (the actual Customer/Client or someone representing him) in the programming shop with good programmers than to have an army of domgrammers — short for domain-oriented-programmers. After all, most of the time, you just can’t become great at a domain in a short span (say 1-2 years) without sacrificing your programming skills. Of course, I am talking about normal people here. As the rule goes, “there will be exception to all rules, except this one”!.

In one of my previous projects, there was this culture of “anyone can do programming; understanding the domain is what it is all about” logic. I was really amused and shocked at that line of thought, but thankfully, I never subscribed to that school.

Towards the end of my first year in that project, we found out that the most critical module of that project was causing a hell of a lot of problems. We also found that there were serious design flaws and hell of a lot of bugs in that module. Luckily, I was learning Refactoring, UML and Design Patterns at that time, and my design skills were good at that time (or at least I thought so :). During this time I was looking after that buggy module and so was spending lot of time fixing bugs and logic-flaws, that just should not have been there in the first place.

I took it upon myself to set the house right, by re-designing the core of that module, and doing enough refactoring to change the design. After “some” struggle, I managed to convince my boss(es) that this is the only way to do it and that I can really do it. Remember, I was still considered one among the juniors in the team.

By this time, client was also breathing down the bosses’ throat to solve the highly critical bugs in that highly critical module. So, at the end of it all, the boss(es) agreed to allow me a free hand in doing what I wanted to do.

I was able to come up with a new design, and then refactor the existing code to fit the new design framework. It was not refactoring actually — though I used it a lot — since it involved a change in the behaviour; after all I had to weed out the bugs. During this process (which took me about 3 months) I had to talk to the client scores of times, communicate the design to the team, do lots of coding and teaching, explain the design to the boss(es) and client etc. I thoroughly enjoyed the experience.

I also understood that no matter how hard I try, I can never match a pure domain guy’s depth of knowledge. Also, it is not useful too, since I can easily learn from them. In the process I also learned that it is pretty hard for a software guy to be as good as a real domain guy, who is breathing the domain day in and day out.

More importantly, had I fooled myself into believing — during my initial days — that learning a few hundred terms and definitions of the domain will make me a better programmer, I would never have been able to come up with the new design.

Just thought will post about one of my core beliefs — that technical knowledge is a hundred times more important for a programmer than domain knowledge.

But of course, the fact remains that I am paid and will continue to be paid less than a hot shot domgrammer or Business Analyst. But that is ok, since I get to do, what IMHO is, the most challenging task of converting what is required into a great design/software that provides the solution.

Of course, Dan Read offers his point of view here on this topic, and as always, it oozes with pragmatism and common sense. But yet, it is difficult to miss the message that in 90% of Software houses, domain knowledge is only that important.

Thanks for reading thus far. It will be really great to get some feedback/comments. Have a great week ahead.


Written by Proto

April 24, 2006 at 01:02 hrs

4 Responses

Subscribe to comments with RSS.

  1. You have hit the nail right on top of its head! Fortunately in product company like us domgrammers have no role. If you are technically fit you are in else out; and emphasis is on “Hands-On” rather than “Tongues-On”, and flamboyant language and bombastic words about domain concepts just doesn’t sell and rather a SQL tuning code or Factory Pattern idea gets more respect.


    April 24, 2006 at 10:39 hrs

  2. Just to add, it depends on where u work – as Arun says, at his place that may be the way to go – after all thats a technology company – but in a typical solutions company it is the BA’s who get paid more and beyond a point there is a convergence between tech and domain expertise.

    The point is domain knowledge is required at the higher level – for instance when u start building systems from scratch – i dont mean design.. – a certain minimum understanding of the domain is a must. If not, why do we have architects , consultants for each specific domain. Specialists as they are called – some be default …some by choice.

    And Suresh, how come u switched “again” to the mantra of “ doesnt matter.. since I get to do, what IMHO is, the most challenging task….”.


    April 24, 2006 at 14:39 hrs

  3. PNS,

    Thanks for the comment. I think you completly missed the point on this one. I was not arguing against the worth of having a BA or a Consultant. What I was arguing against was the tendency to expect your programmers to be good to great at domain, which is more of BS than anything else.

    I think I am a good (not great) programmer, and so far have worked in both Healthcare and BFIS, and I never had any real difficulty in picking up what is required to deliver what is required. I think it is one of the biggest fallacies of our times to require core technical guys to be good at domain (when you recruit them).


    Thanks for the kind words. Great to know that you too think about this in a similar way. Of course I remember the story of I and G from the yore, posted in your blog.


    April 24, 2006 at 23:32 hrs

  4. Suresh, I guess you are right…I too have heard so many people say “anyone can do programming”. But trust me, all those who say this consider that programming as a group of for loops, while and if statements. They hardly think about design.

    It would always be good to have a good blend of domain and programming (giving more weightage to programming). Probably the domain is included here because, when the programmer designs his program, (s)he can kind of predict the enhancements that might come up for that module.


    April 26, 2006 at 10:14 hrs

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: