The Joel Test against my employer - a Bank

In the end, it really depends on your individual department's policies. My department uses version control. We use CI. Dev -> Prod takes as long as it takes the tests to run.

Admittedly, we've managed to fly under the radar with respect to all the arbitrary processes that have been developed. The ideal "process" involves a 1 year dev cycle and filling out a lot of forms every time you even think about changing the production environment. Ultimately, you can follow the letter of the law without requiring too much effort. We install our own Linux distribution in /usr2 on all of our servers so that we don't have to get the dudes in India to install packages for us. We use Redis and SQLite (for some apps) instead of the "official" database, Sybase, so we don't have to fill out requests. The only request that's fast is, "can you please reboot server x", so we have a "firewall rules" script that runs out of rc.local as root. If we need to make some change, we just edit that script, ask for a reboot, and watch something get done in less than a year.

What you have to realize is that the people that design technology processes at big "non-technology" companies don't know anything about technology. It's a job that you get because you failed at being a janitor and they didn't have the heart to fire you. So the processes they design deserve approximately zero respect. The rules are there so they can tell their bosses that they made some rules to prevent all those developer monkeys from doing anything evil. But in reality, they wouldn't know a computer program if it hit them in the face, so they don't actually have the ability to enforce the rules. Nobody has ever been fired for being grossly incompetent, so it follows that nobody has ever been fired for being grossly competent either. Since it's easier to be competent, and you won't get fired for it, that's what we do.

(BTW, the processes would never protect against a malicious internal developer. The reason is that w there's no process like "someone that knows something about programming must review your code". Instead it's stuff like, "laptops must be triple-encrypted" and "you must not use emacs, as it's a 'non-approved' computer program".

You may not be allowed to bring in malicious code, but you can write it in house. A good example was a friend that needed ssh on a Windows server. That's not allowed, so he wrote a program that binds a TCP sockets and execs, with full privileges, every line it receives from any client. That's 100% OK, because there's no way in-house software can be insecure! The system works!)

I will agree with his point about hiring, though. We ask for some code on the whiteboard questions, and 99% of candidates epic fail it. (Our question is: given that F(n) = F(n-1) + F(n-2) and F(1) = 1 and F(0) = 1, write a naive function in your favorite programming language to calculate F(n). And people can't do it!)

We recommend against their hire, but someone always overrules us and then they get hired. As a result, every time we have an open position, the team gets progressively dumber. That's because those janitor-rejects I was talking about in the previous paragraph think that anyone that says they are a programmer is qualified to be a programmer, and they get a raise if they "increase their headcount".

I am getting tired of this and will probably leave soon, but some people apparently like it. I might like it if they didn't lie to me about how much I'd be paid and then lie about the reason for not paying me.

1. Source control. Sounds like they're possibly working mostly in mainframe or DB languages that don't have a clear "edit compile run" loop. This does make source control harder, but it's still important.

2. "build" doesn't refer to deploying to production. It refers to making a complete version of the product so that you can verify that Joe didn't change the method signature that Bill relies on.

3. Again, this is about build for testing purposes, not pushing to production.

4. No bug database. The answer is confused. It seems as if they don't have any concept of a bug tracker, that there is only the schedule or change requests or something along those lines.

5-8 that's great, it sounds like management is at least competent even if modern software development best practices have passed them by.

9. Best tools money can buy? I don't think you can say that without version control and a bug tracker.

10. No testing. Very alarming. Maybe acceptable for the pinboard guy ("I'm very careful") but I don't see how that can fly at a bank.

11. Code in interviews. This isn't surprising. At this point the test is moving from marks of competence to indicators of the outstanding.

12. Usability testing. I think you've effectively pointed out that at least one item on the Joel test isn't universally applicable.

1. Very impressed that the author had the balls to write this.

2. Hoping that none of his peers or superiors catch wind of this.

3. Hoping he lands on his feet if they do.

4. Surprised that he didn't take any steps to post this anonymously, considering that 20 seconds of Googling shows exactly where he works.

5. Glad I don't bank there, and yet horrified to think that my bank (Chase) is probably not any better.

Instead let me say: I think it is awesome that you are even asking these questions. That makes you a step ahead of most everybody you are working with. Good for you. And good luck getting a better job. :-)

  1. Do you use source control?
    Ans:  NO
  ...
  9. Do you use the best tools money can buy?
    Ans: YES

3. Do you make daily builds? Ans: NO I don't think daily builds apply to bank software development. Once a build is deployed in PROD it will never be touched again unless needed say Central Bank changes specification/compliance.

Making a daily build doesn't mean deploying a new build daily, it means making sure that the latest version of code actually builds. This definitely applies to bank software development.

Also:

Can you make a build in one step? Ans: NO Before our programs reach PROD (production) It must pass to 2 servers (DEV, UAT and PROD). We need proper permissions to do the build which by default we don't have.

The question about making a build in one step isn't about the phases of deployment; it's asking if there's an easily triggered process that can create the binaries and necessary files instead of a builder having to follow a complicated manual cookbook.

Even more important than the absolute score, I think, is that a company is A) well-read enough to have heard of it, B) realized the value enough to run through the exercise already, and C) knows the items they need work on without having to look it up. In other words, it shows _velocity_, a culture of continuous improvement.

I haven't been in the job market for awhile, but back when I was, the first words out of my mouth to the contact at the other company was "What's your Joel score?" It's amazing how effective a filter that question is, because the only responses you get are the right one (9<=x<=12) or "I don't know." Other than perhaps "Will you marry me", it's perhaps the highest shannon entropy of any four-word question.

If it is the latter, why not start doing these things on your own? "Backup" your code with git. Make a form that saves to an excel document for tracking bugs.

In other news, tomorrow is my last day at a large investment bank...I plan on curling up in a ball and crying for the next couple weeks over just how miserable the experience was.

Rule #2 seem to yield no flexibility with regards to testing and deployment processes. Certainly having a single-step build and deploy to a development server (and subsequent single-step deployment to a production server) should be acceptable. In particular, this strategy ensures that a development system has been tested before going live.