Lost in translation? Stop using different languages.

SD Times recently published a hip article entitled “Lost in translation“, which does a great job of profiling the long standing disconnect between those that define requirements (i.e. stakeholders) and those that implement them (i.e. developers). As the article points out, developers and stakeholders

spring from very different worlds, and every time a customer approaches a developer for an application, those realms are poised to collide.

Indeed, baby! Just as a popular book aptly pointed out that Men are from Mars, Women are from Venus so to, in this Age of Aquarius, are stakeholders and developers different! You could easily say that stakeholders, who speak in normal everyday language, are from Earth, while developers, who are able to speak in code, which is mysterious to everyone but those that have coded before, are probably from a different solar system all together. You see, when it comes to normal language documents that define requirements there is an impedance mismatch once those requirements are translated into code.

And this mismatch creates

gaps in communication and understanding [which] can result in frustration on both sides of the fence. Users get frustrated because their requirements are not being met…

The article goes on to posit that the solution to this issue of translation is

open communication, sharing of information and plain old accountability.

Which, of course, no one is going to disagree with; however, there is a more direct solution to the problem: if there are issues with respect to translation, then stop translating. That is, stop speaking different languages, man!

Case in point, in the aforementioned article, the author points out that Microsoft actually relies on a resource to translate aspects of requirements–

Rollison said Microsoft relies on program managers to translate customer needs into reasonably unambiguous requirements and build prototypes early in the design phase. “Relying on developers to design a software program would be similar to relying on an engine mechanic to design a car,” Rollison said. “Engine mechanics could probably design a car with some really cool bells and whistles, but the only truly satisfied customers would be other engine mechanics.”

While I don’t dispute the fact that some developers would, if left to their own trippin’ devices, build something really slick but totally worthless to a business, I’m shocked that rather than bridge any gaps in communication, one company chooses to throw more people at the problem.

With the advent of dynamic languages and the popularity of copasetic domain specific languages (or DSLs) frameworks are already here that attempt to bridge that stakeholder-developer gap by making code read more like normal language. This is not to say that all of a sudden trippin’ stakeholders will start writing code. No, the implication that DSLs read more like normal languages, such as English, means that developers can more aptly collaborate with stakeholders as when developers ultimately start coding (in Java, etc) they have the normal language descriptions of what they should be coding on hand.

That’s where easyb comes in! By using a specification based Domain Specific Language, easyb aims to enable executable, yet readable documentation. With easyb, software teams can verify the behavior of anything written in Java in a more natural way; that is, the verification is done using the customer’s own words. Consequently, there is no impedance mismatch between those that write requirements and those that implement them. In essence, easyb helps bridge the gap between stakeholders and development by using a language that everyone can understand. In fact, with easyb, the requirements (or specifications) are literally joined at the hip with the code that’ll implement them.

By using a more natural language that is closely in tune with stakeholders, a more collaborative platform is unfolded that permits both parties (i.e. developers and stakeholders) to talk on the same level. By doing so, the traditional bogue ambiguities and misunderstandings that have plagued software development for years have a real chance of being overcome. Of course, there are no silver bullets in software development and easyb isn’t positioned to be one; however, easyb represents an evolutionary step towards that goal of more human centered software development.

If you find yourself plagued by translation issues, don’t throw more people at the problem, man! Instead, see if you can obviate differences in languages by speaking the same one! Let your stakeholders tell you in their own words what they want! Sure, they’ll skip a myriad of things, like non-functional requirements; however, those can (and should) be accounted for by technical folks.

As the article points out

In the case of agile development, focusing early on mismatches between requirements and specifications is a good thing, said Augmentum’s Hom. “Accept that development is iterative. As development proceeds, it is imperative to have fairly frequent software builds for users to validate that progress is happening as expected. One reason is to enhance confidence. But also there is benefit to finding any misinterpretations or implementation deviations in smaller chunks, so the corrections are manageable, instead of at the end in the ‘big ban’ final user acceptance release.”

Indeed, you can let your users speak their language and eat your cake if you accept that change is inevitable and you work in short blocks of time allowing for frequent feedback. Big systems and legions of people to fix the translation problem is overkill and indicative of waterfall-like thinking. Embrace collaboration and use a common language. It is actually that easy. Can you dig it, man?

You can follow thediscoblog on Twitter now!