Polyglot Programming

I have been reading and thinking a while about Polyglot Programming. Polyglot programming means using multiple programming languages in an application or project. Now that Microsoft has introduced the DLR and is improving tool support, implementing polyglot programming on a single platform (.Net) is becoming easier. Using the right tool for the right job, the rationale for polyglot programming, is getting possible without a proliferation of operating systems, IDE's and other supporting tools.

The promised advantages of polyglot programming are compelling: greater productivity and better maintainability. Productivity will increase, because you are no longer restrained by the restrictions of one language. Some problems are easier and faster to solve using a different language. A consequence is that maintainability also increases: easier solutions are easier to maintain.
One of the disadvantages of polyglot programming is tool support, or the lack thereof. Microsoft's efforts to create one IDE for developing in different languages is trying to tackle this problem. Visual Studio 2010 and the .NET Framework 4.0 allow developers to use static and dynamic languages in their .NET projects and make it easier to create (internal) DSL's.
Another disadvantage is the need for knowledgeable personnel. Knowing when and how to use a language is imperative for the success of a polyglot programmer. Learning these languages can be hard and asks for the willingness to learn. Some even think you should learn a new language every year, though this is not always practically possible.

So, in a business sense, is there value in promoting polyglot programming in you organization? There is not much scientific evidence of an increased performance through increased productivity and maintainability by using polyglot programming. There is one exception: a case study (via Ola Bini) by Hans-Christian Fjeldberg found that productivity and maintainability increased. He also found that the knowledge disadvantage was not perceived by developers themselves, but was by management. He suggests that organizations restrict the language choice to a few options, like Google seems to do. I suggest using one platform, preferably .NET, that supports multiple languages. Being able to use the same tools for different languages makes it a little easier to learn and use a new language.

Office Layout - Going Overboard with Open Spaces

I have the feeling that the use of big, open office spaces is a continually growing trend here, and I'm not a big fan. Don't get me wrong, I'm not a fan of one man offices either, as they are inefficient and ineffective in a team setting. But I'm not convinced that the way the big office spaces/war rooms often are implemented is the way to go. I'll tell you why.

The advantages of an open office space

A great deal of companies I've worked for have implemented this kind of office layout. Whole floors of buildings are free of walls, apart from some meeting offices, having multiple teams located in one big room (if you can speak of a room). Why do companies do this?
The arguments for this office layout, sometimes referred to as "radical collocation" are obvious: improved communication among team members, improved problem solving and improved learning. Multiple studies have proved these arguments, see the references in this post. So what's wrong?

Were does it go wrong?

It's the way companies put the idea of a collaboration-enabling space to use. I see companies going way overboard with this. This leads to two problems in my opinion. As I mentioned, some companies turn a whole floor into one big war room. Such a room is noisy and distraction is all around. This is the first problem in a war room. I think there is an upper limit of the number of people in one room after which focus, concentration and communication get more difficult because of distractions. What's even worse is the fact that companies place multiple teams doing unrelated things in the same room. More irrelevant communication takes place and adds to the distraction.

The second problem I see is the office culture. Companies change their office layout but do not change their culture. They don't enforce or even encourage some 'rules of conduct', leading to ad hoc meetings in the room instead of in an office, people making phone calls in the room, and doing their personal business in the room, which all add to distraction.

Solutions

The solutions to these problems are respectively finding a balance and implementing a whole concept and not just one facet. I also think that the principle for using the right tool for the right job applies here to. Observing the reactions to the question "Cube or office" in the Joel on Software forum a war room is not always preferred. Are you sure a big open space increases your productivity? If so, use a room for one team and create a culture in which distractions are minimized. For a great post on an office layout specifically for (agile) software development teams check out the earlier referenced Ultimate Software Development Office Layout.

I think using the right office layout and the right software development methodology (Agile for instance) can greatly improve your productivity and your work's quality. Ofcourse, the right solution depends on the context.

Logoff Anti-Pattern

At the company I work for the time management system uses a problematic logoff solution. A logged-in user signs off by clicking a link, which displays a javascript dialog box asking for confirmation. When choosing yes, a popup window is opened that performs the actual logoff functionality. The problem is that this popup window is blocked by popup blockers, and the user is not logged off. Naturally the browser shows a visual clue that a popup window has been blocked, but this is easily overlooked, leaving users logged on, while they think they're logged off. This ofcourse poses a security threat, one that easily could have been avoided. Don't use a popup to sign a user off!

Value Mapping (Flattening) Functoid Troubles

A while ago I was troubleshooting a BizTalk solution my company created. This solution facilitates the communication between a CRM front-end and a commonly used municipal back-office system. I had not created this app, so it took me a while to figure out what the problem was. The trouble was that something went wrong in one of the maps. Some messages that went through the map were correctly processed, while others weren’t. Here’s the map (click to enlarge):

