I was going to respond in horror, but I figure somebody else will get to that.
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. :-)
Please keep in mind that asking these questions can put one in peril. There are political consequences to trying to create change in organizations that are this far behind -- no source control? Bwah? -- that imply that the managers are not doing a very good job.
This is a public service announcement. Get a new job.
The best, brightest, smartest developer I ever knew was working at a company with a score of ZERO. Talk about wasted talent. Now he works for me and we do awesome stuff.
There are dozens of companies in any significant metropolitan area who take software development seriously that are begging for competent developers. It doesn't have to be Google, there are well-run boring companies that pay well everywhere. You're (demonstrably) one of the only developers with sense where you are, don't stay there.
There are a lot of places that still use tarballs for "version control". Technically it saves "versions" even if it isn't quickly accessible, and doesnt require a proper VCS
This is a pretty cool article. The key point as I understand it is that the bank is ISO 27001 Certified, but doesn't have testers, source control or a list of bugs. (The rest of the Joel test isn't as big a deal, but these are kind of big ones that indicate cowboy coding and not any sort of process at all.)
I'm curious just how bad the situation actually is within your organization. Is the bank actively against using source control, bug tracking, etc. or is it just neglect.
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.
For #2, I don't think the three environments actually mean the answer is no. If you can build to dev in one step, and then move the build from dev to UAT in one step, it should be fine.
Nitpick: 2. Can you make a build in one step?
Ans: No
But build in one step does not really mean deploy to production right from a dev box. It generally means can you build your code to a deployable artifact or actually deploy it on a server in one step. Or may be I don't understand what OP meant.
While Joel Test is good in general, for a bank some of these requirements aren't relevant or advisable. The author gives a reasonable argument for why #3 isn't applicable here.
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.
I find the Joel test such a useless measure. It doesn't actually tell you anything about the quality of the code being written.
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.
I'm at the point where I've heard so many stories from people hiring, that I really just want to see source code. Point me to a public repo of projects your company (or, failing that, you yourself) have.
The Joel test gives a nice proxy to measure the experience levels of the people in charge.
Inexperienced people seem to underestimate their risks, and overestimate their abilities. Everyone eventually makes a mistake, but the Joel test reveals how likely mistakes are to be caught early, and how quickly a team will be able to recover. When it comes to an complex system, these quickly become critical to maintaining a measure of quality, regardless of how "awesome" the individuals are.
That's not what the Joel Test is intended to measure. You can write quite excellent code even with having a score of 0 on the Joel Test. It's purpose is instead to gauge the quality of the team and workplace and their ability to get the work that needs doing done without being bogged down with all the problems that come with poor processes.
In general the practices highlighted in the Joel Test are some of the most high impact in improving overall development velocity and efficiency as well as in preventing burnout. There is a pretty strong correlation (at least in my experience) with low Joel Test scores and teams/companies who spend a lot more time fighting fires, fighting with tooling, struggling just to get basic dev. tasks completed (e.g. building and testing), working excessive hours, etc. As a consequence of that their productive work vs hours worked ratio is so low that they end up putting out a lower quality product at a much higher cost and they end up causing a lot of excessive stress to developers.
Sounds pretty dire Ron. There are places in the finance industry where developers do follow good practises, so don't give up hope! If you'd ever like to chat about how these things could be better, get in touch (email in profile).
Then there's Joel Test meta-question #13: "Do you know your score?"
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.
I think ronbeltran might be misinterpreting a couple steps. First:
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.
I'll comment on each in turn, since I think the author is so far out in the boondocks of corporate hell that he hasn't even been exposed to some of the things Joel is assuming as standard.
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.
I'm very sorry but I decided to remove the post since I believe my article will put me in danger. The article was written in good faith, and I don't meant any harm that It might cause to other parties.
Re. point 5 - I worked at a major UK bank for a while and won't bank with them because of what I saw, but I know that in all probability the only difference between them and the people I do bank with is that I've not actually seen how things are at my bank.
That said, we scored somewhat better on the Joel test than Rob's employees - not perfect but we had source control, testers and a bug database.
This must be the same place I work, because nobody uses the term "UAT" for "QA" except us, right? (Edit: I used to name the company here, but to give ronbeltran a bit of deniability, I've removed it.)
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.
While agree with a lot of the essence of the post,(Having fought them myself) I'll just observe some of the extreme criticisms reeks of developer-operations fight. And would recommend you consider reading about the devops movement.
If it were allowed, I would hire a system administrator to maintain our production environment. But we simply aren't allowed to do that, as programmers must never be in the same time zone as a system administrator. Why? No idea.
> (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!)
If you have that F(n+2) in there, it gets a little harder than just giving you the Fibonacci numbers.
Very few people know recursion. Even fewer people know math. So it's unlikely that this will ever happen.
The goal is to determine whether or not the person knows that functions can call themselves. It then leads into a nice conversation about the efficiency of this particular algorithm. Answering "1.6 ^ n" will just lead to a similar-but-different question being asked, since this is not a math question.
"...think that anyone that says they are a programmer is qualified to be a programmer..."
Interestingly, at big company these days, it seems like everyone with a title seems confident to declare themselves competent to lead any arbitrary software development activity. Like software development is easy!
Man, the ball that forms in my stomach every time the guy with the title starts to lead specific software engineering activities, even when the interns on the team would never hire them to be in that role.
44 comments
[ 3.1 ms ] story [ 103 ms ] threadInstead 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. :-)
The best, brightest, smartest developer I ever knew was working at a company with a score of ZERO. Talk about wasted talent. Now he works for me and we do awesome stuff.
There are dozens of companies in any significant metropolitan area who take software development seriously that are begging for competent developers. It doesn't have to be Google, there are well-run boring companies that pay well everywhere. You're (demonstrably) one of the only developers with sense where you are, don't stay there.
Please. You can do better.
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.
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.
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.
That having been said, if we were to devise the "HN test", what would be required?
Inexperienced people seem to underestimate their risks, and overestimate their abilities. Everyone eventually makes a mistake, but the Joel test reveals how likely mistakes are to be caught early, and how quickly a team will be able to recover. When it comes to an complex system, these quickly become critical to maintaining a measure of quality, regardless of how "awesome" the individuals are.
In general the practices highlighted in the Joel Test are some of the most high impact in improving overall development velocity and efficiency as well as in preventing burnout. There is a pretty strong correlation (at least in my experience) with low Joel Test scores and teams/companies who spend a lot more time fighting fires, fighting with tooling, struggling just to get basic dev. tasks completed (e.g. building and testing), working excessive hours, etc. As a consequence of that their productive work vs hours worked ratio is so low that they end up putting out a lower quality product at a much higher cost and they end up causing a lot of excessive stress to developers.
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.
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.
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.
9. It won't be cheap. See 1.
This is highly scurrilous of course!
http://www.google.com/support/webmasters/bin/answer.py?hl=en...
I strongly advise doing this immediately, if you're concerned.
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.
That said, we scored somewhat better on the Joel test than Rob's employees - not perfect but we had source control, testers and a bug database.
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.
If you have that F(n+2) in there, it gets a little harder than just giving you the Fibonacci numbers.
Oh well, on to the next problem then.
For instance one 'perfectly naive' implementation of F(n) would be: return 1.6 ^ n;
or whatever your language of choice's equivalent is (depending on your syntax)
The goal is to determine whether or not the person knows that functions can call themselves. It then leads into a nice conversation about the efficiency of this particular algorithm. Answering "1.6 ^ n" will just lead to a similar-but-different question being asked, since this is not a math question.
Interestingly, at big company these days, it seems like everyone with a title seems confident to declare themselves competent to lead any arbitrary software development activity. Like software development is easy!
Man, the ball that forms in my stomach every time the guy with the title starts to lead specific software engineering activities, even when the interns on the team would never hire them to be in that role.