Tuesday, November 08, 2005

Day 189

For future reference, some notes on scanning.

  • For speed of scanning, I've just been using 1200dpi for most of the 35mm scans, bumping it up to 2400dpi for 120 format scans and for particularly interesting 35mm negatives.
  • Using 16-bit depth is fairly pointless from a practical point of view; there's a limited number of file formats that support it (especially for B&W: just TIFF and PNG, and the Windows software I'm using to scan only supports the former), and there's very little you can do with the images in Photoshop Elements. If I want to do pro-level stuff later, I can always come back and re-scan.
  • I probably picked the wrong option for scanning my chromogenic B&W film (XP1, XP2, T400CN); if I'd scanned in colour mode rather than B&W mode, I'd have got the benefit of the dust/scratch reduction. Apparently this works by doing a parallel infrared scan of the film—chromogenic film is transparent to infrared, but dust is opaque and so can be filtered out. The B&W mode turns this process off, because the silver halide in regular B&W films is also opaque.
  • ScanGear's UI really sucks; there are lots of things that you need to do all the time (examples: rotate more than one negative at a time, switch between film and print scanning) that can't be done easily. I can't believe that anyone ever tested this thing in real world use; it feels like they just tested that all the features could be accessed somehow, by some combination of manipulations, then shipped it.
  • ArcSoft PhotoStudio sucks too. It's awkward to do very straightforward things (e.g. rotate 90°), it defaults to its own internal format for 16bit files, but the main problem is the crashes. As far as I can tell (and I didn't really feel like experimenting that much), any time you pull in over 100 pictures, it crashes; I'd guess that this is because it titles the files "Untitled-Scanned-56" and thus only copes with two digit numbering. Again, it's clear no-one tested this thing in a sensible real world scenario. (I should probably have used the Windows copy of Photoshop Elements 2.0 that came with the scanner instead; I didn't want to use my Mac Photoshop Elements 3.0 because that would have tied up my laptop while the scanning was happening.)
<rant subject="testing">

The latter two points really bug me, as a (sometime) professional software engineer. Is it really that hard to actually test software in a realistic way before releasing it on an unsuspecting public?

The usual button that triggers this particular rant is Microsoft Project. Over the years, I've tried to use it for project management three or four times. The first few times I abandoned the attempt because it didn't support some particular thing I needed (IIRC, I don't think I could find an easy way to have a task whose size was proportional to something else, for example "Build mastering: 3% of overall project calendar time"), but on the last occasion I was only running a small part of a larger project and I didn't have the option of abandoning Project and returning to a big spreadsheet together with bits of paper.
[As Joel says, dependencies in software projects tend to be fairly straightforward. That being the case, the most effective way I've found for generating a Gantt chart is as follows.
  • Ingredients: several pieces of lined paper and some blu-tack.
  • Decide on a scale—say, one line per day, or two lines for a week
  • Write out a grid with dates down the left hand side of the paper (in accordance with the scale you just decided on), names of team members across the top of the paper. If you've got a hard deadline, draw a big black line across the page at the relevant place.
  • Using more paper and a pair of scissors, cut out a little rectangle of paper for each task in the plan. The rectangle should be roughly the same width as the columns you just drew on the other piece of paper (the ones labelled with the names of team members). Here's the cunning bit: the rectangular bit of paper should be the same height as the estimate you've got for the corresponding task, relative to the scale you decided on a moment ago.
  • If your rectangles are more than a few lines high, you've probably picked the wrong scale or (more likely) the tasks in your plan aren't really fine-grained enough to bother with a Gantt chart anyway.
  • Put a small piece of blu-tack on the back of each rectangle, and stick them onto the main piece of paper with no overlaps. The column each rectangle goes in indicates who's going to do the task; the rows it covers indicate when the task should be done
  • Don't forget to leave a few gaps in each person's column to allow for illness, slippage, unforeseen other stuff, etc. Leave bigger gaps for less capable team members (who are more likely to overrun on any particular task).
  • If you really do have to worry about significant dependencies, colour the top and bottom of the relevant rectangles (so if task A has to finish before task B can start, colour A's bottom edge and B's top edge the same colour).
This approach makes any of the common scheduling problems immediately visible.
  • If you've got any rectangles left over, you've not assigned all the tasks.
  • If any of the rectangles overlap, then some poor team member is over-assigned.
  • If there are large swathes of the underlying piece of paper visible, then some team member is under-assigned.
  • If any of the rectangle are below the big black line, then your plan doesn't hit your deadline
Interestingly, I've heard from a few teachers that despite the fancy timetable scheduling software you can get for schools, quite often the timetabling boils down to a similar technique. (One such tale involved screams of despair when someone opened the door at the wrong time and a draught blew in . . . hence the importance of the blu-tack).]

So I duly and diligently entered all of the tasks and subtasks into Project, entered all their sizes, set up all of the dependencies, and filled in all of the resource availabilities. Not a particularly huge project; maybe a hundred or so subtasks altogether. Then I pressed the "Level Project" button. This is the button that triggers Project to assign people to tasks and tasks to dates, respecting all the dependencies, and come up with a project plan, a schedule, a Gantt chart and most importantly of all, a project end date.

The end date it came up with was 24th February 2049.

Now, I'm happy to believe that this was because of something I screwed up—a circular dependency, or a mistyped estimate—but there was no error message, no warning. The auto-levelling is the only thing in Project that makes it more than just a wrapper around Excel with some different graph types. And it doesn't work. 2049. Not even a little bit.

(I did eventually consult with some of the other project managers on the larger project; their advice was: "Whatever you do, don't use the auto-level project button". These were the folk who'd insisted on using Microsoft Project in the first place: go figure).


No comments: