Professional Programmer and Domain Knowledge
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.