Accepting a job that failed The Joel Test

Question

Similar to: How do I convince my boss that The Joel Test is credible and should be followed?

and possibly: Effective Ways to Introduce Agile into the Workplace?

---

I'm intentionally asking this question anonymously.

Summary: How can I improve the workplace?

I'm about to accept a job offer for a company that has failed The Joel Test with flying colors. These are the results from the interview I had.

1. Do you use source control? No.
2. Can you make a build in one step? No. The changes have to be copied manually to the staging server, then to the production server.
3. Do you make daily builds? Irrelevant; each feature is pushed to production as soon as it is done and tested
4. Do you have a bug database? No.
5. Do you fix bugs before writing new code? Yes.
6. Do you have an up-to-date schedule? Yes.
7. Do you have a spec? Partially.
8. Do programmers have quiet working conditions? Yes. Some work from home, some in the office. All meetings are done using Skype.
9. Do you use the best tools money can buy? No. They use free tools only.
10. Do you have testers? Not that I know of.
11. Do new candidates write code during their interview? Yes.
12. Do you do hallway usability testing? I don't think so.

This is not a new start-up that is just getting its feet wet, by the way. This is a company that has been around for years and only recently realized that they need to find some way to make money.

In other words, this is not an optimal place to be. I have to take this job for personal reasons and I probably won't be able to find any other job for at least a year.

Now, my question is how do I improve the conditions there. I am positive that within a few months I will be able to make a difference.

But where do I start? And how?

Answer 1

Baby steps. Change one thing at a time.

Take what you consider to be the easiest one with the biggest impact and attack it (i.e., maximize your "bang per buck"). That may convince "management" that it's valuable to change the way things are done.

Answer 2

Source control is always the best place to start. It gets people thinking about processes, and can lead to improvements in other areas. Specs can then be stored in source control (really a misnomer, cause lots of things that are not source can be stored there). Source control is the basis for many kinds of improved methodologies and processes.

If you can't win the source control fight, then you know pretty early if you can make any changes.

EDIT: As someone else said, it's really version control, not source control.

Answer 3

Source code control. Make it happen!

Answer 4

Get them to use Subversion (version control) and Bugzilla (issue tracking) (both free) and once they have seen the advantages, they'll be more receptive to your other ideas.

Answer 5

I would spend the first month or two getting a feel for how things currently work. Make note of anything that seems odd, but just for your own reference. Try to learn why they do things the way that they do without suggesting that they should do things differently. As you get a better feel for how things work (both from a process point of view and a people point of view), then you can start to make suggestions.

When trying to make changes, start with small changes. Since they've been around for years, there might be some resistance. Don't just tell people that you'll make their life better, show them how you'll achieve that. Get them involved in fixing their own problems so that they take ownership.

In the end, you may not be as successful as you would like, but at least try to make a positive impact so that when you move on to a better company, the people at this company will remember you for the good things that you accomplished.

Answer 6

1: should be a real problem. It will be very hard work to avoid regressions.

2: I think Joel is referring to the software build (make), rather than deployment (where a staging server to ensure you have everything together, particularly where installers are not used) is common (and good) practice.

4: Is there any tracking? A spreadsheet would likely be enough if defects are turned around reasonably quickly (and you are no spending time waiting to be able to update it).

8: will make working harder, very hard to build or maintain team cohesion without lots of face to face time. Will also make your part harder to recognise if you are remote (relative to the local members).

9: today free tools are better than ever (remember the Joel test was published over 8 years ago).

Answer 7

If you have the experience, you might suggest that they need someone in a position to implement these things.

If not, you might be able to bring in a consultant--sometimes management listens to consultants when they won't listen to employees.

Also, you could just use my magic trick I've used before:

Every day you get to work at 8:00 AM, you work exactly 8 hours, and you go home at 5:00 pm after a 1 hour lunch, then as you leave the building, you look back and say to yourself "95% of the people in the world do a WHOLE LOT more work for a WHOLE LOT less money.", then go home and do whatever you like to do best for 5 hours.

If you are pissed at the company and they are demanding longer hours, that 5:00 thing can be a stickler, but it's critical for not getting too depressed. You need a life outside of work.

That will get you through every possible unsatisfying programming job situation.

Answer 8

In my experience, not many companies I was able to see a job advertised would pass the Joel Test.

Some were actually good places to work.

I think my first job would probably fail all questions on the Joel test, and it was still a really great place to work, specially because it was my first job, and as I grew as a developer, I got enough encouragement from the team to implement some of those requirements myself.

As for the rest of your question:

Where to start?

As many here have already stated: Source Control!

I use git, and you will find that bitnami will give you most of the rest of the stuff you need.

My current company's main focus is not Software Development, so I am actually at this very moment in active trainning of managers as to the need of (Distributed or no) source control.

Git was the one I found, where I could easily implement this at a personal level, without the need to get infra involved and cause some sort of "trouble" in asking for resources in order to have something implemented, I am managing this from my workstation, because as I said, these people don't understand Source Versioning yet.

They think uploading zip files to a SharePoint list (which provides automatic versionning) is all they need, which is true.. to them, not to me.

I hope that slowly my use of real source versioning control, will start to make an impact by example.

And yes, I sometimes wonder what I'm doing here :^) but my point is: don't rule them completely out if they don't pass the Joel Test, it may be a good experience to be the one upgrading the company to a position where they stand a better chance of passing the test.

Answer 9

I picked up a new contract the other day and I was given 4 days to build an ecommerce website (but was not told of the deadline for about a week). Then, when I went over budget they suggested that I shouldn't use version control because it's slowing me down. Just code it.

Answer 10

I agree with @Scott's answer. Don't view yourself as the "new sheriff in town" who's here to clean it all up in one year. The habits they have settled into have been a long time forming.

Watch and listen, and ask questions about the most severe and recurring pain points. Find out what bad habits have actually caused loss of work, late nights, quality problems, or lost customers. Try to quantify the cost of these bad habits.

Then at some point talk to your boss in a one-on-one meeting and make a proposal for how you could mitigate one specific risk that seems to be their biggest problem. It could be almost anything on the Joel Test, but I'd guess it's most likely to be one of:

• No source code control means the code is a mess, with lots of "commented out" sections. Can't track which code changes were made for a given bug. It's hard to do major features in parallel with ongoing maintenance. No way to roll back changes. No way to track which developer did what changes.

• No build process means some code changes exist only on the live server. Developers are constantly pushing and pulling code to and from the live server. No one has a development environment that's in sync with the live code, so it's hard to reproduce bugs.

• No bug database means some tasks "fall through the cracks" from time to time. Customers report bugs that fall into a black hole. Managers don't know what's being worked on. Employees have no record of their work when it comes time for annual reviews.

When presenting the solutions, don't try to justify them with abstract concepts like "best practices" or "it's the industry standard way" or anything so intangible. If those were enough to motivate this company, they would have done it by now.

Instead, focus on what is their deciding factor. I'd guess it's probably related to how much time and money it costs the business to use best practices, versus how much it can save them. But you should find out if this is really their reason. It'll take some setup work to establish these tools and practices, but you can explain the recurring benefits for quality, productivity, and predictability of the development work. All those can contribute to the business' bottom line.

In one year, you'll be doing extremely well if you can make just one change to help them. It'll take a lot of patience to overcome a development culture that has been building for so long. Keep in mind that the rest of the team isn't there by coincidence -- they may actually be compatible with that level of disorganization.

Answer 11

Steps:

1. Convince them to use source control, install it, make it happen and help everyone use it.
2. Get a build process running without any user intervention required apart from kicking it off. No need for daily builds yet, baby steps. ;-)
3. Introduce a bug database. If that's hard, convince them to have global Excel spreadsheet with bugs. Once they're convinced, tell them the next step is to have a proper bug tracking system which has loads more benefits.
4. With more money, testers will come. It's your job to make sure management see the benefit of a different set of eyes on the product.

This environment should be good enough to work in. Do what is required to implement the new procedures. Explaining them properly over and over again might eventually get more people on your side.

Be careful not to change too many things too quickly. You're the new guy and don't want to let the guys that's been there longer than you feel as if they've been doing things wrong all along. You simply want to improve the systems one at a time.

Answer 12

No organization is perfect and it is fun to participate in the growth of an organization and help it improve through the use of best practices.

That being said, you may want to have a look at low hanging fruits.

Answer 13

Welcome to the world of entrepeneurship. Or, at least I hope that is the reason for failing the Joel test. If this is a well established company, you are in for some triage.

Source Control is the first step. It has the likelihood of causing the most damage. If you do not have source control, you are asking for major problems. It is also the easiest to get buy off on, as you can describe the problem and they have already encountered it if they have more than zero developers. I have personally bit myself by not having source control, so one developer is enough to add cost to a project with no source control.

Number two is to aim at some form of automated testing. This is where I deviate from the Joel test list, but I find computer science pretty lax without some science. :-)

Answer 14

I am but a humble college student, but at my first co-op (hi guys! don't worry, I still like you! :) they didn't quite meet all the requirements of the Joel Test, and I actually ended up setting up a Trac wiki for them. Because of management, they ended up having to use some other (not very good) system for bug tracking, but it's better than nothing. Showing tangible benefits of the process was I think what made them want to use the system. I put some documentation for some of my own projects in there, and now they're using it as an easy, centralized information source. I think if you find they're willing to consider new ideas and improve, then it can end up turning out for the better.

Answer 15

To reiterate some of what others have said, with my own points.

• Small steps are important. Test the waters with little changes before requesting really big ones. If this is an older company that has had some developers doing their current routine for years they may not be very open to change until shown the benefits.
• Source control is probably the best place to start as it will make everything else much easier and it can be implemented in small bits. You can setup SVN (or your system of choice) and put little pieces of their projects into it over time to show the other developers and, most importantly, your bosses, the difference it makes.
• Bug tracking is important but there's a lot of ways it can be implemented. You could go with something like Bugzilla or Fogbugz, but if you receive even a little resistance you can always start with a simple spreadsheet on a networked drive.

But what is, in my opinion, the most important thing, is to remember that implementing all these tools is a complete waste of time if no one else actually uses them. You'll need to make sure you work with everyone else there. If you absolutely love one bug tracker but the one they all want to use is one you don't like, comprise. There's no point setting up a real nice bug tracker when you're the only one using it.

You must also remember that other developers there have probably been successfully using the current system for a long time and must be shown the benefits first hand. You'll need to show that not only will these make your lives better but, as a result, they will make the non-programmers lives better as well.

I'm not claiming to know anything about this company or how it's run, but in many companies the non-programmers are the ones telling the programmers what they can and can't do. Trying to convey to a non-programmer the benefit of proper bug tracking or how important it is to use a good IDE is a pretty big up-hill battle. However, when they ask you to do a task and it's done in 1/4th the time it used to take, the benefits will start to become clear.

Answer 16

My advice would be to tread carefully. To quote:

"It must be remembered that there is nothing more difficult to plan, more doubtful of success, nor more dangerous to manage than a new system. For the initiator has the enmity of all who would profit by the preservation of the old institution and merely lukewarm defenders in those who gain by the new ones. " — Niccolò Machiavelli

Start with something small, easy to do, and that has a measurable immediate benefit. Then try to build on that. For example, you will probably have a hard time pushing #9, even source control will take some getting used to. But, a bug database should be relatively easy to setup and use. You can sell it to management as a better way to track progress.

In general you should always try to frame things in a ways that shows people how it will make it easier for them to do their jobs.

Answer 17

For starters, let me suggest you appreciate what you've got. Admittedly, it's a bit dated, but in Joel's original post of the test, he states that most shops score a 2 or 3, but you're going into a 5. I'm new where I am, and still learning things, but where I work, I'd say we're at 2 ... if I invoke hallway usability testing myself. At my last job, it was about 0.5 (we used source control for some of our stuff).

Otherwise, I'm on board with a combination of Scott's & Pax's advice: Don't rock the boat too soon, and do the simplest things first. Also, do things right for your own work (e.g. a personal source control repository and bugs database); by setting a good example, others may see the advantages.

Answer 18

I agree with all the comments to start carefully, silently. Here are my experiences:

Be a role model. Most won't notice at first, but pains are bound to crop up from the current practise and that's when you can show how your actions work well for you, and then extrapolate from there how these actions would benefit all, if implemented. It's more convincing afterwards with evidence like this, rather than being argumentative up front.

Use good tools, even if others don't. If they only use free tools, they must be lax on what actual tools are used. So use those that you think are best for the job, or the best ones you can afford on your own (=free). Use a bugtracker for your own stuff, use FogBugz if you want. Sneak in some improvements. Use a wiki for yourself, for your own stuff. When others ask, give them a link. Many intranets start the "grassroots" way like this but take off when more people realize the benefit. This can work for other tools as well.

Understand their point of view. Ask good questions. You may be right that you know better tools and better ways. But listen before you speak. Do they have good reasons for being in their current position? Think of ways how they can improve, step by step, as that is sometimes more likely to be doable. When you think you have a workable suggestion that is specifically made for this business, go to the proper guy and present it. Back it up with your experience there, with your tools usage, advantages you have had over their current process.

Be humble, but believe. They probably need somebody like you to lift them up to the next level. Appreciate that you've got the chance, and believe in yourself, but don't be too pushy. Earn their respect, or at least their understanding of "your way". They might not right away understand the benefits you're touting, so let them learn it at their own pace.

Answer 19

Go for something simple with management. I suggest trying to get them to buy into repeatability. It's a term that all companies want to be able to do well whether in tech, frying burgers, flying passengers, whatever.

I think joel points 1-5 are all really aids to help you get repeatable things in place. Processes that don't show easily repeatable things within them are a big problem. I think a management friendly thing for you to do when you join is go on a quest to add repeatability to the things they do.

Get buy in and then rock their world

If you get source control in, even if it's just on your box to start with. Then you can have a script to check out and build the thing daily. If you host use subversion then you could spin up Trac locally to help with a bug database, even if it's just for you. Then over time as your machine points out a problem in the build and you are on top of it you can point this stuff out as the timesaving device it will become.

Answer 20

There's a great article by Joel himself on working at an organisation that scores low on the Joel Test here: http://www.joelonsoftware.com/articles/fog0000000332.html

Hope this helps.

Answer 21

You know, I think about 85% of all programming jobs in the world would fail this test. Especially the last bit about hallway testing.

Answer 22

Don't be too dogmatic about the Joel Test, it's aimed at a particular brach of (shrink wrap) software:
I think this company scores reasonably well.

Do you use source control? No. Ok this is unforgivable, BUT it is very easy to just start using it and then get everyone else on board.

Can you make a build in one step? No. I think this is correct for a web enviroment. Should a bank fail if they mandated an air gap between development and production?

Do you make daily builds? - Again not necessary for a web app

Do you have a bug database? No. Are bugs at least tracked in email? Or just managers shouting at people?

Do you use the best tools money can buy? No. Free tools might be the best you can buy. Is the Linux kernel crap because it uses GCC?

Do you have testers? Not that I know of. It is tricky to make the financial case for full time testers. Especially on specialist software where the testers might have to be qualified doctors/traders/engineers as well.

Do you do hallway usability testing? I don't think so. You probably do discsuss how to lay out the pages with other programmers.

Answer 23

Unless you are being hired "to make a difference" be careful. I have beat my head against many walls trying to fix companies that didn't want to be fixed. I applaud your willingness to be a positive force for change, but one mans change can be another mans terrifying horrible disaster.

Just go into the situation with open eyes.

Answer 24

If the person in charge doesn't think all of that stuff is important, then it will never change. Don't take the job if all of that is important to you.

Answer 25

I was just going to comment, but the comments has more posts than the answers do.

FWIW, this company outscores mine by 2.5 maybe 3 points. I didn't know that at the time, and I thought I could fix it after I found out, but it turns out I really really can't. It's symptomatic of such deeply riven human problems, the business ones are beyond salvation.

It's been one of the biggest mistakes I've ever made and it's noticeably affecting my quality of life. I can't recommend enough to you that you walk away while it still doesn't cost you much to do so.

All these constructive optimistic recommendations about changing one thing at a time are critically flawed because they assume you have any power to do so. Chances are those who established the status quo will never see what's wrong with their comfortable prison.

Best of luck.

Answer 26

You're going to work for Twitter?!

Answer 27

Change Your Organization Diary details one man's attempt to effect change from the bottom up.

Answer 28

Looks like there is lot of scope to apply your knowledge in the field in this case. Take the job and start implementing yourself.

Answer 29

Seems to be a "nice" company with a big chance to do things better! What position do you apply for? If you get the chance, make the world a better place.

Answer 30

Teach them to use source control and bug database ASAP. These are pretty obvious things to do in any project, especially source control. Not using source control in 2009 is like programming on a 386 computer with mono monitor...

Automatic building would be nice too. Using free tools, on the other hand, is OK for me. I've been using free software (free as in beer, or as in speech) almost exclusively for the last few years and I don't feel like I'm missing something.

Answer 31

I tend to agree with most on this answer. Baby steps of course. I'd start with the Source Control and this is how I dealt with it before. I downloaded the latest copy of CVS (my favorite free tool back then, opinions may differ esp. now) and grabbed the latest production build, and created my tree with that. I'd commit my changes to the tree, as well as pull in all the other changes using WinMerge to determine what's changed on a fairly frequent basis and committed those changes as well.

One day the build wouldn't work and everyone was having trouble figuring out why, but I was able to roll back a few changes, made a succesful build and was the superhero of the day. Pretty soon after they found a junk server, put CVS there and migrated my work over. This is how stuff happens...