The Joel Test [1] is a measure of how a team performs with regards to the best practices in coding. What questions, given a 'yes' answer, would subtract from the the Joel test score?
(Assuming you don't simply negate the current questions on the 'Joel Test', ie: "Do you have no source control?")
For example:
Do you do your development work on the live production server?
Is there a dress code which includes a suit and tie?
Is the chief technology officer an accountant?
Do developers have to account for their time in small increments?
Is refactoring discouraged?
Is the development team driven and controlled by sales people?
Do you usually promise to create the documentation after the software is finished?
Do you hire cheap people because they cost less?
Do you let inexperienced people create new products, but experienced people finish and maintain whatever is created?
Are strategic alliances (instead of technical merits) the main argument for resp. against the use of a technology?
Are you required to use Internet Explorer 6 at work and you do web development?
Guilty as charged. Ugh.
Does management think that paying a consultant to teach on-site classes is the most effective way for developers to learn a new technology?
Is there at least one case where a single person unilaterally makes software architecture decisions for more than three simultaneous, ongoing, non-trivial projects?
Is the coding standard an inviolable straitjacket that serves to hinder rather than inform?
Is Stack Overflow blocked at work?
Would management view time off to speak at a conference or other technical gathering relevant to your work as suspicious and/or unconditionally refuse it?
Do developers feel frustrated or stymied by managerial/organizational problems more often than technical ones?
Does your source control consist of physically backing up your source tree into a source.backup.n directory every time you want to make too many changes?
Did the last developer you hired leave quickly? Usually high turnaround in IT means at least one of two things: A) The code is wretched and unmaintainable, and/or B) Management has highly unrealistic expectations about programmers.
Also: Does the team not care about learning new things, experimenting with new technologies and at the very least check out what's "new" in their programming world? If they are like this then it means the team is a bunch of incompetent Morts and are mediocre at best.
Is the primary development language an in-house only product?
I have seen way too many Daily WTFs where people were stuck developing in a language that was designed, built and consumed solely within the company. That would be a -10 for me.
Do I need to work weekends just before a big release?
Does the average developer have more than 3 hours of meetings a week?
Are working hours strictly enforced? Am I supposed to work 9-5 daily with no exceptions?
Do you expect developers to serve support requests while doing project work?
(= Do you let the urgent override the important?)
Is there no coffeemaker?
Are your developers unhappy?
Do they hire developers primarily based on academic degrees?
Does the build/deployment need 10 different manual commands which only one guy knows about?
Is unpaid overtime a regular occurrence, and nothing is being done to change that?
EDIT: StefanB notes that some overtime might be normal. I don't disagree with this, and in fact when I'm passionate about a project, I will give it of my own volition. But I've been in places where some is expected of the employee and is programmed into the schedule; I'm not talking about emergency situations that require occasional heroics, I'm talking about sizable chunks of time that show disrespect for the employee's personal time.
The law states you are paid for a standard work week of 40 hours. Dedicated employees have no problem giving a little extra, but when it's chronic or counted on by management, and that same management isn't comparably dedicated to offering comp time or overtime pay, that's when people are justified in being upset about it.
Is there a dress code for "dress-down Friday"?
Are rules set in stone, even if the programmer have a good reason to break them?
This is actually why I dislike places that requires a suit - it is not the suit itself, but the attitude that the company conveys where appearances are more important than functionality.
Here are the first two that popped into my head:
Are suggestions about programming techniques or implementation details from non-technical people taken seriously by management?
(As a corollary) Do employees from multiple departments without an ownership stake in technology make suggestions about programming techniques or implementation details and expect to be taken seriously?
Have you upgraded to Fortran 77 yet?
Is developer regularly (once a month) asked to complete numerous online courses prescribed by management to tick some bigger company-wide goal that is completely irrelevant to what developer is paid for (e.g. ethic course, personal goal management course, meeting your goals course, how to use your new time tracking tool in 50 easy steps course, be happy at work course ...)?
Do management judge projects by their costs only and are unable to judge them by their value earned?
Are you the only developer?
Are you obliged to participate in the company's "must" events?
We had to perform a City-rally, according to the predefined plan, make photos of predefined objects, find out questions to specific answers and be in time for evening restaurant (cheap bar, I only got a cup of coffee). It's either I miss something or I'm glad I'm not German.
Are they one-deep in any critical positions, like Oracle DBA's? So when the one guy goes on vacation you're hosed?
Do the developers work on multiple projects in parallel?
Do the developers use print statements for debugging? (usually implies no IDE is available and the systems are ancient legacy system)
Do the developers need to work on other tasks, such as maintaining servers or desktop support?
So the guy in charge of software development has never been a developer?
Has management imposed KPI's to measure individual programmer performance?
Are your developers working on single-monitor workstations ?
More thoughts regarding this topic on ServerFault [1]
[1] http://serverfault.com/questions/1782/exclusive-of-cost-what-is-the-ideal-monitor-set-up-for-a-team-of-programmers/3935#3935Did they lie to you in the interview? (That should be worth -10 or so.)
Does the number of new feature requests correlate to the length of time the CMO was stuck at the airport with his Blackberry?
Do employees have to fill in an hourly timesheet?
Is Ie6 the primary browser Org wide?
How many Dilbert cartoons are posted on your cube / office walls?
This is doubly-damning for some organizations. Not only are the employees making not-so-subtle commentary about their work environment, they're also telling me "we're cliched Scott Adams characters just as much as the management!"
"Pointy-haired boss! Hur hur!" ... Spare me!
In the interest of full disclosure, my cube currently has three xkcd and one Penny Arcade strips.
Do the developers think that they can keep every bug/issue in their minds, and therefore use no issue/bugtracking?
Are there no programming questions when interviewing a new developer?
! (
is there a QA department?)
This has probably been answered but.
Have the developers been asked to find "creative solutions" to meet unrealistic deadlines?
Do you have to Google Traslate/Babelfish the dev specs, business analysis docs and/or client requirements?
Do you test in production (load testing or otherwise) just because you can't mirror your production environment in a test environment?
Are you forced to use an ill designed hungarian syntax?
Do you plan when to do refactoring? (If refactoring is something you plan, then people aren't doing it all the time, when required. If the business prioritise what's on the plan, you're also letting non-technical people make decisions about essential technical work).
A related one:
Do you branch before refactoring? (You're not breaking refactoring into small, low-risk steps. You're not sharing the work between those working on the branch and those on trunk. You're introducing merge hell between trunk and the refactored code.).
I've seen both of these many times, sometimes on the same project.
Are projects managed merely to fail as cheaply as possible?
Do you not work for a company that develops and sells software?
Does the only connection of developer workplaces to the internet go through a HTTP proxy that is limited to ports 80 and 443?
Do you have proxy authentication in place? Is it configured to Basic Authentication? Does it lock the user profile on 3 failed authentication requests?
And because it's in perfect harmony with the above:
Is there computer policies in your company that interfere with your daily work?
Is the team all male (or all female).
On a small team it probably doesn't matter but when you have a larger team that is single sex it quickly leads to a poor working environment.
Do you have the feeling that dilbert strips are not funny, they just describe your daily experience?
When developers make changes, and unit tests break, do they always simply delete them, no questions asked?
Do they measure developers by SLOC or LOC?
Do you have to fill in TPS reports ?
Do you spend more time waiting for your project to compile than actually writing code?
How much paperwork is required for a database modification?
Do you have clean restrooms for me to poop in?
Do you require development from janitor closets?
Do you have a real network that does not require Remote Desktop Connections?
Will you pay for my lunch? Every once in a while at least?
Do you laugh at developers when they tell you they need new hardware?
Technology
Source control
Development methodology
Developer consideration
Organization / Management
Does Technical Support have the authority to ask developers to help troubleshoot a problem without first performing due diligence?
Do you develop your softwares on the same plateform for 10 years
Here's the cowboy contractor edition...
Does the employer negotiate a request for an increase in pay by not paying at all?
Are you interviewing 1099 programmers because you think 10-12 bucks an hour with no benefits/tax contributions/incentives is a reasonable and good strategy to save money on the bottom line?
Does your boss still use AOL as a web browser?
Is the project manager currently reading self-help books because this is the first 'real' project he's managed?
Has the project manager stonewalled with the other (and more senior) developer and attempted hostile negotiation the week of CDR (Critical Design Review) because he thinks it's a good tactic to 'up his cut?'
Note: By stonewalled I mean, convinced the other developer to not commit his work to the repository during the month leading up to CDR.
Does the contracted (and highly paid) integration specialist spend the full week of integration writing his portion of software from scratch and leave without any testing?
Are there features being added into the spec (preventing it from being frozen) as concessions because the project manager (who had to be dumped from the team) created an initial schedule that was impossible to meet?
Do the Customer's employees expect periodic out-of-state on-site support to teach them how to code in a new language and how to run a windows based system (that any teenager could handle) even though the the customer explicitly opted out of the on-site training portion of the package?
Does project tracking consist of a many concurrent/conflicting versions of a word document containing a table of problems with the project (not just bugs)?
Does the customer techs need numbered step-by-step procedures for every conceivable task that could be done on said system because the windows control panel is 'advanced stuff?'
Does the customer developer's decades of extensive experience with SCM (Software Configuration Management) consist of copying a new source file and incrementing the numbered suffix in the filename?
Is the computer you're attempting to interface with using a custom proprietary variant of Unix and still running the version written in the mid 80s?
Are the computers you're interfacing with taller than you and have 1000th the processing power of the cell phone in your pocket?
Or my personal favorite...
Does the customer default to reject 'good' advice on the grounds that they prefer to save a nickel by spending a million?
And... people think that working from an air-conditioned cubicle with sub-par-quality coffee is bad... Try to be the guy who's pulling his hair out trying to convince everybody else on the project that adopting version control is a good idea because none of them have even heard of it. Or being a junior developer with no guidance and little experience making critical make-or-break decisions about the project because no one else has a clue.
I feel like I've earned a pair of spurs that would complement a nice pair of shiny rattlesnake-skin boots.
Do you write design documents in MSWord (instead of a company wiki)
Is your entire developer team a Monoculture (in terms of Operating System, Programming Language, IDE etc.).
By this I specifically mean do they all share the exact same opinions about these things, or is there free debate over them.
Do they use dial-up?
Is the Testing Plan, for a given piece of software, developed after the software itself is developed?
(The Test Plan should be using the Requirements as its basis rather than the software.)
Do they mix EJB, Hibernate, SQL in .properties files, and a custom code generator?
Do you have more active code branches than team members?
Is it a top-down company or are teams self-organizing?
Are you confined to non-open source tools (because it "hasn't been tested")?
Is people manager making code production decisions (e.g. you need to split coding that module in 5 parts because I give you 5 people, could you have test plan finished a week before requirements are completed so that test developers can start implementing test cases ...)?
Is the build process manual? Does it have a dedicated "build person", and take hours to produce one build, assuming nothing goes wrong?
Are you required to restart your development box at least once a week?
Even though developing for Linux/Unix systems it always feels like Linux development environment is only an after-though. You're given Windows box and have to open millions of terminals and work remotely using vnc with minimalistic setup to not burden the server where every other developer uses Window box. Not to mention that you have to 'restart' once a week when critical patches for software are applied.
Where are those companies using Mac OS only environment?
EDIT:
Oh did I say "at least once a week"? It's becoming more like once a week but every forth week apply new patches so three restarts a week are required.
Someone in my office made a point that Monday morning restart of window box is ok BECAUSE IT"S AFTER WEEKEND. I told him that it's like to expect to take your car to service every Monday, because it's Monday and the car is expected to run for the rest of the week.
Sorry if all these restarts are norm in Windows world and people got used to that but my Mac Book Pro I use at home gets restarted about once every two/three months unless I left it unplugged and it runs out of power ... but that does not happen often.
Are your designs disregarded because they're not inline with the company's [secret] vision?
Do you only write Unit Tests after the development is done ?
Do your unit tests take longer than 1 hour to run?
Does your company have a causal dress code policy all the time or only when no 'VIP' are walking around?
I was sold on casual dress code (jeans/T-shirts) during inteviews, I was told not to dress up for interview but more and more often we get email notifications that for next one/two weeks no t-shirts or required black trousers/shirt code ...
Recently seen:
This is a true indicator of cluelessness.
Do you write test plan only after the software is complete? (as opposed to, during development)
Are your programmers reluctant to show work in progress?
(As in "can I freely edit stuff of others", notifications vs priviledges, etc)
Is developer productivity or performance evaluated by metrics such as "lines of code written" or "number of bugs fixed"?
Is third party software managed by a central purchasing department that applies the same rules and timescales to software purchases/licensing the it would to office supplies?
Does all internally approved 3rd party software have it's .msi rebuilt and wrapped in a proprietary scripting language, inevitably breaking perfectly unusable installation processes? Do you have to wait 2 months for an offshore vendor to write this script?
Do you strongly enforce code-generation tools to shelter your programmers from the confusing intricacies of programming?
Is there a "rock-star" developer within the group?
Is the metric of quality done fast?
Are the architecture, analysis, and tests performed by straight-out-of-school developers, paid the salary of a developer, and with the sole title of "developer"?
"Has marketing a higher budget than development?"
Do your developers look puzzled when you ask them where their customer requirements are?
Do the software developers have to waste their time dressing up with anti-ESD coats and shoes to go accross the production floor into the warehouse to pick up their just-delivered SW/HW tools?
Are you forced to implement system changes recommended by non-programmer users that will threaten the security/integrity of the system simply because the non-programmer user "thinks like the customer"?
Do you provide a full proof for your software?
Do you fix bugs before writing new code?
Oh... wait a minute... that one's actually number 5 on the actual Joel Test. I wouldn't want to work for any company that answered "yes" to this one.
If you want an explanation, why don't we turn to Joel himself? In an article written only a year after the "Joel test", he explains why Fog Creek don't fix bugs before writing new code [1].
[1] http://www.joelonsoftware.com/articles/fog0000000014.htmlBut mostly, it's worth fixing bugs. Even if they are "harmless" bugs, they may reduce the reputation of your company and your product, which, in the long run, will have a significant impact on your earnings.
" - Joel Coehoorn
Are you still using Waterfall?