Keeping It Simple

Category: interviewing

  • Accepting a job that failed The Joel Test

    A user recently asked:

    I’m about to accept a job offer for a company that has failed The Joel Test with flying colors.

    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?

    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.

    I’m posting to my blog the questions I’ve answered on StackOverflow, which earned the “Good Answer” badge. This was my answer to “Accepting a job that failed The Joel Test“

  • Verifying a Company Uses Best Practices

    A user recently asked how to use the Joel Test in an interview, to confirm that a software company practices what they preach with regard to professional software development habits:

    I’ve got an interview with a company that claims to score a 12 on the Joel Test. […] What are some ways of determining if they really implement all 12 points? Are there any particular questions I can ask?

    It’s reasonable to say, “show me.” Ask them for examples and concrete details of their support for the Joel Test subjects. Since they claim they score all 12 points, they are obviously proud of it. People tend to like to show off, so they’ll probably be eager to share more details.

    If you ask more specific questions, it’ll become apparent from their descriptions whether they really have those good practices.

    We can think of many specific follow-up questions to the basic questions. The Joel Test questions are in bold below, and my follow-ups, er, follow:

    1. Do you use source control? What source control system do you use? Why did you pick that one? What is your branch/release policy? What are your tag naming conventions? Do you organize your tree by code vs. tests at the top with all modules under each directory, or do you organize by module at the top with code and tests under each module directory?
    2. Can you make a build in one step? What tools do you use to make builds? How long does it take to go from a clean checkout to an installation image? What would it take to modify the build? Is it integrated into your testing harness? What would it take to duplicate a build environment? Are the build scripts and tools also under source control?
    3. Do you make daily builds? What software testing tools do you use for daily builds? Do you use a Continuous Integration tool? If so, which one? How do you identify who “broke the build?” What is your test coverage?
    4. Do you have a bug database? What bug tracker software do you use? Why did you pick that one? What customizations did you apply to it? Can you show me trends of rate of bugs logged or bugs fixed per month? How does a change in source control get associated with the relevant bug?
    5. Do you fix bugs before writing new code? What is your bug triage process? Who is involved in prioritizing bugs? How many bugs did you fix in the last release of your product? Do you do bug hunts with bounties for finding critical bugs?
    6. Do you have an up-to-date schedule? Can I see it? How far are you ahead of/behind schedule right now? How do you do estimating? How accurate a method has that turned out to be?
    7. Do you have a spec? Can I read one? Do you have a spec template? Can I see that? Who writes the specs? Who reviews and approves the specs?
    8. Do programmers have quiet working conditions? Can I see the cubicle or work area for the position I’m interviewing for? (or an equivalent work area)
    9. Do you use the best tools money can buy? What tools do you use? Are you up to date on versions? What tools do you want you don’t have yet? Why not?
    10. Do you have testers? How many? Can I meet one? Do testers do black-box or white-box testing?
    11. Do new candidates write code during their interview? What code would you like me to write? What are you looking for by seeing my code?
    12. Do you do hallway usability testing? How frequently? Can I see a report documenting one of your usability testing sessions? Can you give me an example of something you changed in the product as a result of usability testing?

    Beware if their answers to the specific follow-up questions are evasive like, “um yeah, we are committed to doing more best practices and we’ll be looking to you to help us effect changes toward that goal.” If they’re so committed to it, why don’t they have anything to show for it yet? Probably because like many companies, when the schedule is in jeopardy, following “best practices” goes out the window.

    I’m posting to my blog the questions I’ve answered on StackOverflow, which earned the “Good Answer” badge. This was my answer to “Administering the Joel Test.”