InnerWorkings Blogs

In this post, Jimmy Nilsson observes that using a ubiquitous language poses a problem when working in a business based in a country where English is not the native language. Customers typically use their local language, but he prefers writing software in English.

My view is that programming in English is not a matter of preference only.

Before moving to Ireland about 5 years ago, I worked for a few companies in Italy, including a very successful firm in the field of software automation. Using Italian names for classes and operations seemed like a good idea at the time…until, a few years later Siemens A&G bought us!

Add this post to:             

In the book titled ”Domain-Driven Design”, Eric Evans suggests that one of the fundamental ingredients of effective software modeling is the deliberate adoption of a shared language between domain experts and software developers.
Such a ubiquitous language develops as the understanding of the domain evolves.

The idea is that by eliminating the linguistic barriers between different groups, we enable the creation and refinement of a rich model that embeds the language in code.
This model should be sufficiently expressive to support both domain experts and developers in their communication of rules, requirements, etc.

I’m still not sure about the feasibility of such approach, but don’t get me wrong, the objective is certainly admirable. My fear is that our capability of building a ubiquitous language on which our model should be based is inversely proportional to the number of individuals and groups involved in the effort.

Each member tends to have only a partial view of the domain (including domain experts!). Each individual has different mental maps about how things are or should be.
The process of creating and sharing both language and underlying model could face challenges similar to the ones that experts find in an enterprise when adopting a shared database strategy or a global canonical model: it’s very hard to do properly (trust me… I know.).

Are there valid alternatives? I don’t know for sure. Use cases, for example, are great at bridging the gap between domain experts, users and developers. But admittedly they are not of huge help in all situations and they give limited or no support for validating models and business rules.

Whatever style we adopt for gathering requirements however, it is important to keep the right attitude, and learn the most important skill of all: the ability to listen.
The biggest failures in software development often happen when developers or analysts don’t question their mental maps enough to ensure that those accurately reflect reality.

Add this post to:             

SD Times

By David Rubinstein, SD Times
May 1, 2005

How do developers like to learn?  Many read books that are relevant to their practice. Others rely on co-workers or developer Web sites to pick up tricks and shortcuts, and still others attend technical conferences to learn from the vendors of the software they use.

There is, though, one thread that runs through all the choices: Developers like to learn from other developers. Don’t give them academics. Don’t give them so-called  “experts” in a field. And for heaven’s sake, don’t give them marketers.  Developers truly believe that unless you’re a developer or you’ve been a developer, you don’t know the trouble they’ve seen.

Fran McKeagney learned this while at CBT Systems, a California-based company providing interactive education software. “We had a hard time reaching software guys,” he said. “We just weren’t getting usage with the software guys.”

When he founded InnerWorkings in 2002 with the goal of providing educational tools for developers, he learned his audience had been rejecting training materials written by technical writers. “It was clear to the developers that these people didn’t make a living writing enterprise code.” The learning industry just didn’t adequately support the developers, he said.

Since that time, numerous educational and training Web sites have arisen, and books and downloadable tutorials remain plentiful. Attendance at technical conferences is finally rebounding to levels not seen since the dot-com implosion. Many of these are created by developers for developers. JavaOne, Tech-Ed and myriad other user conferences provide hands-on learning. DevX, IBM’s alphaWorks and MSDN all have large, thriving developer communities. But McKeagney says something was lacking - the ability to work at your desk, in a tool you use, at your own pace, to improve your skills.

Something else was missing, he believed - a way to get a developer from the competency he or she showed to get a job to becoming much more effective on the job. “Classroom teaching is conceptual,” he said. “It’s like reading a book on building a house and then going out and doing it.” Developers, they learned, are being challenged like never before, being asked to “do more with less” even if their skill sets aren’t quite up to par in certain areas.

So McKeagney and his team developed software called the InnerWorkings Developer Interface, which includes something they call the Inferent code-judging engine. The software provides users with challenges that describe the objective and offer a problem statement, and the developer builds the application and runs it. There are constraints as to what not to do as well as links to reference materials, hints and an e-mail link to a personal tutor.

After the application is built, the user clicks on the “judge” button, and a score is returned. If errors were made, very specific feedback is returned. “It’s a safe learning environment, but it’s real-world,” said Brian Finnerty, director of product marketing.

InnerWorkings has collaborated with Microsoft to integrate its software into Visual Studio. The first practice set of challenges deals with developing for ASP.NET; currently, there are eight hours of coding challenges, involving such topics as Web controls and exception handling. By the end of the year, the company hopes to have hundreds of hours of practice sets; Finnerty said the next sets in the works are for Web services and object-oriented design and development.

For people worried about having a development process forced upon them, McKeagney said the reference materials and judging engine are based on Microsoft Patterns and Practices Group information and the Microsoft curriculum. In the future, he added, the tool might be able to accommodate a company’s best practices, so that the training of new employees becomes more standardized. Armed with US$8.8 million in Series A venture funding, that should happen sooner than later.

Listen, I certainly understand people who hate being forced to change the way they do things. I started in this business writing my stories on a Royal manual typewriter. Then I was forced onto an IBM Selectric, which had a unique set of characters that had to be typed into the text to instruct a scanning machine what to correct or omit.

Since then, I’ve had to learn a number of different applications, each with different nomenclatures and symbols for typesetting instructions. And I went kicking and screaming every time. If it were feasible, I’d go back to my manual typewriter in a heartbeat. Has learning these different systems made me a better writer? Microsoft Word certainly has made it easier to clean up my mistakes, but it doesn’t help me with story organization, sentence construction, or those colorful turns of phrases we writers live for. But it hasn’t hurt me either. So if learning some new best practices can make you a more efficient programmer, without hurting you from a creative perspective, the benefits are clear - if not to you at first, then certainly to your company. Old dogs, like the one seated here, can always do with some new tricks.

David Rubinstein is editor of SD Times. This article was reprinted with permission from SD Times May 1, 2005.

Launch Article (PDF)

Add this post to: