   The Joel Test on your own company
Found this link in the SE forum12 steps to better code: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? so now, for the company I work:yes: 1, 2, 3, 4, 5, 9, 11, 12no: 6, 7, 8#10 is difficult to say, because we have a very small testing team that is not on site and is not worth a damn. So, it exists, but it's inconsequential. I'm going to rate it as a "no". That gives my company a whopping 8 points, and Joel claims that "10 or less and you've got serious problems". Thank God we're not one of those 2-3 companies he talks about in the article.   
  My last job.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?Yes: 1, 3, 4, 5, 6, 7, 9, 10, 11 (well, I did anyway)No: 8, 12Icky: 2The one I was the most concerned about was 8.  I did complain about it but fixing this would have meant moving.  Usability testing isn't really a priority.  It works and the chances of error are minimised.  We only licensed the product to other similar institutions and provided training.  While extensive usability would've been nice, it wasn't quite worth it to overstress it passed listening to the user complaints and reacting.Webapps are hard to "build in one step".  Sure we could have a script that does all the uploading to the server and deployment, but the approach using maven targets was fine and more flexible.  "clean" "upload test" "upload production" "deploy application test/production" "update assets test/production" "deploy libraries test/production".   ;Quote:Original post by jfclavetteWebapps are hard to "build in one step".  Sure we could have a script that does all the uploading to the server and deployment, but the approach using maven targets was fine and more flexible.  "clean" "upload test" "upload production" "deploy application test/production" "update assets test/production" "deploy libraries test/production".You must be using the wrong tools, because when I write webapps I can build and run them in one swat of the F5 key.   ;Quote:Original post by capn_midnightQuote:Original post by jfclavetteWebapps are hard to "build in one step".  Sure we could have a script that does all the uploading to the server and deployment, but the approach using maven targets was fine and more flexible.  "clean" "upload test" "upload production" "deploy application test/production" "update assets test/production" "deploy libraries test/production".You must be using the wrong tools, because when I write webapps I can build and run them in one swat of the F5 key.Using a local webserver, probably, which wasn't an option in my case.If you were using a distant server, then building everything with F5 isn't flexible enough for me.  What if I only want the backend updated, despite having modified the frontend also ?  Different projects for each part might work, but, in that case, F5 wouldn't smoothly run it anyway.  In fact, we probably had a "do everything test/production" target.  I just didn't use it.I don't really see pressing 3 buttons as that much trouble.  "clean" "deploy" "upload assets" for a full from scratch cycle.  Or "clean" "deploy" if you didn't care about having the latests graphics/CSS.  And since deploy crushed everything, "clean" wasn't even necessary except when you actually removed file from the project.   ;  Yeah, you don't realize just how amazingly helpful it is to be able to press one button to clean, build, deploy, and run your application until you've experienced it. It is one less stressor to contend with, often in situations which are already stressful. It's also a good sanity check to make sure your build engineer is doing his job.   ;  Also, there are a lot of stuff missing to this list.  I know it wasn't meant as the ultimate benchmark of software development in an enterprise, but I would at least include stuff about (on the top of my head):- Code reviews- Different 'shades' of specs (overall project specs, technical spec, user interface spec...)- Training and technical leadership   ;Quote: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?Yes: 1, 2, 3, 4, 6, 7, 10, 11Sometimes: 5No: 8, 9, 12   ;Original post by capn_midnightFound this link in the SE forum12 steps to better code: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? During the 1990s, when I was making games, I can truthfully say that none of the companies I worked for could have ticked items 1, 4, 6, 7, 8, 9, 11 or 12.Then again, I developed mainly for 16-bit platforms back then. Some of them singlehanded. :)Depressingly, the last games industry corporation I worked at a few years ago, still lacked 2, 3, 5, 6, 7, 8 -- I _hate_ open-plan offices, 9 -- the source control software crashed frequently, 10 or 12. By the time I left, 15 months later, they'd rectified almost all of those except 7 (there was never any kind of design doc), which is nice.;  For my old job:1.) Do you use source control?CVS.2.) Can you make a build in one step?Notta chance.3.) Do you make daily builds?Nope.4.) Do you have a bug database?Nope.5.) Do you fix bugs before writing new code?Writing new code, what's that? The whole time was spent bug-fixing.6.) Do you have an up-to-date schedule?No.7.) Do you have a spec?Yes, i think so, but I never saw it.8.) Do programmers have quiet working conditions?Not really.9.) Do you use the best tools money can buy?Absolutely not! We had a guy who was brought in to optimise code - they paid him a years salary without getting many results, because they refused to buy him a profiler!10.) Do you have testers?We were the testers.11.) Do new candidates write code during their interview?I did.12.) Do you do hallway usability testing? Nope.A whopping 4 points, one of which was gained by default. Needless to say, the job sucked and I left as soon as was humanly possible.   ;  1.) Do you use source control?Um, SourceSafe, that's almost worse than no control. It crashes frequently and during the little time I've been here it has corrupted files at least once created  "ghost locks" a couple of times and it's a pain on daily basis.But Im currently tasked with evaluating options and planning migration.Switch to SVN is immenent and will occur when we upgrade our environment so soon.2.) Can you make a build in one step?Are you joking? I've tried to argue for this one but as it is today the build and deploy procedure is ridiculus. Hopefully I can get permission to create proper build scripts when we move from VS6 to 2005. 3.) Do you make daily builds?Yes. Mostly. And it's a pain.4.) Do you have a bug database?Does post it's and mail with totally random headers count. I guess not.5.) Do you fix bugs before writing new code?Actually we're quite good at this. It's on a devloper per developer basis but currently we all seem to share that mindset.6.) Do you have an up-to-date schedule?Uh, not one that I've seen. 7.) Do you have a spec?No, basicly my spec is something someone told me last week about a feature they would like because they said so. It's quite rare to get it exactly right from the start, espically since people change their minds on a daily (or better hourly) basis.8.) Do programmers have quiet working conditions?No, not a chance. We even have one guy sitting in the middle of a "sales island".9.) Do you use the best tools money can buy?Not close. But upgrades are around the corner so maybe we'll be close.10.) Do you have testers?They're called users ;)11.) Do new candidates write code during their interview?Nope, but they're given generic prope questions and problem sovling tasks.12.) Do you do hallway usability testing? Yes.He, that didn't fare to well. But people are quite aware of most of the shortcommings and it's actually a fine place to work despite how it sounds.   