Joel Test Updated 182
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."
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.
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: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:A serious question (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: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.
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: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.