Changes at Work

Apparently, one of my colleagues, told my boss (again, not that boss) about my last two blog entries (Rant: Open source is not secure and The Joel Test). So now, there are undergoing changes. WOOT!

I was asked to write a document describing advantages of Subversion versus Vault. It makes perfect sense - I think I'm the guy who knows the most about Subversion in this company. Heck, I even have some ongoing spare time projects, involving Subversion, Python and hooks :P. However, after I updated my rant, I really started leaning towards Perforce, instead of Subversion. So, I think I'm going to get Perforce, and evaluate it locally on my computer (it has some options for free evaluation - see licensing page for more info). I guess I'll write more than just one document... ;)

Oh, I think I should be fair and mention something in Vault's defense - I'm not as angry on it as I was yesterday... Although, what I wrote about it is still true - I'm kind of getting used to it. Yeah, it slows me down, but at least I already figured out how to perform the most basic tasks. Anyway, I still think that lock-less version control method is much better, so I'm not giving up my hopes to use Subversion or Perforce at work.

I'll post updates about our score on The Joel Test as soon as it changes. :)

The Joel Test

Ok, so I started writing about my Job and I can't stop now. :)

I decided, to evaluate the company I work for with The Joel Test. I'll try to explain my answers to all questions and maybe I will make some conclusions. So, let's start it already!

The Joel Test as it appears on the Joel on Software:

The Joel Test

1. Do you use source control?
2. Can you make a build in one step?
3. Do you make daily builds?
4. Do you have a bug database?
5. Do you fix bugs before writing new code?
6. Do you have an up-to-date schedule?
7. Do you have a spec?
8. Do programmers have quiet working conditions?
9. Do you use the best tools money can buy?
10. Do you have testers?
11. Do new candidates write code during their interview?
12. Do you do hallway usability testing?

Let's answer those questions one by one.

Do you use source control?
Yes, we do. The source control we use isn't the best in the world, but we do use it.

Can you make a build in one step?
No, we don't. We have a lot of projects in our repository, and all of those projects get updated from time to time. Building the project, usually, involves getting one of the developers to get the latest copy of the source, and building it manually in Visual Studio. If necessary - version numbers must be updated manually. Packaging must be handled manually. Basically, we don't have any official build process - each developer does it however he likes it.

Do you make daily builds?
No, we don't. We should, though. There are people who use the projects we develop. Currently, we have to e-mail updated versions of the applications. If we'd make nightly builds - we could as well make those available for the people who use the projects. So, they'd be always using the latest versions, and we wouldn't have to worry about sending the projects to them.

Do you have a bug database?
No, we don't. This one, actually, frustrates me. The common practice, is to report bugs via e-mail to the developers responsible for the project. I don't think I have to explain, why e-mail based issue tracking is bad.

Do you fix bugs before writing new code?
Yes, we do. If we wouldn't fix bugs before writing new code - we wouldn't be able to make money. We actually rely on our projects being bug free. So yeah, we do fix bugs, before we write new code.

Do you have an up-to-date schedule?
No, we don't. But we are trying to change this. In general, we don't have any schedules. It's kind of hard to make schedules for old projects, but for the new projects - we sometimes write schedules.

Do you have a spec?
Yes, we do. I don't have anything to add - we have specs.

Do programmers have quiet working conditions?
No, we don't. This isn't very annoying to me, because I work at home. Sometimes I do go to work to the office, however. When I do - it's not really quiet. All developers sit in one office, together with the administrator and the boss (not that boss).

Do you use the best tools money can buy?
Yes and No. See my previous post about not using the best version control system.

Do you have testers?
Sort of? I don't know if I can call them testers. They're actually the only users of our applications, and it's not in they're job descriptions to test the applications. But they do the tests, they report issues... Kinda like testers... I guess, they are testers, then.

Do new candidates write code during their interview?
No, they don't. When I had my interview - I didn't have to write any code at all. I don't think there were changes in the hiring process since then. I could say something in defense, however. We don't really need them to write code, because we never hire unknown people - all of the developers hired so far were friends of someone who was already working for the company. You won't even get asked to come to an interview, otherwise. So, the company already knows, that the guy is capable of writing code.

Do you do hallway usability testing?
No, we don't. But it's not really needed. Our company is the only user of the applications that our company makes. Because of that, we don't really need the hallway testing.

So, what's the score? We have 3 yes'es, 2 sort of's and 7 no's. Our score is 3. According to Joel:

A score of 12 is perfect, 11 is tolerable, but 10 or lower and you've got serious problems. The truth is that most software organizations are running with a score of 2 or 3, and they need serious help, because companies like Microsoft run at 12 full-time.

Something, obviously, has to be done. I hope my boss will see this... ;)

Rant: Open Source is not secure

If you don't know, I have a job. Now, my boss has problems with open source software. He says, that because it's source is available - everyone knows how to hack it. In other words - my boss thinks, that all open source software has security issues.

Normally, I couldn't care less, what my boss thinks about it. However, due to his trust issues, programmers have productivity issues. Imagine that? Well, let me explain...

Currently, the best version control system in the world is Subversion. It's an open source version control system. As explained in the Subversion Book - Subversion uses the copy-modify-merge model. It's a great model, because there are no locked files, ever! Sure, you sometimes need to manually merge your changes, but that doesn't happen very often. Even when it does happen - there are wonderful tools to help you, like TortoiseMerge (part of TortoiseSVN). So it's not really a time waster.

Now, as I said - Subversion is open source. My boss doesn't like it, obviously. He thinks, that if we'd use it - someone could hack into our code repository. So, the boss is forcing us to use SourceGear Vault. Now, the problem with it is that it uses the lock-modify-unlock model. The problem with this model, especially in our case, is that it locks every file automatically, when you start editing it. Now, that operation, usually, takes from 10 to 20 seconds. Imagine that - you open a file, you just want to add a few lines of code, you navigate to the right place, hit ENTER to start adding new code and Visual Studio hangs for about 12 seconds... And that happens each time you open a new file to edit. It isn't the only problem with Vault, but it certainly is the most annoying one. Another issue, worth mentioning, is that Vault's documentation is very incomplete and doesn't cover some important topics.

Now, what do I do? How do I convince my boss, that open source can be just as safe as closed source, commercial projects? I though about that and frankly - I have no idea...

Maybe I should show him the testimonials on Subversion project page. I should also, tell him about the certified Subversion binaries, available from CollabNet. Pointing him to Subversion Access Control from WANdisco, might also help.

I don't know, I guess, the moral of my post is this: if you have a software company, be careful with your opinion, don't be religious about anything - it might be the one biggest thing slowing down your developers.

Edit: I forgot to write about the other - closed source alternative to Subversion that is just as nice (or so I've heard). I'm talking about Perforce. From what I have found on the web - Perforce might even be a better than Subversion on some aspects. My boss should like it, because it's not open source. Well, if I fail to convince my boss to switch to Subversion, I'll suggest Perforce.