reading
You Should Read
archives
- September 2004
- October 2004
- November 2004
- December 2004
- January 2005
- April 2005
- May 2005
- June 2005
- July 2005
- August 2005
- September 2005
- October 2005
- November 2005
- December 2005
- January 2006
- February 2006
- March 2006
- April 2006
- May 2006
- June 2006
- July 2006
- August 2006
- September 2006
blogs I read
- Caspian Arts
- Coding Horror
- ComputerZen
- Joel On Software
- Knowing.net
- MSBuild Team Blog
- Rob Howard
- ScottGu
- Scott On Writting
- Signal vs. Noise
- SimpleBits Articles
Tuesday, November 22, 2005
The Article of the Week 3
Title
The Joel Test: 12 Steps to Better Code
Author
Joel Spolsky
Description
The Joel Test contains a list of 12 steps to rate the quality of the software development. I don't see this as a list of requirements, but as steps towards being more efficient, and making programmers lives easier.
Our team has already taken 7 of the twelve steps:
1. Do you use source control?
4. Do you have a bug database?
5. Do you fix bugs before writing new code?
6. Do you have an up-to-date schedule?
7. Do you have a spec?
9. Do you use the best tools money can buy?
10. Do you have testers?
We plan on discussing the remaining steps to see if we all believe they are worth implementing, to what extent, and how to go about doing it:
2. Can you make a build in one step?
3. Do you make daily builds?
8. Do programmers have quiet working conditions?
11. Do new candidates write code during their interview?
12. Do you do hallway usability testing?
Because we work on so many different applications, step 3 (Do you make daily builds?) may be overkill for our team, but I think that it would make sense to build and run automated tests the day you make any changes to an application and check the changes into source safe. That seems like a big job now, but if QA guy keeps cranking out the automated tests, and we implement step 2 (Can you make a build in one step?) as a standard process, it could easily be a reality. There are many tools available that can assist us towards these steps. Some, like the NAnt build tool, are free.
Step 11 (Do new candidates write code during their interview?) nay be something to keep in mind going forward with any new hires, or for when we interview applicants for internships.
I like the idea of step 12 (Do you do hallway usability testing?), which, in a nutshell, is grabbing the next person who walks by your cubicle, pull them in, and giving them the choice of conducting usability tests on your latest app, or drinking the QA guy's coffee (you can cut it with a knife).
Currently we are in cubicles, but If our dream of being able to work remotely comes true, step 8 (Do programmers have quiet working conditions?) may become a reality.
Discuss why or why not, and how or how not, we should implement the 12 steps that Joel outlines. I would be interested in your thoughts and experiences regarding them.
Content copyright ©2003-2006 Tod Birdsall
The Joel Test: 12 Steps to Better Code
Author
Joel Spolsky
Description
The Joel Test contains a list of 12 steps to rate the quality of the software development. I don't see this as a list of requirements, but as steps towards being more efficient, and making programmers lives easier.
Our team has already taken 7 of the twelve steps:
1. Do you use source control?
4. Do you have a bug database?
5. Do you fix bugs before writing new code?
6. Do you have an up-to-date schedule?
7. Do you have a spec?
9. Do you use the best tools money can buy?
10. Do you have testers?
We plan on discussing the remaining steps to see if we all believe they are worth implementing, to what extent, and how to go about doing it:
2. Can you make a build in one step?
3. Do you make daily builds?
8. Do programmers have quiet working conditions?
11. Do new candidates write code during their interview?
12. Do you do hallway usability testing?
Because we work on so many different applications, step 3 (Do you make daily builds?) may be overkill for our team, but I think that it would make sense to build and run automated tests the day you make any changes to an application and check the changes into source safe. That seems like a big job now, but if QA guy keeps cranking out the automated tests, and we implement step 2 (Can you make a build in one step?) as a standard process, it could easily be a reality. There are many tools available that can assist us towards these steps. Some, like the NAnt build tool, are free.
Step 11 (Do new candidates write code during their interview?) nay be something to keep in mind going forward with any new hires, or for when we interview applicants for internships.
I like the idea of step 12 (Do you do hallway usability testing?), which, in a nutshell, is grabbing the next person who walks by your cubicle, pull them in, and giving them the choice of conducting usability tests on your latest app, or drinking the QA guy's coffee (you can cut it with a knife).
Currently we are in cubicles, but If our dream of being able to work remotely comes true, step 8 (Do programmers have quiet working conditions?) may become a reality.
Discuss why or why not, and how or how not, we should implement the 12 steps that Joel outlines. I would be interested in your thoughts and experiences regarding them.