The map's functionality

The map transforms a response of the back-office to a message format the CRM system understands. It’s quite straightforward; the input schema contains a root element that in turn contains one choice element. The options for the choice element are three (although one of them isn’t used, don’t ask me why) tree structures that are the same, except for their names. Scripting functoids are used to concatenate some fields (and do some other stuff) from the input message and the result is fed to Value Mapping (Flattening) functoids. These functoids have two input parameters: the first is the result of a Logical Existence functoid that checks the existence of one of the choice elements, the second contains the concatenated values of some fields. The result of the Value Mapping (Flattening) functoid is the second parameter if the first one is true. So to summarize, the map checks the existence of the choice element options and when the element exists maps the concatenated values of some fields in this element to the output message.

Problem

The weird thing was, that only messages with the BinnenVerhuisaanvraagResponse element (excuse my dutch) were mapped correctly. When a message contained an UittrekselaanraagResponse element, the output message missed the mapped fields (should be in the InputData field of the output message). This was very strange, because the messages were identical, except for the names of the choice element options. Also I double-checked the functoids, but they were again the same.

The Value Mapping (Flattening) functoid

What had caught my attention briefly earlier was the use of the flattening version of the Value Mapping functoid. This version flattens a tree structure input to a single field. The input of these functoids in this map however is always a single value from a Scripting functoid. Maybe the reason was that in an earlier version the Scripting functoids weren’t used, but the input fields directly, but that’s just a wild guess. Anyway, in this case there is no need for the flattening version of the Value Mapping functoid. So I replaced these with the normal Value Mapping functoids, ran some tests and hey, all messages are processed just fine?! I could not find anything on the net as to why this happened, I might have stumbled on a bug here, although I have not tested this error in other environments. So, be aware of this when using the Value Mapping (Flattening) functoid in source schemas containing choice elements!

Avoid the alignment trap

I stumbled upon some very interesting research by Bain that studied the link between getting IT right and the result on business growth and performance (via InfoQ). I’ll summarize the Bain study hereunder and give my thoughts on it.

Results

One of the results of the study was that while some companies reached performance gains by using IT, other companies get stuck in what Bain calls the “alignment trap”. A company is in an alignment trap when increased investments in aligning IT with the business actually hurt growth and performance. IT becomes an obstruction in stead of an enabler. Costs are higher than expected and projects take longer to complete, if ever. There is an over-alignment that causes high fragmentation, redundancy and low scalability.

The solution to get out of the alignment trap Bain proposes is getting effective first and then getting aligned. This may involve temporarily getting lesser aligned to be able to provide more effective solutions. Unnecessary complexity should be avoided, IT capabilities should be, in Bains words, “rightsourced”: the right capabilities should be sourced, from the right source, from the right shore, at the right cost, and the quality of IT delivery should be high.

Only when high effectiveness is reached it is time to get better aligned. Business strategy should be supported and enabled by IT capabilities, IT investments must be made in the right place and business results must be monitored, and both business and IT accountability should be ensured and clear.

Bain research results

SOA

I have seen my share of IT projects trying to bridge the alignment gap before effectiveness is reached, especially in SOA environments. This might be one of the most important reasons SOA attempts fail. Although a service oriented architecture removes redundancy by creating reusable services, there are problems that must be dealt with before improving alignment. One of these problems is creating a good technical foundation upon which all future services can be built. I am not talking about problems like choosing what constitutes a service, what granularity to apply, getting business support and commitment; these are alignment issues in my opinion. I am talking about building a performing, not overly complex, technical foundation, or architecture so you will, using IT capabilities from the right source that effectively enables the creation of value adding services. I have seen companies building an architecture and then quickly moving on to implementing value adding services on top of this architecture. On the way flaws and design errors of the foundation are found and fixed, often resulting in adding complexity to the same design. Another complexity issue is the fixed choice for a specific platform and/or product a company enforces. This product must be used, even if it adds only complexity, not value. Performance issues arise, integration problems prevent implementing business scenario’s, etc.: IT has become an obstacle.

Lightweight 'Guerilla' SOA

