General musings on programming languages, and Java.

Monday, April 09, 2007

Really Own Your Code

Walking to the bus stop, with a coffee burning one hand and my breakfast the other, I noticed how poor my area looks; an urban area where many students and young professionals rent houses. The tenants aren't poor, the owners neither, but the area itself is impoverished, because the owners don't care and the tenants don't care. I got on the bus, and dropped half my coffee on the bus floor as it went over a speed bump, because I was holding the coffee so as not to burn my hand too much. Ah, well, glad it wasn't my bus. It struck me right there how little tenants look after the property they rent. Some local teenagers smashed a bottle of beer outside my house, and I didn't clear it up. I didn't ask the local authorities to do so either. I just looked at it with disdain whenever I passed it, and resented paying my local taxes even more. In my job as a coder, on a 1.5-man project, I am a tenant. I'm actually a good tenant, in that I look after the codebase pretty well, but I'm still a tenant in the most important, and crippling, way. I don't own my code. This isn't the same as responsibility for my code; I have that. It's my code, but it's not mine. I can't walk away from my employer and reuse the code elsewhere. That's not completely true; for a couple of libraries I wrote for the project my boss has given me licence to release them for free. For those libraries, I actually find myself reserving my best coding practices, because I know that other people will need to read the code. Not just in some abstract "sometime after I leave my job" way, but in a "they already do read it" way. I don't bother to create separate libraries for code that I can't release separately. In other words, I don't decouple as much as I could, because the practical benefits are too indirect. Realistically, I know that my project will die when I leave. That's not to say that I won't be very gracious in documenting it. My boss doesn't have the skills to maintain it well, and he's uncertain as to how to make more money from it, so he probably won't want to release the whole thing for free until it suffers from bitrot (which will probably be whenever IPv6 becomes dominant). The fact that I don't own the code means that my goals and the project's goals are slightly at odds with each other. There's an IP stack in the project, a serialisation library, clever handling of scroll bars when stuff is dragged around the display, but only our 200 students (per year) are benefitting from those. The funding comes from a nationwide education body, but they don't have rights over the code either. In that respect, it's a waste of money, because other establishments can't easily customise it for their requirements, and largely they don't know about it. In fact, even within our department, another member of staff wanted to use the software, and she couldn't, because it didn't have a particular feature. I offered to implement it, but my boss declined because it wasn't part of what the funding was paying for. If it was my code, I'd happily implement it in a separate branch, in my spare time, and I'd feel enthusiastic about it. Now let's look at the most recent entry in Bugzilla for this project: "A long term thing for a quiet Friday afternoon (if such a thing exists!) In the same way you have files in the jar for customisation of "installation number", "installed to" etc, I think there may be a long-term need to use a similar mechanism to allow some customisation of the conformance rules (this will be important if other people use IPSim, as there may be some things that I want to give feedback on that other people may not care about" We lost 150 users already by not doing this for the other member of staff. Plus, I could only code in advance customisations that I can anticipate. If I'm on holiday or busy coding a new feature that we already have funding for, we'll miss out on the opportunity. For a small project like this one, developer motivation and the quality of the project would increase if the developer could reuse the work elsewhere. That could mean open-sourcing it, as has been done for two small parts (a functional programming library and a Java layout manager), or it could mean an agreement not to use the code for commercial purposes for a fixed term after employment. How about for a larger team? I'd suggest to assign each source file to a single developer, who has responsibility over that file, and has actual ownership, so that he can reuse the file at some point, even now, in another company. Then any changes made by any other developer to that file are automatically licenced so that the owner can use them.


Sam said...

I seen a statistic that most coders will reuse office work in future projects... which isn't hard to believe. The statistic didn't have what kind of code though, which would have been more interesting, because everyone has their preferred helper methods sitting in a file somewhere that they bring with them. Of course, the coder's contract may forbid this.

Out of curiosity, what does your contract say regarding code that you do in your "spare time"? And further, what if you create something in your spare time and then add it to your work codebase? Are you obliged to transfer the copyright?

Ricky Clarkson said...

Code written in my spare time is my own. I don't add it to my work codebase, but as a library (in other words, I don't know whether I'd be obliged to transfer the copyright, so I avoid the situation).

Stefan Schulz said...

Nice idea, but not really applicable for team-based development. Usually, larger project's functionalities don't restrict implementation to single classes but are also orthogonal to the class hierarchy, requiring developers to share access on classes. If it were different, using SVN or CVS would become really easy.

Ricky Clarkson said...

Stefan, I don't understand your comment. Do you mean that, because one class does many things, many developers need access to it?

That would be covered by the automatic licencing. An interesting result is that because it would be easy for the owner of the file to re-use it, but not so easy for those who only edit it, or depend on it, developers would be more likely to write modular code.

Stefan Schulz said...

I just can tell from my experience as professional Java developer that in teams it is not possible to assign classes to single people and it is not possible to build a product solely from libraries. Most of the classes are interwoven, and commonly developers are assigned for specific area of application (or functionality layers) that do not follow the class hierarchy. Otherwise you would never have problems with conflicting changes, which we have quite often in large projects.
Another reason, of course, is the code being produced is owned by the company and not the developers for a very good reason: it's the companies value.

Blog Archive

About Me

A salsa dancing, DJing programmer from Manchester, England.