how to get 12 for joel test working in a small team of 3-4 on php website?

Question

Hi, I read this and I was inspired. I am asking for specific help to achieve a 12 for my current project. I am working in a team of 3-4 on a php project that is based on cakephp. I only have a dedicated server running on linux which i intend to have the website live on and i have a plan with assembla where i am using its svn repository. that's it.

I like to hear a major, impactful step towards answering each point raised by the joel test. by impactful i mean doing just this one thing would raise my project to scoring or close to scoring on that area of the joel test. Lets begin:

1) do you have a source control system? I am very proud to say learning how to use svn even though we know nuts about branch/release policies made the biggest impact to our programming lives. and the svn repos is on assembla paid plan.

Feel free to add if anyone thinks we can do more in this area.

2) Can you make a build in one step?

i think the issue is how do i define as a build?

i think we are going to define it as if tomorrow my dedicated server crashed and we found another server from another normal hosting provider and all my team's machines all destroyed, how are we going to get the website up again? my code is in svn on assembla.

1 step means as close to 1 button to push as possible.

3)Do you make daily builds?

i know nothing about this. please help. i googled and came across this phpundercontrol. but i am not sure if we can get that to work with assembla. are there easier ways?

4)Do you have a bug database?

we have not used the assembla features on bug tracking. ashamed to say. i think i will sort this out myself.

5)Do you fix bugs before writing new code?

policy issue. i will sort it out myself.

6)Do you have an up-to-date schedule? Working on it. Same as above. estimates have historically been overly optimistic. having spent too much time using all sorts of funny project management tools, i think this time i am going to use just paper and pen. please dont tell me scrum. i need to keep things even simpler than that.

7)Do you have a spec? We do, but its in paper and pen. what would be a good template?

8)Do programmers have quiet working conditions? Well we work at home and in distributed manner. so ..

9)Do you use the best tools money can buy? We use cheap tools. we are not big.

10)Do you have testers? NO testers. Since we have a team of 3, i think i should go get 1 tester. even on a part time basis. so i should get this 1 part time tester test in what manner to extract maximum effects? should i get him to write out the test scenarios and expected outcomes and then test it? or i write the test scenarios and then ask him to do it?

we will be writing the test cases ourselves using simpletest. i came across selenium. how useful is that?

11)Do new candidates write code during their interview? Not applicable. But i will do it next time i try to hire anyone else. hires or contractors alike.

12)Do you do hallway usability testing? Will do so on a per month or per milestone basis. i will grab my friends who are not net-savvy. they will be the best testers of this type.

Thank you.

Answer 1

I'm only going to address the items I have something to say about or you have issues with, anything unspoken we can just agree to or you've already passed. I think one problem Joel's list has is, you can only comply to it 100% if technical people have control over business decisions, and we can all agree that's not the norm.

2) Can you make a build in one step? One step building is nice, but as long as it's a fairly simple, streamlined process, I'm not going to complain, I find this issue pretty low of importance on this list.

3)Do you make daily builds? I'm soft on this point too, obviously a full daily build is the only way to be sure the whole codebase is kosher, inversely developers must be responsible to their own code, they should have their own dev installation and database and always be sure any code is stable/usable before committing it to the build. A daily build is always nice, but it's only critical if you can't trust your developers or they are sloppy.

4) Do you have a bug database? But what's most important of all is the bug/feature database. The real reason a database of features/bugs is important is because you need to log the issue, allow anybody to comment on it, and for a tester to review this and add their follow up to test the fix. If you don't have some kind of life cycle tracking for requests and bugs, things WILL fall through the cracks.

5) Do you fix bugs before writing new code? I'd love this, but in 99.9% of the world, the suits define what features you have, and they can be more important than bugs. This is something you should strive for, but reality makes it impossible to always comply with.

6) Do you have an up-to-date schedule? In regards to your situation, It's always better to over estimate and deliver ahead of time, than to over promise and under deliver. If you keep breaking your promises, the suits will have no faith in you.

7) Do you have a spec? Our company uses a commercial wiki solution ( Confluence ) and I'll swear by it. Wiki is a wonder way to digitally sketch your ideas and it's more than just a fancy web based text editor, you have checklists and more. In my opinion your choice of wiki software is key to it's success, they're not all the same.

9) Do you use the best tools money can buy? I don't think best and price has to go hand-in-hand, in fact the best PHP dev tools are cheap ( phpDesigner is my personal favorite ) or free ( everybody else in the company uses NetBeans). So don't confuse good tools with expensive.

10) Do you have testers? Developers make horrible testers, I would really recommend a professional tester, it's the only way you're going to find real bugs. But even if you can steal a secretary or somebody and have them hammer away at your app, it's a step in the right direction. Developers make HORRIBLE testers, and a developer is totally inept at testing their own code, at best they can attempt to test other developer's code. I realize you are a startup and the dev to tester ratio is 3:1 or higher, so you may not be able to convince the powers that be to pay for a tester. Being a startup sometimes you have to make sacrifices but you can still sell the idea that somebody outside of the loop needs to test. A simple analogy of laying bricks to make a 12 story building would work well on the suits. What happens if nobody is checking the bricks are all even, even being 1/100th of an inch off every time adds up to a colossal failure, and how are you going to fix that when you're on the 10th floor?

11) Do new candidates write code during their interview? Joel had a really good post about interview questions (which I can't find anymore), keep the question so simple that it can be coded on a white board without thinking (ex: write a function that figures out the area of a rectangle or the infamous FizzBang question). It the person needs to stop and think, that's a huge red flag. The question should be so easy that their hand is the bottleneck in writing out the pseudo code. I also award bonus points if the person does extra things like error handling ex: did they check if X or Y is negative, of course this assumes X and Y are length and width, are they numbers, what about ints vs float depending on your language. And when writing FizzBang I like the idea of doing 3 checks, one for Fizz, one for Bang and one for FizzBang. While not required, I do feel that merely allowing FizzBang to occur looks more like a bug than a feature if it's not explicitly coded for, a future coder might turn two IFs into in IF/ELSEIF and ruin the accidental FizzBang output (yes I'm splitting hairs).

12) Do you do hallway usability testing? Any non tech savvy tester is the way to go. And related to #10, you kind of kill two birds with one stone by using a secretary to test (mind you #10 is poorly satisfied with a non professional tester).

In regards to selenium, I know our professional testers have started using it and they swear by it, but I couldn't tell you a thing about it (I'm not a tester).