Slashdot Mirror
Joel Test Updated
An anonymous reader writes "In 2000, Joel Spolsky wrote the Joel Test, an excellent and simple way to evaluate a software company. While the test is still used, it's getting outdated, as many companies are moving to web technologies, and new development tools exist. In his blog, Marc Garcia wrote about what could be an update to Joel Test."
first test post
1. No known species of reindeer can fly. BUT there are 300,000 species of living organisms yet to be classified, and while most of these are insects and germs, this does not COMPLETELY rule out flying reindeer which only Santa has ever seen.
2. There are 2 billion children (persons under 18) in the world. BUT since Santa doesn't (appear) to handle the Muslim, Hindu, Nigger, Jewish and Buddhist children, that reduces the workload to 15% of the total - 378 million according to the Population Reference Bureau. At an average (census rate of 3.5 children per household, that's 91.8 million homes. One presumes there's at least one good child in each.
3. Santa has 31 hours of Christmas to work with, thanks to the different time zones and the rotation of the earth, and assuming he travels east to west (which seems logical). This works out to 822.6 visits per second. This is to say that for each Christian household with good children, Santa has 1/1000th of a second to park, hop out of his sleigh, jump down the chimneys, fill the stockings, distribute the remaining presents under the tree, eat whatever snacks have been left, get back up the chimney, get back into the sleigh and move on to the next house. Assuming that each of these 91.8 million stops are evenly distributed around the earth (which, of course we know to be false but for the purpose of our calculations we will accept), we are now talking about .78 miles per household, a total trip of 75.5 million miles, not counting stops to do what most of us must do at least once every 31 hours, plus feeding and etc. This means that Santa's sleigh is moving at 650 miles per second, 3000 times the speed of sound. For purposes of comparison, the fastest man-made vehicle on earth, the Ulysses space probe, moves at a poky 27.4 miles per second - a conventional reindeer can run, tops, 15 miles per hour.
4. The payload on the sleigh adds another interesting element. Assuming that each child gets nothing more than a medium-sized Lego set (2 pounds), the sleigh is carrying 321,300 tons, not counting Santa, who is invariably described as overweight. On land, conventional reindeer can pull no more than 300 pounds. Even granting that "flying reindeer" (refer to point #1) could pull TEN TIMES the normal load, we cannot do the job with eight, or even nine. We need 214,200 reindeer. This increases the payload - not even counting the weight of the sleigh - 353,430 tons. Again, for comparison - this is four times the weight of Queen Elizabeth.
5. 353,000 tons traveling at 650 miles per second creates enormous air resistance - this will heat the reindeer up in the same fashion as spacecrafts re-entering the earth's atmosphere. The lead pair of reindeer will absorb 14.3 QUINTILLION joules of energy per SECOND, EACH! In short, they will burst into flames almost instantaneously, exposing the reindeer behind them, and create a deafening sonic boom in their wake. The entire reindeer team will be vaporized within 4.26 thousandths of a second. Santa, meanwhile, will be subjected to centrifugal* forces 17,500.06 times greater than gravity. A 250 pound Santa (which seems ludicrously slim) would be pinned to the back of his sleigh by 4,315,015 pounds of force.
In conclusion - If Santa ever DID deliver presents on Christmas Eve, he's dead by now. And he'd be a faggot.
======================
*Please note that centrifugal is a made-up non existent word. The real word should be centripetal. Centrifugal is a made up force that physics people HATE! So please, everyone use the world centripetal, not centrifugal. Thanks!
Seriously, who the fuck is this "Joel" person, and why does anyone give a shit what it thinks?
First UPDATED test post! Now, get off my lawn!
He failed the grammar test:
I think every software company should took the test, and every programmer looking for a job, should make the test to any company he could be interested.
Do your team work in good conditions...
What one fool can do, another can. (Ancient Simian Proverb)
A few hundred words by some guy who can't even take the time to half-bake his own ideas, instead poorly rephrasing someone else's to tack on a few now-stylish buzzwords, is now worth the Front Page?
You can do better, timothy.
I think the original Joel questions still work fine.
Who needs a distributed source control system if everyone on my team works in the same office.
Also, I don't want end customers submitting directly into my bug tracker. I'm OK with them having a web based way to submit problems, but then QA should verify the defect and translate customer speak into something that makes sense. Then the defect can be entered into bug tracker with a good set of steps to reproduce and given a proper severity. To a customer, everything is critical.
Joel Test for my scientific endeavors.
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
If you actually read through the Joel Test writeup and explanations you will easily see that TFA has absolutely nothing positive.
This is someone with no experience actually running a software team trying on new buzzwords.
*Shrug* - just comes off as a wish list of how this developer thinks software companies should work. IMHO part of the attraction of the original Joel list was that it was more or less applicable regardless of product audience / build tools etc. The core principles *really were important*.
But getting back to this, Garcia's list appears to be fairly sound. I have some comments on two of his modified questions:
Do you use a distributed source control system? Why should I care about distributed source code control in a monolithic commercial development environment? I can see its value in a distributed open-source project, but I really don't understand the necessity otherwise.
Do you fix bugs before implementing new features? All bugs? Some bugs? This tells me nothing about prioritization. Sometimes you need to do both at once. Sometimes it's not worth it to fix a bug if the circumstance is rare enough.
Dog is my co-pilot.
I would like to see a similar list for knowledge workers generally, starting with having a quiet, interruption free environment.
This is of course not "Joel" updating his list of requirements for good development, but some joker trying to take advantage of Joel's reputation.
Example: Allow users direct access to a bug database? It's hard enough to train testers to give you good bug reports. You won't get anything usable from an end user without some severe filtering.
Do you pair employees regularly (at least from time to time) to allow for cross training so the more experienced staff etc.. (whatever the experience) can learn with the less experienced ones.
Do you have an adaptive development strategy, beyond well just do it.
thank God the internet isn't a human right.
Do you use a bug database where users can report bugs directly?
No. No. No. You'll end up with a database full of laundry list bugs and PEBAC resolutions.
Do your team work in good conditions (quiet environment, flexible schedule, freedom to choose development software, fair paycheck...)
Brilliant, ask about working hours and how much money you'll be paid. You won't come across as lazy and greedy, honest.
Summation 2
He thinks Microsoft gets a 12/12 (lmao!) and organizations that don't give programmers "the best tools money can buy" are already losers LOL!!!
I guess it's the end of the fiscal year and he needs more business so he's getting his friends to refer to his obsolete and irrelevant standards.
Seriously good software isn't written by microsoft or by people who get 12/12 on that silly quiz.
M
Yeah, seen enough of them from the old Dot-com boom.
Seriously, there are enough good software professionals around who do good work without claiming to be a Guru. And IMO none of these Gurus are worth a damn iota of good work.
So, why exactly does everyone need a distributed source control system? Just because anything distributed is automatically cooler?
Also, yeah, having the users report bugs directly in the bug database is just stupid.
sic transit gloria mundi
Do you use source control?
- useless if your source control doesn't know about unified diffs and if developers don't know how to make 1 commit - 1 changeset
- also if it's dog slow, throw that piece of crap in the trash
AND I MEAN IT
Can you make a build in one step?
- very important, but overrated for things that don't 'build'
- make this a 'deploy package' in one step
Do you make daily builds?
Do you have a bug database?
- important. Corolary: all bug databases suck, some less, some more, use bugzilla and you'll be fine
Do you fix bugs before writing new code?
-use unit testing here
Do you have an up-to-date schedule?
Do you have a spec?
- overrated
Do programmers have a quiet working conditions?
- ditch the phones
Do you use the best tools money can buy?
- the best tools are free. Use only tested and true tools, and ONLY if they cost $1000,00
Do you have testers?
- this is really important
Do new candidates write code during their interview?
- important as well
Do you do hallway usability testing?
how long until
It's important for any buzzword-compliant software development organization today to use a distributed version control system, even if it doesn't actually benefit them in any way.
See, if you're not using a DVCS, then maybe you're still using relational databases, too. That'll make a lot of managers and executives really suspicious these days.
The guy's apparently from Belgium, so English is quite possibly his fourth language, so I won't bother ripping on his grammar. His content is another matter...
Original: Do you use source control?
New: Do you use a distributed source control system?
My current Big Work Project has a whopping four coders, so I can't speak to when distributed source control is a big deal and when it's overkill.
Original: Can you make a build in one step? Do you make daily builds?
New: Do you have automated build or deployment procedures?
Clearly inferior. An error-prone 20-step process that you run once a month is still automated, just not automated enough and not used enough.
Original: Do you have a bug database?
New: Do you use a bug database where users can report bugs directly?
The BWP is still small enough to get by on Excel lists, with changes manually merged back into the master copy by the project manager, or just e-mail for quick-turnaround items. Excel is noticeably clunkier than an automated system, but you may want to start there to get a feel for what the automated system should do (e.g. separate status fields for "the coder did some testing and thinks it's fixed" vs. "the tester did some more thorough testing, confirmed that there were no misunderstandings, and couldn't find any more edge/corner cases").
Original: Do you have testers? Do you do hallway usability testing?
New: Do you have a testing protocol, and specific resources for testing?
I hate calling people "resources". Also, your protocol should stick to the right things (e.g. "when you find a problem, report X and Y and Z"); an example of a wrong thing is "test this specific way of using the system", because real users will go off the rails.
Original: Do you fix bugs before writing new code?
New: Do you fix bugs before implementing new features?
More or less equivalent.
Original: Do you have an up-to-date schedule? Do you have a spec?
New: Do you have a roadmap, and you don't make important changes to the short term priorities?
These have become fuzzy for no good reason that I can discern.
Original: Do programmers have quiet working conditions? Do you use the best tools money can buy?
New: Do your team work in good conditions (quiet environment, flexible schedule, freedom to choose development software, fair paycheck...)
More or less equivalent. "Fair paycheck" is so blindingly obvious that it shouldn't need to be pointed out. "Flexible schedule" is a genuinely good addition; I've personally gained some peace of mind by saving some tasks for evenings/weekends when I knew I wouldn't be interrupted by other work stuff (family stuff is another matter, but easier to control), and consequently taking it easier during normal business hours.
Original: Do new candidates write code during their interview?
This has been omitted completely for no good reason that I can discern. Maybe he's lucky and hasn't had to clean up after a bad coder yet.
That's it. No tools, methodology, procedures, or what have you will make up for the lack of good programmers. And good programmers will do well no matter what the tools, procedures, methodologies, etc are (barring Kafka-esque hindrances).
So here's my revised list:
1) Is the company full of good programmers?
Of course, acquiring and maintaining good programmers doesn't just happen. New hire interviews need to be technically based, the staff needs adequate compensation, and management should not get in the way of programmers trying to do their job. However, employees don't need to be treated like prima donnas. They just need management that commands respect and respects them likewise.
This is evaluation of what precisely? All of those things are surely good to have, some are really a 'must have' especially if there is more than one developer. But in reality none of that answers the question: "is the software company a kind of company I would want to work at?"
There is nothing there about what kinds of projects the company is doing, what kind of working conditions are set, what kinds of flexibilities are allowed, there is nothing there about desire/ability of the company to require excellence or initiative, there is nothing there that helps you to understand if your work will be rewarded based on your contribution, etc.
Sure, there is probably correlation between a company that works on multiple projects and that can in principle allow the developers to work from home (for example) and things like 'distributed source control'. But that is maybe a correlations, not a causation.
Where are the questions about management structure? The types of projects that you'll be engaged in? The kind of initiative the company is expecting (or not expecting), the kind of documentation that will be expected, the kind of maintenance you'd be expected to do, the kind of work hours you'll be putting in, something to measure the expected stress levels due to scheduling/resource mis-allocations, etc? You need to understand those if you want to be able to make informed decisions on the compensation and work conditions you'll have.
The source control, etc., it's all good, but it's all irrelevant! That's because YOU can change it once you are on a project, I had to change those things many times, from source control implementation, to documentation structures, even management structure. The real question for me is always: what do you really expect me to deliver and given the levels of stress associated with it what will you be paying per hour? (contracts only of-course).
You can't handle the truth.
My boss brought this test up when he first started and we scored maybe 3. Looking at it now we only score 1 - go figure!
Do you use a distributed source control system?
The companies that need this are limited. And in some ways it's a bad sign. Makes it easier to ship your job to India.
Do you use a bug database where users can report bugs directly?
Assuming you do some sort of post processing to control flooding attacks, and do quality control, etc, this is ok.
Do you have a testing protocol, and specific resources for testing?
Are there seriously software companies with more than 5 coders with no qa? You have to know what you're getting into with a group too small to have discovered the need for qa.
Do you fix bugs before implementing new features?
This isn't always the right thing to do. It's sometimes a good practice because you can tackle bugs while you're fresh on a topic, but it can likewise be a focus distraction. As with another item below, this seems to be a demand to dump agile.
Do you have automated build or deployment procedures?
Well, I won't argue with this one. Removing meaningless grunt work is generally a good idea where possible.
Do you have a roadmap, and you don't make important changes to the short term priorities?
So you're ruling out working anywhere doing agile? Agile works great, and makes changes to short term priorities all the time.
Do your team work in good conditions (quiet environment, flexible schedule, freedom to choose development software, fair paycheck...)
Our environment is loud loud loud and generally that is considered one of our best features. We supply ear phones if you need quiet time for concentration. We will let you pick your editor, etc, and the pay is fine, those seem like reasonable requests.
"Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
Put a $10 bill, or the local equivalent, in an envelope on the company bulletin board. On the outside, write, "I need change for $10 please" without any indication of who you are. Do this every six months or so. If you ever come back and find that the envelope is empty, your company is too big. You have hired a thief who does not care about his or her fellow employees.
I piss off bigots.
as many companies are moving to web technologies, and new development tools exist.
Web technologies change nothing in his test. And his test does not mention any specific tools, just general classes of tools. "Do you use source control?" and the catch-all "Do you use the best tools money can buy?" are asking if you use the general types of tools that distinguishes good shops from bad shops. You could add "Do you use a mock-objects framework?" but now it isn't universal, because that doesn't always apply and could be subject to debate.. Then it just becomes someone's checklist of "Have you used every tool that I use and endorse?" The Joel Test is universally applicable, covering the kinds of things all shops should do.
Most of the updates in his blog are a pedantic rewording of the existing ones.
So I call myself a software developer, but I've never worked on any group project that required builds at all. I've done java and c++ projects of my own, but any time there was more than just me, it was a web development environment where things were broken up to the script level and it was very rare that one person's work would break another's. Launching individually tested scripts was fast and asynchronous. It seems to me that is a superior model for web development. I know that the place I used to work switched over to java for a lot of stuff, and now they have build headaches and compatibility issues between the communication layers. I'm not sure what the advantage is there for web development. Isn't the whole idea of builds a pointless carryover from desktop software?
Daily builds have never made much sense to me. If someone breaks a build, the fix is easy - revert their commit and tell them they screwed up. If you have expensive (processing-wise) unit tests that you want to check with continuous integration, I can see value in that at least.
Other than that, Joel's list is quite solid. Those are the first things to fix at a company, and the things to jump ship over if the leadership refuses to address them.
Paraphrasing both Joel S and Marc G : Do you do everything my way, just 'cos I ( ... think I know better than a guy that ... ) runs a two-bit software company in New York?
Of course I sodding don't: my company writes for it's conditions and requirements, and not yours.
If I choose to use SVN or GIT or even PVCS, what's it got to do with you?
If the personal dynamics in the team are slightly competitive rather than perfectly "A: let's do it your, way. B: No your way. A: no, insist - your way. ... ad nauseam", does that preclude producing decent software? (I'm C, "C: will you just get it done already!")
Software development isn't about one process or another, it's about meeting the sodding customer's requirements, so they can get on with THEIR business, and most of the time they couldn't give a flying duck what methodology you use, as long as the software does what it says on the tin, doesn't cost too much, and isn't a pain in the ass to use every other day!
How is there no mention of software architecture or design considerations? imo, this is one of the biggest problems plaguing software development.
I have misgivings about the "daily build" mania. Like "extreme programming", it maps well to the class of problem which consists of a large number of loosely coupled features. Most web-based systems fall into that category. It's not a good model for, say, a compiler, a file system, a database, a solid geometric modeling system, or simulation system, or a real-time control system, where there are rigorous overall constraints and "features" don't dominate the problem.
(Most of the stuff Joel's company does isn't that advanced. Their products are a project management program, a front end to an existing version control system, and a "remote administration tool" which sounds like Back Orifice..)
13) Can you remote debug?
What does that even mean?
The first two questions in particular are certainly not applicable in many environments.
Who needs a distributed source control system if everyone on my team works in the same office.
You need distributed source control even if it's just you because:
1) You can work more easily between several different systems.
2) You get more advanced branching and alternate release features.
3) Lower weight cost to frequent checkins (not every checkin has to go to the server).
4) When you DO end up needing to work with a second person, distributed version control systems are much better at getting a second person integrated into the build process.
I've used ClearCase, CVS, RCS and Subversion. Distributed version control (git for me though there's nothing wrong with Mercurial) just works better, for how programmers work.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
I have seen this all the time with open source software with public bug databases:
* User files bug with vague description and no steps to reproduce.
* Project manager lumps a bunch of vague bugs together as "duplicates".
* Programmer fixes bugs that sound similar to the vague descriptions and marks as fixed.
Then all holy hell breaks loose on the forums as people bitch about you closing their bugs when the problem still exists, and post on slashdot about "bugs" that have been open for 5 years but no one will fix. In reality the "bug" has morphed into an ever changing thing that means something different to each person involved and which is thus impossible to ever truly "fix".
Bugzilla in particular is horrible to use as an outward facing webapp (I don't even like using it internally).
my name is Joel and I failed it.
This guy has no relevance in today's era of programming (and had questionable relevance even before today). He hasn't done anything special and I don't know why people continually feel the need to post about this elitist asshole who has only had marginal success in the business with software built for pointy haired bosses that no programmer actually likes.
BeauHD. Worst editor since kdawson.
A question that cuts past all the red tape, and gets right to the heart of the matter...
"What do you think, sirs?"
In 2000, Joel Spolsky wrote the Joel Test, an excellent and simple way to evaluate a software company. While the test is still used, it's getting outdated, as many companies are moving to web technologies, and new development tools exist. In his blog, Marc Garcia wrote about what could be an update to Joel Test.
Great! That's really cool, I've been waiting for an updated list -- from Marc Garcia no less!
What, who the f--- is Marc Garcia? Well... he's done well at getting his web site pageranked (probably in part due to this "anonymous" submission). Beyond that he seems to be one of the countless dime-a-dozen bloggers who have opinions nobody cares above. Hey, no insult intended - I have a blog nobody cares about too -- but then you don't see me trying to get it featured on slashdot. What's worse is that he's doing so by using a well-known name -- and it seems to be working His most recent article has 45 comments, while most of the previous articles have 0.
Well, if nothing else I guess he knows how to get visitors to his web site - in spite of nobody having ever heard of the guy before today. Funny part is that he'll probably *get* a following out of the deal -- all for writing one post that references the opinions of a relatively well-known 90s-era software developer while providing no actual thoughts of value. .
Okay, to be fair - yes it's possible that he did not submit this himself; and that some random person stumbled across his article and posted it here. After all, enough people upmodded it indicate there must be some interest -- though that could be on the basis of the misleading summary... no matter the issues in the original posting, at least it didn't lie by implication.
</mini-rant>
joel serves as an intelligence test
If you understand why he is wrong or full of BS on almost everything, you pass
Sort of like nuclear reactors for electricity - if you understand why they are a bad idea, you pass