The Spolsky Score
-
Good afternoon people. What do you make of the "Spolsky Score" as a measure of an organisation's quality? http://www.joelonsoftware.com/articles/fog0000000043.html[^] I've got my reservations, but I'd like to hear what the rest of the world thinks.
-
Good afternoon people. What do you make of the "Spolsky Score" as a measure of an organisation's quality? http://www.joelonsoftware.com/articles/fog0000000043.html[^] I've got my reservations, but I'd like to hear what the rest of the world thinks.
Having been laid off from a place that has only 1 yes, to #1, (even then the source control was not used properly and caused major issues this week) I would say these are a decent gauge. I now find these important and will probably use them in my job search. #3 might not be that important IMO.
"I have a theory that the truth is never told during the nine-to-five hours. " — Hunter S. Thompson My comedy.
-
Good afternoon people. What do you make of the "Spolsky Score" as a measure of an organisation's quality? http://www.joelonsoftware.com/articles/fog0000000043.html[^] I've got my reservations, but I'd like to hear what the rest of the world thinks.
Rob Lyndon wrote:
What do you make of the "Spolsky Score" as a measure of an organisation's quality?
I like it way more than the Capability Maturity Model, mainly because it's practical.
Rob Lyndon wrote:
I've got my reservations
Can you give an example?
Bastard Programmer from Hell :suss:
-
Good afternoon people. What do you make of the "Spolsky Score" as a measure of an organisation's quality? http://www.joelonsoftware.com/articles/fog0000000043.html[^] I've got my reservations, but I'd like to hear what the rest of the world thinks.
-
Good afternoon people. What do you make of the "Spolsky Score" as a measure of an organisation's quality? http://www.joelonsoftware.com/articles/fog0000000043.html[^] I've got my reservations, but I'd like to hear what the rest of the world thinks.
I've always heard it referred to as the Joel Test :) I think a score of 11 is a necessary, but not sufficient, criteria for me choosing to spend my time with a company. These ideas have been around for at least 11 years - there is no excuse nowadays to score less. The one exception applies to very small outfits - in these cases the role of tester is often shared among the stakeholders and is not a dedicated person. If I had to pick one as most important, I would choose #9: using the best tools money can buy. If an employer wants me to work with one hand tied behind my back, then I'm obviously not charging enough! Nick
-
Good afternoon people. What do you make of the "Spolsky Score" as a measure of an organisation's quality? http://www.joelonsoftware.com/articles/fog0000000043.html[^] I've got my reservations, but I'd like to hear what the rest of the world thinks.
Thanks, I'll be circulating that around the office. It seems like a good way to initiate some healthy introspection. I'd say the team I work in scores about 6 (+-2, depending on interpretation... e.g., what is the cutoff for "quiet working conditions").
Joel wrote:
you're wasting money by having $100/hour programmers do work that can be done by $30/hour testers
You guys make $100/hour? And I only made $8-$12/hour when I was a tester. :((
Somebody in an online forum wrote:
INTJs never really joke. They make a point. The joke is just a gift wrapper.
-
Rob Lyndon wrote:
What do you make of the "Spolsky Score" as a measure of an organisation's quality?
I like it way more than the Capability Maturity Model, mainly because it's practical.
Rob Lyndon wrote:
I've got my reservations
Can you give an example?
Bastard Programmer from Hell :suss:
For sure. 1 to 5 are absolutely indispensable, and 9 to 12 are very important. As to 6, 7 and 8, I'd say that depends on the nature of your business. Let's have a look 6, 7 and 8 in a bit more detail. 6. Do you have an up-to-date schedule? I don't disagree with this one, but I will point out that schedules can sometimes change very quickly. I remember working on a financial application, when a change in the law came in, and we had to add a component pretty much yesterday, in order to keep the FSA off our back. (OK, that might be a slightly bogus example, because as any regular reader of Private Eye can tell you, the FSA is often perceived as more of a kitten than a lion, but run with me for now.) So when requirements like this come in, your schedule needs the flexibility to keep up with the changing landscape. Another thing to point out is that you may be in an outfit where you're expected to know the business well enough to come up with your own ideas, and present them to the business accordingly. If you have enough reusable components, and you have built your system from the ground up using the right set of best practices, you'll be surprised how quickly you can release a component. We used to play the "start the clock game" in our team. When a requirement came in, we could sometimes fulfil that requirement by making config changes, generating a couple of derived classes, and adding one or two lines of code. Because we were adding very thin layers on top of code that was already thoroughly tested and trusted, we had a high degree of confidence in what we turned out, and could target our testing accordingly. I guess what I'm saying here is yes, keep schedules, but don't let them constrain your creativity: they're there for your benefit, not the other way around. 7. Do you have a spec? You can go a very, very long way by naming libraries, classes, methods and variables intelligently, and by observing the Single Responsibility and DRY (Don't Repeat Yourself) principles. Again, if you're working on an internal app in a small team, then if you have a straightforward method for code reuse that you've all bought into, then the need for a spec starts to fade. Under those circumstances, enforcing a "no code without spec" rule feels like you're adding unnecessary red tape to an already efficient process. On the other hand, with a larger team and thousands of users, a spec can add an indispensable layer of clarity to your project. My attitude to schedules and specs is similar: use them, b
-
To be honest I'm not so sure about #5, bugs are bad by definition, but they can be so noncritical that they become "wontfix", and a "wontfix" isn't meant to kill the project by making it "Illegal according to Spolsky" to add any new code.
Joel's argument about the cost of bug fixing is a compelling one. Your "wontfix" may be benign at this point in time, but who says it isn't going to turn malignant just before you're due to ship? But yes, if you're so dogmatic about the rules that you cross the line between running a project and practising a religion, you may end up cutting off your nose to spite your face. A talented manager is hired to know the difference.
-
For sure. 1 to 5 are absolutely indispensable, and 9 to 12 are very important. As to 6, 7 and 8, I'd say that depends on the nature of your business. Let's have a look 6, 7 and 8 in a bit more detail. 6. Do you have an up-to-date schedule? I don't disagree with this one, but I will point out that schedules can sometimes change very quickly. I remember working on a financial application, when a change in the law came in, and we had to add a component pretty much yesterday, in order to keep the FSA off our back. (OK, that might be a slightly bogus example, because as any regular reader of Private Eye can tell you, the FSA is often perceived as more of a kitten than a lion, but run with me for now.) So when requirements like this come in, your schedule needs the flexibility to keep up with the changing landscape. Another thing to point out is that you may be in an outfit where you're expected to know the business well enough to come up with your own ideas, and present them to the business accordingly. If you have enough reusable components, and you have built your system from the ground up using the right set of best practices, you'll be surprised how quickly you can release a component. We used to play the "start the clock game" in our team. When a requirement came in, we could sometimes fulfil that requirement by making config changes, generating a couple of derived classes, and adding one or two lines of code. Because we were adding very thin layers on top of code that was already thoroughly tested and trusted, we had a high degree of confidence in what we turned out, and could target our testing accordingly. I guess what I'm saying here is yes, keep schedules, but don't let them constrain your creativity: they're there for your benefit, not the other way around. 7. Do you have a spec? You can go a very, very long way by naming libraries, classes, methods and variables intelligently, and by observing the Single Responsibility and DRY (Don't Repeat Yourself) principles. Again, if you're working on an internal app in a small team, then if you have a straightforward method for code reuse that you've all bought into, then the need for a spec starts to fade. Under those circumstances, enforcing a "no code without spec" rule feels like you're adding unnecessary red tape to an already efficient process. On the other hand, with a larger team and thousands of users, a spec can add an indispensable layer of clarity to your project. My attitude to schedules and specs is similar: use them, b
By the way, here's a potted history of Laban's life. http://www.trinitylaban.ac.uk/about-us/our-history/rudolf-laban.aspx[^]
-
For sure. 1 to 5 are absolutely indispensable, and 9 to 12 are very important. As to 6, 7 and 8, I'd say that depends on the nature of your business. Let's have a look 6, 7 and 8 in a bit more detail. 6. Do you have an up-to-date schedule? I don't disagree with this one, but I will point out that schedules can sometimes change very quickly. I remember working on a financial application, when a change in the law came in, and we had to add a component pretty much yesterday, in order to keep the FSA off our back. (OK, that might be a slightly bogus example, because as any regular reader of Private Eye can tell you, the FSA is often perceived as more of a kitten than a lion, but run with me for now.) So when requirements like this come in, your schedule needs the flexibility to keep up with the changing landscape. Another thing to point out is that you may be in an outfit where you're expected to know the business well enough to come up with your own ideas, and present them to the business accordingly. If you have enough reusable components, and you have built your system from the ground up using the right set of best practices, you'll be surprised how quickly you can release a component. We used to play the "start the clock game" in our team. When a requirement came in, we could sometimes fulfil that requirement by making config changes, generating a couple of derived classes, and adding one or two lines of code. Because we were adding very thin layers on top of code that was already thoroughly tested and trusted, we had a high degree of confidence in what we turned out, and could target our testing accordingly. I guess what I'm saying here is yes, keep schedules, but don't let them constrain your creativity: they're there for your benefit, not the other way around. 7. Do you have a spec? You can go a very, very long way by naming libraries, classes, methods and variables intelligently, and by observing the Single Responsibility and DRY (Don't Repeat Yourself) principles. Again, if you're working on an internal app in a small team, then if you have a straightforward method for code reuse that you've all bought into, then the need for a spec starts to fade. Under those circumstances, enforcing a "no code without spec" rule feels like you're adding unnecessary red tape to an already efficient process. On the other hand, with a larger team and thousands of users, a spec can add an indispensable layer of clarity to your project. My attitude to schedules and specs is similar: use them, b
Rob Lyndon wrote:
Again, if you're working on an internal app in a small team, then if you have a straightforward method for code reuse that you've all bought into, then the need for a spec starts to fade.
I'm part of a team of four, and I'd say that specs are a requirement; simply because there's no goal without a roadmap.
Rob Lyndon wrote:
Do programmers have quiet working conditions?
Everything that you could notice is a potential source of distraction. That's the reason why a lot of programmers like to work at night :)
Rob Lyndon wrote:
It is not good for you to be "in the zone" eight hours a day, five days a week, forty-nine weeks a year.
Too bad. Those are my working hours.
Bastard Programmer from Hell :suss:
-
Good afternoon people. What do you make of the "Spolsky Score" as a measure of an organisation's quality? http://www.joelonsoftware.com/articles/fog0000000043.html[^] I've got my reservations, but I'd like to hear what the rest of the world thinks.
Interesting. In my role as the DSJB(*), I've helped take my group from a score of 2 to one of 10.5. 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? When our group started, #4 and #6 were the only things that applied, and they were externally imposed by management. The only item we are entirely missing now is #11, and I think that's mainly because we haven't hired anyone new in ages. I only give us half credit for #3, since we do our builds on a demand basis. We have six products with development and maintenance branches of each. Our build process takes 40 to 90 minutes. We've got two high-end server-class machines we do builds on. I don't think we've got the horsepower to do daily builds of all products and all branches. Most get built at least once a week. The 'hot' products, coming up on a release, get built once or twice a day. (*) Departmental Sh!t-Job Boy; I administer our department server, manage our source control, maintain our automated build process, and usually write our documentation.
Software Zen:
delete this; -
Thanks, I'll be circulating that around the office. It seems like a good way to initiate some healthy introspection. I'd say the team I work in scores about 6 (+-2, depending on interpretation... e.g., what is the cutoff for "quiet working conditions").
Joel wrote:
you're wasting money by having $100/hour programmers do work that can be done by $30/hour testers
You guys make $100/hour? And I only made $8-$12/hour when I was a tester. :((
Somebody in an online forum wrote:
INTJs never really joke. They make a point. The joke is just a gift wrapper.
AspDotNetDev wrote:
Joel wrote:
you're wasting money by having $100/hour programmers do work that can be done by $30/hour testers
You guys make $100/hour? And I only made $8-$12/hour when I was a tester.
Joel lives in NYC, so his costs are on the high side compared to most other places. However I also strongly suspect he's looking at fully qualified costs after all the overhead costs are factored in. Slap something like a 2x multiplier on for rent/utilities/management/hr/it support/bean counters, and all the other supporting expenses that start to become needed once you grow beyond the startup stage and $100/hour doesn't seem unreasonable for a middle/upper level dev.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason? Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful? --Zachris Topelius Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies. -- Sarah Hoyt