The design of the SOA foundation could be Big Design Up Front, something I would not advocate for developing a business service (apply agile methodologies there), but pay attention on keeping complexity low and effectiveness high. Try not to create barriers, like performance bottlenecks. This does mean designing and measuring for performance. I’m not a fan of premature optimizations, but this core technology determines for a great deal whether the SOA/IT is a business strategy enabler. I know you cannot anticipate everything beforehand, but I agree with Joel Spolski that thinking things out in advance can reduce the chance having to solve a non-functional issue in an established architectural landscape. So, my advice is: first get effective by creating an enabling foundation, secure non-functional requirements and keep it lightweight! When that is in place, agilely create value adding services. Of course, the technical foundation is not a static thing, it should evolve to keep enabling business strategies. Create a Guerilla SOA. This might seem controversial to my advice of designing up front and creating a solid foundation before delivering business processes, but it isn’t. Designing a lightweight foundation up front may take more time than jump-starting an increasing complex, heavy-weight middleware solution (although often this takes more time and money), but a clean and lightweight foundation is more manageable in the long term and keeps being an enabler.
This way, IT should result in increased business growth and performance, while getting costs lower.

Gaining Advantage By Letting Your People Go

Tags van Technorati: competitive advantage,strategy,employee turnover

Currently I'm busy writing a thesis for my master's on the relationship between knowledge management and sustained competitive advantage. Taking the perspective of the resource-based view I try to find emperical evidence that firms using unique knowledge will perform better than their competitors. The past months I've been reading a lot of scientific articles on the subject, most of which, though some are dated, were very interesting. Some of this stuff I like to share with you.

People quit

Besides reading scientific articles I also read a fair amount of blogs. A while ago I read an interesting piece about employee turnover in IT by Alex Papadimoulis of the dailty wtf fame. Alex argues that employers and employees should face the fact that someone won't work for the same boss ad infinitum and be comfortable with that. He even thinks that embracing this fact will be beneficial for companies for three reasons: employees leave with a positive attitude and their they have not engaged in less productive behaviour, an alumni network is created and unskilled personnel is flushed out.

Paradox

This is a really interesting point of view that unveils a paradox. Making it easier for employees to leave the firm increases the risk that valuable knowledge is drained from the firm, since the knowledge assets a firm owns mainly reside in the people that work there. When you see knowledge as the most important source of competitive advantage (as a lot of scholars do), this means that advantage might decline or even disappear when this strategy of embracing quitting is used. So, what should an employer do?

Building a network

I think that acknowledging that people do not stay forever is a good thing, but to put this inevitable fact to their advantage, firms need to take action. An alumni network builds itself, but organizations need to actively put the network to use. A great example of a firm that does this is ThoughtWorks in my opinion. Not only do they display blogs of their employees on their website, there is also an alumni section. ThougthWorks' current and ex-employees stay in touch, read eachother's blogs and so share knowledge. ThoughtWorks has created a network of ambassadors and champions consisting of both employees and alumni. Another example of a company that endorses employee transfers is Toyota. They often let employees transfer to their suppliers, sometimes permanent and sometimes temporary. This way they can build a network identity and share knowledge within this network. Both Toyota and their suppliers benefit from this approach.

Minimizing risk

The risk of losing valuable knowledge can be minimized in a few ways. First, a lot of knowledge is context specific and loses its value outside the firm. Also firms aquiring knowledge by hiring away personnel face adjustment time and consequently can't put the newly acquired knowledge directly to use.

Second, a lot of knowledge isn't articulate. This tacit knowledge, as it's often called, is problematic to transfer, because it can not be documented or codified. It requires face-to-face interaction to be transfered. It will not leave the firm quickly, but it is also difficult to transfer within the firm.

What to do?

So what companies should do is integrate the knowledge of their employees, making it more context specific and creating collective, organizational knowledge instead of individual knowledge. Although the trend is to document and codify all knowledge in the organization, firms should leave some valuable knowledge tacit. Which knowledge to keep tacit is a key question. When specific knowledge needs to be transfered within the firm, it should be codified, or externalized to be able to speed up the transfer. But beware, speedy transfer could mean speedy disappearance!

Letting people leave the firm in a good way, building an active alumni network, while at the same time keeping valuable knowledge inside the firm is in my opinion a way to gain and sustain competitive advantage.

Welcome to this blog

Hi and welcome to my personal space in the blogosphere. I am a software developer specializing in Microsoft technology at a global information technology services company. My interests lie mostly with Enterprise Application Integration using Microsoft .NET and BizTalk. I am always trying to stay on top of new technologies, which at the moment are WCF and WF.

I live in the Netherlands, somewhere near Amsterdam. Besides my day job I'm currently obtaining a master's degree in the social sciences. The programme I'm taking is Policy, Communication and Organization at the VU University Amsterdam, where I study organizations from different perspectives using theories from sociology, psychology, public organization, business administration and strategic management.

On this blog I will post about these two passions of mine and try to combine them. So when I write about new technology I'll try to explain the business value of it. When I write about organizational issues I'll try to relate them to my daily work and potentially that of many other developers out there. Stay tuned!