Joel Test Updated 182
Posted
by
timothy
from the inspect-the-width-of-the-coal-chute dept.
from the inspect-the-width-of-the-coal-chute dept.
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."
Grammar test fail (Score:2)
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...
Re: (Score:3)
The "sentence" is total fail.
I find the irony of that statement absolutely hilarious.
Re: (Score:3)
Do your team work in good conditions...
The sentence fragment is "correct" in countries like England where English escapes them, and they don't understand that a team is a singular entity
In over 30 years of living in England, I never saw or heard this solecism committed by an English person.
It is a mistake — not a local variation — and is never correct.
Re: (Score:2, Informative)
Old system is fine. (Score:5, Interesting)
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.
Re:Old system is fine. (Score:4, Interesting)
Says the person who's job is about to be exported to India.
It seems like a fairly logical list, but I've noticed that the list is geared more toward waterfall, and not for, say, Agile - for instance "Do you have a spec?" doesn't really apply because the requirements become the spec. Also Agile often has non-dedicated roles - for instance, I work in Product Validation and in waterfall I do nothing but write test plans and run tests, but in Agile I manage the Lab Manager VMs, write schema, and run unit tests, none of which I would do in my traditional role (it doesn't hurt that I am a programmer originally hired into automation, but that got outsourced, and I've filled a variety of roles since then like US government security testing, which the US doesn't allow to be outsourced).
Re: (Score:2)
AFIK the "distributed source control system" is not about networking or Internet, but about giving each developer a whole copy of the central repository so they can "pre-commit" their code and this generates some benefits Spolsky talks about when referring to Mercurial.
BTW, Subversion will not prevent anybody's work being exported to India.
Re: (Score:2)
Who needs a distributed source control system if everyone on my team works in the same office?
Says the person who's job is about to be exported to India.
Yes, that's a good reason NOT to use a distributed source control system. Anything that makes it harder to outsource work is a good thing.
Re: (Score:2)
Says the person who's job is about to be exported to India.
1. Maybe your is going to be exported to India. After all, what do you know about the OP's job to make that assertion? Or are you one of those who think offshoring is both a) inevitable and b) a tragedy?
2. What does distributed source control has to do with remote teams? People have done offshoring with CVS successfully for cry out loud. The distributed part in the "distributed version control" name is not what you think it is. It is not about physical distribution/networking per see.
It seems like a fairly logical list, but I've noticed that the list is geared more toward waterfall, and not for, say, Agile
Que?
for instance "Do you have a spec?" doesn't really apply because the requirements become the spec.
In other words yo
Re:Old system is fine. (Score:5, Insightful)
His "updates" just sound like re-statements of the original questions for a particular situation (i.e. less applicable to all modern software companies than the original).
Joel Spolsky assumed you would be intelligent enough to adapt the list to your specific situation.
For example, what good is "source control" if it doesn't effectively control the source code? There is no need to specifically mention distributed source control; if your source control is doing its job then you have good source control. If it isn't doing its job because you've got developers all over the country, then you need a distributed source control. It's built in to the question.
Customers directly reporting to a bug database, as others have mentioned, can be disasterous. However, Joel's flagship software is bug tracking software, and from what I've heard it's very, very good. His bug tracking uses a combination of silent reports from the software, direct customer input, and support service input. Specifically stating bug tracking must be entered directly by the customer is stupid and inflexible, and does not apply to all situations. The point of the software test is to apply to all situations.
It goes on, most of them are similar, but this one is egregious:
Do you have automated build or deployment procedures?
What the hell does he think "Can you make a build in one step?" means?! That's automated build and/or deployment!
Also:
Do you fix bugs before implementing new features?
Uh... frankly, that sounds worse than "Do you fix bugs before writing new code?"
Do you have a roadmap, and you don't make important changes to the short term priorities?
A) That's not the programmers job nor responsibility, and B) "Do you have an up-to-date schedule?" Hello?
Seriously, what does this guy think all these words mean? Just because they were written 10 years ago doesn't mean the meanings of the words changed. Apply them to your situation, they fit just fine.
Last but not least:
Do your team work in good conditions (quiet environment, flexible schedule, freedom to choose development software, fair paycheck...)
That's a dream of every office worker in America, and if you refuse to work at companies that don't have an office culture like that, well, you won't be working much unless you are seriously hot shit.
Re: (Score:2)
Re: (Score:2)
Do your team work in good conditions (quiet environment, flexible schedule, freedom to choose development software, fair paycheck...)
That's a dream of every office worker in America, and if you refuse to work at companies that don't have an office culture like that, well, you won't be working much unless you are seriously hot shit.
Is it really that bad? I mean, the last three are debatable, but the first one seems to be pretty necessary to me. Hell, I quit my last job mainly because of the lack of a quiet
Re: (Score:2)
Also, I don't want end customers submitting directly into my bug tracker.
You mean, you don't want then submitting directly into your queue. OK who cares. Why force Q/A to manually retype or cut-n-paste each customer request before dropping the ticket in your queue? Its not as if cut-n-paste magically improves upon pasting. Trust me, Q/A doesn't necessarily make any more sense than customer speak, but being distant from a bug does mean small details will be lost, some of which may be important.
I would never, ever let a customer set the actual ticket severity. They are free t
Re: (Score:2)
and translate customer speak into something that makes sense
Spoken as a true programmer--well done, sir!
Re: (Score:2)
Re: (Score:2)
Who needs a distributed source control system if everyone on my team works in the same office.
Your code is still distributed among multiple people; and even for a single person, you could have several unrelated features being worked on in parallel.
Plus, even if you personally prefer the centralised approach, DVCSes tend to be better at that too (eg - looking at a commit log with SVN was always a chore as you need to wait for the server. Git not only lets you look at it easily, but make use of it, for instance being able to automatically do a binary search across a range of commits to see which patc
Distributed source control is better for anyONE (Score:2)
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 perso
Re: (Score:2)
The point is, if you're after top talent, you're going to need to distinguish yourselves from every other run-of-the-mill gig out there. Too many interviewers fail to understand this. If it's a plain old boring job, well sure. But then you shouldn't be looking for top talent (and it seems everyone wants top talent).
There's a Dilbert comic about this. Every company wants top talent, but they want to pay "competitive" wages, which means the market average. Why companies think they're going to get top talent
I always prefered this (Score:3)
Is how open source devs would like corps to be run (Score:3, Insightful)
*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*.
A serious question (Score:5, Interesting)
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.
Re: (Score:3, Interesting)
The "bugs" one made me think this was written by someone who had no idea how a sustainable development model works. Then I read Marc Garcia is a student. How does this shit pass thru Slashdot's editors?
Re: (Score:2)
Commenting to undo moderation (the new mod system should allow you to undo and lose the point).
This list is pretty awful. Most of it is specific and Joel's original list is quite indicative in and of itself.
Re: (Score:2, Informative)
Why should I care about distributed source code control in a monolithic commercial development environment?
Aaahhh.. haven't you learned by now that being able to divide concepts recursively is generally a Good Thing (tm)?
Even a monolithic company consists of different workgroups, and the developers in those groups may want to work remotely on some stuff, e.g., when they are on a trip. If it would cost them too much pain to merge in their changes when they're back home, do you think these developers would be thrilled to do said work when they're away?
Re:A serious question (Score:5, Insightful)
Has Joel Spolsky done anything that's worth a damn?
Not really, but he seems to be an expert bullshitter who throws around the fact that he once worked at Microsoft every chance he gets. As for what he's done, let's see:
City Desk - some sort of program for creating and managing websites. Little or no mention of it on his website anymore and the City Desk forum is long gone from the website.
Fogbugz - The Forgbugz forum is also gone from his website. Here's a blurb from Joel this past September: "Thanks to the hard work of the Fog Creek team, including ten great summer interns, we have just released amazing new upgrades to FogBugz " Thank god for free labor.
Co-Pilot - a remote access program that was written entirely by summer interns. Really. Thank god for free labor.
Stack Overflow - Not an actual application but simply a website where people can ask questions.. This doesn't stop Joel from proclaiming "I’m the CEO of Stack Overflow".
From what I can see on his website, his main business now is ads for programmer jobs.
Re: (Score:3)
Could you elaborate on the problems with FogBugz (or "the FuckBox" as my new coworkers call it)? My new employer has a FogBugz installation that is half-assedly used for product development, but we want to manage support via FB too (using the mail feature) and merge in existing tickets from our Bugzilla (which doesn't handle "standard" tickets at all) so that we end up using FugBogz only for everything. We're only 30 people living off a specialized software, so load won't be an issue. I'm intrigued by the t
Re: (Score:3)
So I haven't used any of TFS/Subversion/Clearcase/CVS in the last 10 years. Do they really not offer a branch structure that would allow you to do all of that without the need for distributed functionality? Sourcesafe and perforce both do.
Total failure (Score:4, Insightful)
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.
Re:Total failure (Score:5, Insightful)
You won't get anything usable from an end user without some severe filtering.
Indeed. This attitude is one of the biggest failures in Open Source software development, and why companies like Microsoft flourish. Microsoft software has many issues, but listening to the End User is not one of MS's problems. On the other hand, pipe up to just about any Open Source project about End User issues, and "STFU and submit a patch" is about the nicest thing you'll hear. Even as responsive as Apache and Mozilla are, End Users still feel this wrath. It a fact, most companies that want their products to flourish and make money are responsive to the people that actually use them. The GIMP Team? Not so much.
Re: (Score:2)
> but listening to the End User is not one of MS's problems
After reading countless posts regarding inaction and apathy on long-term known bugs in the Visual Studio suite, I too can confirm that listening to the end user is definitely not something that MS consider their problem.
> On the other hand, pipe up to just about any Open Source project about End User issues, and "STFU and submit a patch" is about the nicest thing you'll hear
What complete nonsense. There are plenty of projects out there that ar
Re: (Score:2)
Q: Why are you not like photoshop?
A: It's a different program with different aims. Besides, photoshop doesn't even have UNDO so is aimed at professionals that save a lot or never make mistakes.
Fast forward to now, many complaints are about it not being photoshop or missing features needed for specialised industrial printing on very expensive bits of gear. After fifteen years if it was me I would say "just go out and buy photoshop and leave us alone", but the
Re: (Score:2)
It has a big problem because it "guesses" your account-settings and basically automates the setup of your mailaccount. If it works, fine. But if it doesn't, you're SOL.
Nonsense.
It *trys* to guess your accound setting, and if it can't (and even if it thinks it has), it gives you the option of doing in manually. Yes, I'd like that option first, but really no big deal.
There are a lot of *other* things that make me start to think about Outlook...
Re:Total failure (Score:5, Interesting)
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.
The question is whether you are better off leaving your users to work out their bug corresponence via mailing lists or email and only let a blessed few enter bug reports, or is it better to have the full case history going all the way back to what the customer actually reported along with any logs or screenshots. Or if you just drop it only the floor saying "LALALALA our software is perfect, all problems are PEBCAK problems."
Personally I'm a big fan of wine appdb's "*** This bug has been confirmed by popular vote. ***". If enough people are experiencing a problem, you have a problem whether you get anything useful from the logs or not. Don't forget that crappy bug reports and crappy logging often go hand in hand, when the application just goes boom without giving any useful information about why the developer is just as much at fault for making it impossible to debug.
Re: (Score:2)
his list of requirements for good development
You won't get anything usable from an end user without some severe filtering.
The two quotes are more closely related than you'd think, in that both are limited to extremely narrow experiences and assume the rest of the world MUST be the same as the past limited experiences.
If all I have is a hammer, suspiciously, everything, including bolts and screws, looks like a nail.
Users reporting bugs directly (Score:2)
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.
Re: (Score:2)
No. No. No. You'll end up with a database full of laundry list bugs...
God forbid you would want that! A list of issues that the people that ACTUALLY USE YOUR PRODUCT have with it? Heavens no...
Re:Users reporting bugs directly (Score:4, Informative)
Unless your users are professional developers/programmers, the signal to noise ratio is going to be horrid.
And it makes for horrible public interactions. (Score:2)
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 f
Re: (Score:2)
You've never waded through a laundry list of bugs before, have you?
Re: (Score:2)
err that's normally one of the the things the job spec has up front and if it didn't that would be a warning in its self that the company is a poor employer.
Wait, what? (Score:3)
Also, yeah, having the users report bugs directly in the bug database is just stupid.
Re: (Score:2)
Because Garcia said so!
Seriously, most of his "updates" are just re-statements of the old questions in a less flexible manner, so that they apply to fewer software companies or coding environments. The old questions already include his if you assume such things as bug databases and source control need to be effective in order to meet the requirement. A bug database that doesn't contain the information you need to fix bugs is useless, and would count against the company. Source control that doesn't effect
Re: (Score:2)
Just because anything distributed is automatically cooler?
It's not a causal link, but the correlation is pretty much 1:1 -- when I first moved from svn to git, what blew me away was that the command line tools were simply better in basically every way ("git subcommand --help" gives you a scrollable searchable man page rather than wall of text on stdout; coloured output makes it much easier to read; having a local copy of the history makes everything a million times faster, etc) -- it was a few months in before I did anything actually distributed with it...
Plus, t
My take on it: (Score:2)
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 b
Re: (Score:2)
Dammit, now we have to fix the headline:
s/Joel Test Updated/Joel Test Updated Again (see comments)/
Re:My take on it: (Score:4, Interesting)
I imagine Joel thought you would be smart enough to apply the guidelines to your own situation. You've done that to a degree, but you're making the list needlessly inflexible.
- Do you use source control?
If your source control does not actually control the source effectively, it isn't source control. It's just a thing you put your source code into to make your life a living hell.
-Can you make a build in one step?/Do you make daily builds?
This one you have a small point on, but the obvious purpose here is to automate the process of publishing the latest version of the software to the team in order to avoid mistakes in the build/deployment process. Server side scripting, for example, isn't compiled or "built", but all the pieces do need to be in place and everyone needs access to the most current version. "Building" in this case would mean deploying the new code to the internal test server so all the developers know what the most current version of the web site is and can actually use it to verify that everything is working. This prevents you from making changes that are so large they are difficult to trace (if you have source control and nightly builds, you know exactly who screwed up and when). There should be an automated process to ensure all of the needed components are, in fact, there. It's just as critical for things that don't build as it is for things that do, it just looks different so you may not realize it.
"make this a 'deploy package' in one step" I hope you mean deploy to the test server in one step, and not publishing it out to the world. If not you totally missed the point of nightly builds (it's to catch major bugs before the code needing debugging becomes too large).
I could accept Garcia's "Do you have automated build or deployment procedures?" as a replacement for "Can you make a build in one step". The point is automation to avoid procedural mistakes, not compiling/deployment itself.
-Do you fix bugs before writing new code?
"Use unit testing here" - There is no need to be so specific. Unit testing is an effective modern tool, but it will not catch all bugs, particularly systemic bugs. The point is that you need to fix the major, money sucking bugs before you add new features.
-Do you have a spec?
"overrated" ??? The specification is the thing that describes what you are trying to do! How the hell can you write anything but hodgepodge software, especially with more than one developer, if you don't have overall design goals written down somewhere where they can be referenced? You can change the specification if your goals or needs change, but you should always have one! I suspect this is an especially serious flaw for open source projects that don't have strong leadership, given the distributed nature of open source.
-Do programmers have a quiet working conditions?
"ditch the phones" ?? What if your programmer works from home, how are you supposed to effectively communicate? Email isn't good enough for all situations, IM is better but still doesn't quite cut it, and frankly it encourages people to interrupt you more often. Quiet working conditions are what you need, not a simple lack of phones. I think if you were to expand this you should add "free from distractions" to the end of that. These days, it can be very quiet in your office yet still be extremely distracting with emails and IM notifications popping up all over the place.
Re: (Score:2)
"ditch the phones" ?? What if your programmer works from home, how are you supposed to effectively communicate? Email isn't good enough for all situations, IM is better but still doesn't quite cut it, and frankly it encourages people to interrupt you more often. Quiet working conditions are what you need, not a simple lack of phones. I think if you were to expand this you should add "free from distractions" to the end of that. These days, it can be very quiet in your office yet still be extremely distractin
Point-by-point analysis (Score:4, Insightful)
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.
Re: (Score:2)
In my experience DVCS isn't "overkill" for anything ; if anything, it's less effort for the single developer than say, Subversion would be because you don't have to set up a repository separately ; you just do a
git init
(or your chosen DVCS)
And off you go. Some of them (Bazaar) will let you set things up so they work more like a central VCS. While the GUI tools are possibly not as mature as something like TortoiseSVN, I find using the CLI and spawning GUI dialogs for logs and merges to be slicker than using
A good software company needs good programmers. (Score:2)
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
Re: (Score:3)
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).
I disagree. You can stuff the top ten programmers of the world into a company, but without a proper team around them they'll just get nothing done that's worth it. For example, see Duke Nukem Forever. That didn't fail because of bad programmers. Other example: Microsoft Bob. That didn't fail because the programmers were crap, it failed because the product designer (user experience designer, workflow designer, product management, whatever you like to call it) was a complete failure.
Good software projects nee
Re: (Score:2)
You assume by "programmers" I only mean "implementers".
No, I assume "the ones writing the sourcecode".
If you're only working on projects where the only required specialization is programming, then I envy you, because that is very rare. Even in very small projects, you need others.
For example, I've yet to meet any programmer who is able to do any significant artwork for the software (just look at Minecraft), and I've yet to meet any graphics artist who is able to do any significant software development. Those two things seem to be mutually exclusive.
Additionally
Evaluation of what exactly? (Score:2)
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 excell
Re: (Score:2)
This is a test of general dysfunction.
It doesn't tell you anything about teams that pass. But it tells a lot about teams that fail.
Everything on the list is a simple and easy thing a development team can do to improve productivity.
So, if a team is not doing these things, why not? What do they have against productivity?
This test will stop being useful when most development teams master the basics. But that time has not yet come.
Re: (Score:2)
This is good advice.
My eyes glaze over when a candidate starts asking about what versions of what products she will be using. No one cares. If we made the wrong choice, I expect someone to get some consensus and fix it.
I always tell a candidate about management structure: it's 1 boss per 20 workers, so there won't be a lot of hand-holding or meetings, initiative is required, etc. That's the easiest way to avoid a bad match.
Also, always walk the candidate through the group's workspace. 2 minutes there sa
Re: (Score:2)
Re: (Score:2)
When we decide to hire high-school graduates and give them guns, I expect we'll reconsider.
Until then, we'll hire self-directed, highly-educated professionals. They tend to be a better fit for writing complex software.
nonsense list for the most part (Score:2)
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
Simple test for when a company is too big. (Score:5, Insightful)
Re: (Score:2)
The Joel Test does not need updating (Score:4, Insightful)
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.
Builds (Score:3)
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? (Score:2, Interesting)
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.
Re: (Score:2)
Daily builds have never made much sense to me. ... If you have expensive (processing-wise) unit tests
Some places use expensive (angry-customer-wise and lost-sales-wise) "unit tests". Life is never easy in operations or the call center, but at least they know if it breaks at 2:36pm it almost certainly has to be an operations problem as opposed to a failed deployment.
Also important for rolling out new features simultaneously with marketing/sales. Or having a formal way to cease new rollouts before the big fundraising round demonstration (of course stopping regular deployment merely means you'll be demoing
Re: (Score:2)
I don't think Joel was referring to deploying/launching daily builds, just building in a test environment. I guess this goes against the spirit of the Joel Test, but I assumed it went without saying that any build going to production would go through building, unit tests, and QA. I'm pretty sure Joel was talking mainly about compilation to check for syntax errors.
I would expect the same build/unit test/QA process for a build used to demo, and that the demo would go to a UAT or other stable environemnt (in
Re: (Score:3)
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 aren't doing daily builds, how do you know when the build is broken? The idea is to catch it soon after the problem occurs, so it's easier to fix.
Re: (Score:2)
I figured out from another post that daily builds is in reference to large compiled projects. Somehow every project I've worked on has either been interpreted (eg. php: 'svn up' and visit any page, if configs are broken you find out immediately) or compiled projects small enough to rebuild every time you make a change to verify the change works.
It's actually really hard for me to imagine coding on a project so large I can't test my code as I work. Waiting even a day to get a build created and see the resu
Re: (Score:2)
I don't think that's the point, I can apply patches and build a new kernel in relatively short time if everything else is compiled already. I think it's more that there's regular testing that everybody's work merges properly and passes unit testing. It's more than a little frustrating if it's the big merge day and after every developer has checked into the master branch then everything fails.
Re: (Score:2)
How can you know if the build is broken if you don't try it regularly?
You'd find out the next time a coder updates from the repository and builds, which (ideally) shouldn't take more than a day or two anyway.
so you can actually get a new binary with your changes about 1.5 hours after you make your code changes (it's a large tree).
Ahhhh, now I get it. With a build time that long I can definitely see the necessity for daily builds. I've never worked on a single compiled project anywhere near that size. Now I feel bad for whining that my last java project took 2 minutes to build ;)
Joel must have been talking about large compiled projects too, based on some of his other posts. I guess that item on
Incrementalism (Score:2)
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 do
Re: (Score:2)
Interesting.
The system I'm currently working on has most of the above (compiler, custom file system/database, simulation system, real-time constraints, and also compute farms, global 24/7, hundreds of developers, etc.)
We run "build-and-test on check-in." No code base forks, no long-lived private branches. "Daily build" would be horribly inefficient for our specific workflow, even 5 minute builds are a bit annoying.
The environment you are operating in determines a lot about the tools/practices you get: we
Don't Think Much of His Additions (Score:2)
The first two questions in particular are certainly not applicable in many environments.
Enough spolsky (Score:2)
My Joel Test is one question... (Score:2)
A question that cuts past all the red tape, and gets right to the heart of the matter...
"What do you think, sirs?"
Wait, what? (Score:2)
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 o
Re:Who is this guy? (Score:4, Informative)
Joel Spolski is a guy who runs a software company, and he used to be a program manager on Excel. However that's not why people give a shit about what he thinks. People read (past tense) his articles because they were pretty good, and explained stuff lots of people in the software business need to know but often don't. For instance if somebody doesn't understand Unicode, I often point them to his article explaining it .... because he did a pretty good job.
The real question is, who is Marc Garcia and why does the article submitter think we should care? In fairness, he says the "updated list" is just his personal opinion rather than something generally applicable, which is good because pretty much every software company I know would fail at least one or two of the points on there, including Google.
Re: (Score:2)
Re: (Score:2)
Re:Who is this guy? (Score:4, Insightful)
Do you sell your car every year to buy a new one? There's a cost to converting, so you have to make an engineering decision about making the conversion. The automated tools don't always work with old and complex repositories.
Re:Who is this guy? (Score:4, Insightful)
If it means redoing all of your established routines and teach people the new routines, rewriting all your automation, and obsoleting existing ticket or work log systems (or otherwise run two repositories in parallel, with the problems of authorativity that entails), "nicer" doesn't necessarily cut it. There has to be a gain that measurably outweighs the inconveniences.
Re: (Score:2)
There has to be a gain that measurably outweighs the inconveniences.
Not necessarily a gain, but a DCVS like git inherently "backs up everything that is needed or ever happened" to all the devs.
1) Ultimate multiple site backup capacity for disaster recovery
2) If engineered properly, bringing up another host in the cluster / bringing up a disaster recovery site is beyond trivial.
3) (the bad news) Security FreakOut!
If the big boss says this shall be a small component of the disaster recovery plan, well, then an abstract weekly metric result doesn't much matter, does it?
The oth
Re: (Score:2)
Only automation support is a sticking point.
Otherwise, if you can't manage a switch to a different VCS then you have some problems (either with developers or with organization). Which nicely proves Joel's point.
Of course, there can be exceptions, like working with large amounts of unmergeable content (CAD drawings, images, etc.) where DVCSes do not work well.
Re: (Score:2)
Because what we have works pretty damn well, and we can trust it. Only once a week someone runs into a problem that'd be solved easier with a newer SCM, and it'd only save him/her 30 minutes.
So we can quantisize it at ~30 minutes per week of lost productivity
Switching to a new SCM will require many many hours of research by whoever is tasked with organising the switch, and it will require a couple of hours at least for everyone else, in learning the new gotcha's (lets not forget, some of the guys who are us
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Gits have plusses and minuses. And in many cases, the good things about git are necessitated by the bad things.
Like the better merge facilities, which are much more needed, and still don't nearly make up for when you have to merge 10 branches from 20 developers instead of the simplicity of merging a team branch with a trunk.
Or the local copy, which is necessitated by not being guaranteed having access to an authoritative master.
Git is nice. But it's not a panacea that works for every situation.
Re: (Score:3)
1) checkin after every logically complete operation (for What The Fun Just Happened moments)
2) checkin every night (so if I'm sick tomorrow people can get to my work)
3) my-code-doesn't work, collaborate with someone down the hall or geographically remotely
4) I want to experiment with an alternate code path (but don't want to deal with the politics - remeber coders have egos)
4a) I want to experi
Re: (Score:2)
I don't see why distributed source control is so necessary for a team. I mean, git is neat and all that, but I'm thinking it's a lot more "nice to have" than "need to have".
Source control is important, regardless of the team size. One project I worked on years ago was some custom contracted software for a specialized industrial client. I was helping the lead programmer with initial deployment and bug fixes. Every couple of weeks the client would call me about a particular bug and let me know that it was back again. I'd go back to the code dump and they were right, a bug I had previously squashed was back again. This happened several times and I informed the lead programme
Re: (Score:2)
Agreed! I don't know who this guy is, or why I should care, and the original list seems quite broad so it should encompass all new technologies without much updating.
Re: (Score:2)
really most principals can be applied to any kind of work and the employee doesn't really matter (a developer should pair with a sales person, if that's the kind of experience you want to swap for instance)
Code repository = Auditable whatever, and filing.
Bug / Feature tracker = CRM or whatever.
Usability testing = Product evaluation and feedback.
etc....
Best tools money can buy, should really be most appropriate tools etc...
Re: (Score:2)
Re: (Score:3)
Re: (Score:2)
Thanks for proving Santa does not exist. However by doing so you have also proved Trolls exist.
Dammit Man, don't you see it? Santa is not an ELF, He's a TROLL!!!
It's so insidious, it makes perfect sense.
Oh, he's also still a perv too...
He see's us when we're sleeping!
He knows when we're awake.
We have to sit on his lap and ask for gifts!!!
Dear God, When Will People Wake Up?
Re: (Score:3)
If you were an alien and you came here in 1991 and you wanted to learn how to develop software, you would learn ten times as much at Microsoft as anywhere else, I think, because I watched these companies kind of flail making mistakes. There were things--really basic things, that companies did not know. Microsoft knew that loading a segment register on the 386 was a very time-consuming operation, and therefore on the 386 architecture you can't use far pointers unless you absolutely have to because it's extremely slow. Borland did not know that. Result: Microsoft Access loaded in 2 or 3 seconds; Borland Paradox for Windows took 90 seconds to get running. Because of something that Microsoft knew that Borland did not know. And that's one of a million examples.
Now Microsoft has forgotten all these things, and they've hired a lot of morons that don't know these things anymore. I think that now Microsoft is kind of a big tar pit where you can barely move forward because there's so much bureaucracy. But I learned a lot.
Source: http://www.foundersatwork.com/joel-spolksy.html [foundersatwork.com]
Re:Nobody takes this seriously... (Score:4, Insightful)
The idea that borland didn't know about the performance of loading a segment register is ridiculous. It's in the intel manual. Everybody I knew who cared about the performance of software had that manual handy. Then eventually the compiler just took care of it for you and we all stopped caring.
Re: (Score:3)
The "nobody takes this seriously part" requires relating the 1991 date of the quote with MS buying Fox Technologies in 1992, along with their product Visual FoxPro, which I am told was renamed to "Access" and released in 1992.
Re: (Score:3)
Having seen visual foxpro in action I can assure you that they did not just "rename it and release it as access," unless you count castration as a usual part of the renaming process.
Re:Nobody takes this seriously... (Score:4, Insightful)
If you think Microsoft products are bad, imagine how much worse they would be if Microsoft wasn't answering yes to a lot of those questions. Also understand that the article was written in 2000, when the computer world landscape was vastly different than it is today. Google and Apple where nowhere near as relevant, Linux wasn't a viable option for grandma, and it appeared as though Microsoft would continue to dominate the industry just as it had in the 90's. If you wanted to name drop a company that everyone would know and recognize as a leader in the software industry, you would have used Microsoft as well.
Re: (Score:2)
From TFA [joelonsoftware.com] (the original, not the haphazard rewrite):