Wednesday, January 26, 2011

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!

No comments:

Post a Comment