Maximum PC

The original article: http://www.joelonsoftware.com/articles/ ... 00043.html I was introduced to this by my supervisor. It's a 12 yes/no questionnaire designed to evaluate the efficiency of a team of software developers. And those 12 questions are...

1. Do you use source control?
2. Can you make a build in one step?
3. Do you make daily builds?
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?
8. Do programmers have quiet working conditions?
9. Do you use the best tools money can buy?
10. Do you have testers?
11. Do new candidates write code during their interview?
12. Do you do hallway usability testing?

I guess it's something to think about at your workplace.

I remember going through this list back when I was working at Boeing.

1. Do you use source control? Yes
2. Can you make a build in one step? Yes
3. Do you make daily builds? No - I don't really see why a daily build is that important though either. Wouldn't a weekly build suffice?
4. Do you have a bug database? Yes - Amazingly, I worked on five or six different teams at Boeing and each team had their own 'bug database' and processes and sometimes terminology for dealing with 'software change requests'.
5. Do you fix bugs before writing new code? No - Usually we had to document the problem; Fixing things makes people look dumb (the people in charge), so you shouldn't do that... makes you want to walk into a brick wall at times.
6. Do you have an up-to-date schedule? Yes, that was reviewed for at least a half hour every day.
7. Do you have a spec? Not sure what he is calling a spec.
8. Do programmers have quiet working conditions? Yeah, for the most part.
9. Do you use the best tools money can buy? Yes / No.
10. Do you have testers? The larger teams had testers, but amazingly, only the small teams used automated testing.
11. Do new candidates write code during their interview? When I was conducting interviews, we _grilled_ people.
12. Do you do hallway usability testing?

The smaller teams did some of this.

The Joel test is nice, but it's not a perfect fit for many orgs. I work as a consultant, so maybe of these are just not in our vocabulary/

1. Do you use source control?
2. Can you make a build in one step? We can, but depends on the project (CMS, no. Custom from scratch, yes)
3. Do you make daily builds? Depends on the project
4. Do you have a bug database? Yes
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? Yes (our spec is our contract)
8. Do programmers have quiet working conditions? Hahaha, yeah...no
9. Do you use the best tools money can buy? Nope (I make do with open source tools)
10. Do you have testers? Yes (we have an entire department)
11. Do new candidates write code during their interview? YES WE DO.
12. Do you do hallway usability testing?

Nope

Just curious, has anyone worked at a company which did daily builds? If so, did it help with anything? What? Note, I'm assuming a daily build means that you check in any changes that you made during the day. I really can't imagine how this helps a team (assuming that the code was created with some conception of high cohesion and low coupling that way changes in module A won't crash module B). Perhaps daily builds only applies to software that is in the maintenance phase of the software lifecycle?


This was actually a funny thing about Boeing. Every single team had a homegrown Software Change Request (SCR) system; Each group also had different processes for handling change requests (ie bug reporting). This is partially a consequence of the many varied software groups that work at Boeing (in terms of programming languages, products, hardware, age, etc). However, I thought it was kind of retarded that a very general system that could be customized was never considered.

I'm also curious about the experiences of those folks that have worked on the .NET side of the fence in regard to source control and bug tracking.

Since this topic is kind of related to work environments, I thought the following articles might be of interest to people reading this thread:

http://www.inc.com/caitlin-berens/start ... break.html

http://www.inc.com/joe-reynolds/give-yo ... -time.html

I've only been in one project where we made effective use of daily builds. I'm a big fan of it but not for all purposes. It helped us with client interaction and feedback: checking in triggers a build, the build script dumps the results (if it passes) to a network drive that IIS referenced as our client staging site. Most of the projects I've been on never really used daily build correctly (it was mostly for show/kicks and giggles)...I found great success in using it for hallway usability testing since it provides immediate feedback to the client. Also we used this on new builds (when I worked in consulting), we had Data Initialization scripts from Entity Framework to drop/recreate the database and pre-populate it with data.

As for bug databases? We used whatever was free. I think we used TRAC at my last job, which I hated.

From the .NET side of things, there's really not a whole lot to it. I just made sure that we followed a protocol for testing, we standardized test formats, made sure that the client is aware of our daily builds and let my PM handle the client 99% of the time.