Do we developers care about the business domain we work on?

Do we developers care about the business domain we’re working on? Or should we developers care about the business domain we’re working on? Domain knowledge for a developer is mostly a nice to have (and not a must have) entity. Sure, a developer with absolutely no knowledge about the domain can write good quality code incorporating all the patterns and best practices that are.  But can he/she produce a high-quality product? By product I mean here a ‘system’ or an ‘application’.

What happens when a developer tries to understand a business domain? Lot of knowledge transfer sessions take place between him/her and the functional guys/gals. Such a session typically includes lot of talk or lot of presentations flying around. After many of such meets, a developer begins to grasp the mechanics and dynamics of the domain. Super! He/She feels better equipped and motivated to do the task at hand. With that high-note, he/she begins reading the functional specs of the first use cases defined for the system. And most often to his/her utter disappointment, he/she realizes that not only are the specs ‘not complete’, but also wouldn’t fit together to make a 'complete system’. What happens then are more discussions where he/she tries to convince the functional specifiers of his/her findings. And before they all know it, the project is already running late resulting in enormous pressure on development to deliver working software. So was the whole need to understand the domain worth it!

The reason why this situation arises over and over again is due to the utterly bad tooling our functional specifiers use. Although these are the guys/gals who really understand and envision the system, they have no feedback on whether their specifications are complete and whether they end up in working software. More agile methodologies to software development have made this feedback cycle shorter, but it still exists. Wouldn’t it be nice for functional specifiers to have the tooling which validates their work? A tooling which guides them to a complete, working system. Some of you must have already guessed it. Yes, I’m talking about DSLs (Domain Specific Langauges) or DDD (Domain Driven Development) here. Languages which understand the domain and help specify it. This would remove that extra overhead and feedback loop.

Does this mean that the developers would be out of jobs? No, only now their time will be spent in developing these DSLs. This gives an opportunity to everyone to excel in their own discipline – the functional specifiers in the business domain and the developers in development. And also results in software which is tightly coupled to its specifications. A win-win-win I would say!

Motivation

When I started my career in IT back in 2004, I was a university graduate wanting to learn industry ways of developing software. The first years passed doing exactly this. Most of the methodologies learnt in the university were put to practice and I had a good feeling about this. Those were the times of ‘prime motivation’! Senior colleagues inspired me to work harder, gain knowledge and most of all have fun in developing software. My answer to college mates or fellow colleagues who would switch jobs for a higher salary was, “I’m learning a lot and enjoying what I do. I do not wish to change jobs”. Somehow these aspects always seemed more important to me and something which my fellow-mates did not always get.

Recently I read about the book ‘Motivation 3.0’ and saw one of the Ted talks on motivation. Both references prove that the ‘carrot and stick’ approach doesn’t help in getting job done faster; on the contrary this approach results in a bad performance. This approach results in people having a restricted line of thought. Projects like the Wikipedia are successful today since they bring out the best in people. People, by nature like to contribute, gain knowledge and attain mastery. Just having an environment which sees this and promotes this would suffice. Any other stimulants would not be needed. The best ideas in Google came about in the 20% free time that they have for their employees.

When I read about these, I said to myself, “Duh! I knew that. That’s common sense”. But then “Common sense isn’t that common”, one of the favourite quotes of one of my colleagues. The money-driven system is one of the root causes of the ‘lack of joy’ in one’s work today. We know that some of our needs come with a price, and often that price is our 40 hours in a week. One cannot put a price-tag on motivation. Motivation should be a continuous feeling and something which will take one through a long career. Motivation comes with the thirst to mastery, desire to do better and purpose. I know of an Indian film industry actor who refused receiving any film awards, but still is one of the most motivated fellows out there. Every movie he makes is a work of art. This world would be a different place if everyone steers or steered to making every piece of work they do a ‘work of art’!