This time I’d like to talk about a phenomenon we don’t learn about at school and never hear from happening in the US, but apparently being pretty common in our area: Legally Distributed Software Development. The reason is that I consider it very nice, and it deserves a highlight.

First off, a definition (since I just invented that name). I call it legally distributed, because distributed development is very common. A few years ago I worked at a company where some programmers were in Tunesia, some in Shenzen/China, some in Paris, some in Vienna, some in Bratislava, etc (nobody knew the exact amount of people involved, but it was estimated at around 200). All of those spread-out teams had to be coordinated and it wasn’t a lot of fun — some coworkers voiced their opinion that a single team in one location could have done the same work with better quality with 1/4 of people or less.

However, what I’m calling legally distributed is quite the opposite: the people are all working in the same (general) geographic area, but aren’t hired by any company which oversees the process. They’re all what is called one-person-companies (EPU) here. They’re working together on a project-by-project basis, splitting the costs, risk and earnings. This is a true agile business: For one project, you might work with person A, B and C, on another project with person D and E. This way, you always have some project going on (or more at the same time if you’re not careful), and you can always pick a team of people that have the talent for the tasks required and the necessary capacities. The risk for everyone is reduced, because it is spread around multiple projects.

Now, there’s a problem with it that causes this whole structure to be quite fragile: there’s no legal framework for any of this, except for the very basics (that you’re allowed to do business at all), which means that there’s no protection if something goes wrong. There’s no standard contract for this kind of arrangement (like there is for many other things), and nobody can afford a lawyer to write one. Most of the agreements are based on oral contracts, which any lawyer strongly disapproves of.

However, in an ever-accelerating world, this is definitely the direction software development is heading towards. Some time ago I participated in a conversation with friends of mine, and one of them mentioned that he’s been working for the same company for four years. The immediate reaction from one of the others was “What? You should look for a new job very soon, otherwise it looks bad on your CV.” Considering that my mother worked at a single company for thirty years (until they closed shops) and that’s not considered unusual in that age group, there’s a definite trend there. However, getting hired and then quitting are both lengthy processes, which is not adequate for agile project-based development. Thus, many companies have shifted to hidden employment, where you’re treated like you’re an employee, but legally are not. This is a very bad thing, because you get the worst thing of both worlds.

Of course, this one-man-company-distribution doesn’t scale all that well to more than three or maybe four people (I’ve never had more than three on a team), but when looking at software sales e.g. in one of Apple’s App Stores, it’s clear that the profits per developer are heavily favoring smaller teams nowadays anyways.

So, is that kind of development here to stay? Or will those who do it right now just found their own companies in the end, fearing the legal issues arising from it? I don’t know, but I’ll definitely stay for a while and see what will happen.

« »