The 12 questions were originally developed by Joel Spolsky a former program manager at Microsoft that worked on Excel. Under each question additional observations from my experiences.
-
Do you use source control?
If not you are out of control. Even with a single developer.
All code, support programs, build files, help files, etc, should be put into the repository. Code should be checked-in frequently once it is in a state that it is not likely to cause problems to other developers. A private branch can be used to check-in intermediate work without affecting other developers, to be merged into the main project branch once it is in a stable state.
-
Can you make a build in one step?
This is the only efficient way to make sure you are not introducing human error into the build.
-
Do you make daily builds?
Computers are only too happy to work overnight. Continuous integration helps make integration weeks a non event.
-
Do you have a bug database?
MS Excel doesn't count. Resist all attempts by the program manager to export the Bug List to Excel! Anyone (including customers) should be able to log a bug. Don't stick the bug database behind your corporate firewall. It leads to MS Excel documents.
-
Do you fix bugs before writing new code?
Important ones anyway.
-
Do you have an up-to-date schedule?
Vacation schedules. Agree upfront that vacations are sacred. The project team should be able to do without a team member for awhile. Release schedules are also important although problematic.
The word just should NEVER enter a schedule discussion....just means it should already be done.
-
Do you have a spec?
Not a novel. A spec may be a cocktail napkin, UML diagrams, UI Mockup whatever is useful. Define useful as someone actually reads it and comments on it!
On UML
UML gets a bad name from Use cases. All those little bubbles and stick figures. Who cares? They are really the beginning not the end. Use cases should turn into activity diagrams etc.
One of the things that I find amazing is that you can write a hundred page spec and get no comments but you can present a series of UML diagrams and get everyone to actually read them! A picture is worth a thousand words.
-
Do programmers have quite working conditions?
Quite conditions for coding. You also need a team area for integration and testing.
-
Do you use the best tools money can buy?
Money isn't everything but it sure helps build and infrastructure. Lots of applications don't cost money these days but hardware and infrastructure do. Don't skimp.
-
Do you have testers?
Should be familiar with things like virtualization.
-
Do new candidates write code during their interview?
Spend time interviewing candidates. New people are disruptive.
-
Do you do hallway usability testing?
Solicit others input.