tag:blogger.com,1999:blog-58192482019216569592024-03-05T20:45:20.617-05:00Jim's Reflections on SoftwareMy thoughts and experiences creating and managing software.Unknownnoreply@blogger.comBlogger22125tag:blogger.com,1999:blog-5819248201921656959.post-73469075854079850892014-07-26T06:25:00.000-04:002014-07-26T06:25:48.087-04:00Moving from Apple's Aperture to Adobe's Lightroom (Part 2)<div dir="ltr" style="text-align: left;" trbidi="on">
<div class="separator" style="clear: both; text-align: center;">
</div>
<b>Ten days ago</b>, I began a trial of <a href="https://lightroom.adobe.com/" target="_blank">Adobe's Lightroom</a> after I learned that Apple would be retiring their pro photography software, Aperture, and their consumer photography software, iPhoto, in favor of a new product called <i>Photos</i> that will (supposedly) serve both constituencies (see <a href="http://www.macworld.com/article/2375212/apple-retires-aperture-and-iphoto-to-be-replaced-with-photos-for-os-x.html" target="_blank">MacWorld</a> for the announcement). In "<a href="http://swblog.jimkile.com/2014/07/moving-from-apples-aperture-and-adobes.html" target="_blank">Moving From Apple's Aperture to Adobe's Lightroom (Part 1?)</a>," I noted some missing, "fixed" (from an Aperture perspective), and "new" features in Lightroom and concluded that things were promising thus far. Before the end of last week, but after my last post, I had also installed a trial version of Photoshop as well, since that would come with the same subscription as Lightroom. What follows is some of my additional thoughts.<br />
<br />
<div style="text-align: left;">
<span style="font-size: large;"><b>Alignment, Cropping, and Color Correction (Lightroom)</b></span></div>
<br />
The alignment, cropping, color correction, and all of the general development tools (sharpening, noise reduction, etc.) work quite well. In many ways, I like the way Lightroom handles these tasks better than Aperture. I have also come around a bit on the "auto" function, but I still think it does not estimate exposure correction anywhere near accurately. It does provide a good starting point, though, for photos that need relatively little work.<br />
<br />
For photos that were slightly crooked and needed color correction, I was able to re-align the photo plus match the colors to what I believe my eye saw. (Note the richness of the wood doors with Samantha and Benjamin posing in front in the example below.)<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh-zUt2cbrgHqtJb30szKZ9z7_RQm0dqbOiIq-pOFw0MoWO2GD-acr9dQMLlhKUkIVi4PUe-CcnS9YgjDGioEBstWT1hfmz_YGlvT-E2DfwFFdpCeQZQnNgogZjhaQ2CAxnVYcnRU5Tqwxu/s1600/Cropping+and+Adjustment+Example.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img alt="Before and After: Alignment and color corrected." border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh-zUt2cbrgHqtJb30szKZ9z7_RQm0dqbOiIq-pOFw0MoWO2GD-acr9dQMLlhKUkIVi4PUe-CcnS9YgjDGioEBstWT1hfmz_YGlvT-E2DfwFFdpCeQZQnNgogZjhaQ2CAxnVYcnRU5Tqwxu/s1600/Cropping+and+Adjustment+Example.jpg" height="310" title="" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Before and After: Alignment and colors corrected.</td></tr>
</tbody></table>
In addition, I have become rather fond of the "Before" and "After" functionality. The example above shows the full picture, but you can also cut the picture horizontally and vertically with the before and after sitting as a piece of the entire picture, which is very convenient.<br />
<br />
While most of the controls were pretty straight forward, I seems right to call out the usability of the alignment function: It works well, but is less intuitive than in Aperture where you just have to move the photo within the grid (Lightroom relies mostly on a slider). <br />
<br />
<span style="font-size: large;"><b>Where is the AF Point (Lightroom)? </b></span><br />
<br />
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; text-align: right;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjFfxczwdxgyarxw0yKBUMMef1FV7XP92lBi58y7UMh059sF5YSaklU6HadcCU69a2qj0yHnL8Z591HGTJjWuKLpAfftfLDFiiwYhv9ZpIgyapItS6-vWvPuuv_WjeFP2QxDgedWQnObuYR/s1600/DPP+AF+Point+Example.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img alt="Canon's Digital Photo Professional with AF Point(s) shown." border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjFfxczwdxgyarxw0yKBUMMef1FV7XP92lBi58y7UMh059sF5YSaklU6HadcCU69a2qj0yHnL8Z591HGTJjWuKLpAfftfLDFiiwYhv9ZpIgyapItS6-vWvPuuv_WjeFP2QxDgedWQnObuYR/s1600/DPP+AF+Point+Example.jpg" height="220" title="" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Canon's Digital Photo Professional with AF Point(s) shown.</td></tr>
</tbody></table>
One thing that perplexes me is that Lightroom cannot display the AF point from the camera as an overlay on a photo; the functionality does not even exist. I read a bunch of forum posts that seemed to say this was a difficult thing to do, etc., yet Aperture does it (at least before the photo is developed). Canon's own <a href="http://learn.usa.canon.com/app/pdfs/quickguides/CDLC_DPP_QuickGuide.pdf" target="_blank">Digital Photo Professional</a> software can also show the AF point, so that's what I used for those photos where I wanted to know. I also still use Canon's software if I need to examine the original RAW file in a little more detail without even the basic processing done on import into something like Lightroom or Aperture.<br />
<br />
One might think that the lack of AF Point overlay functionality is a nit, but that focus point comes in handy in low light situations. Notice that the photo in the example is slightly blurry (more on that later) due to camera shake. I was able to correct it in Photoshop, but needed to know where I had set the focus point to understand what parts were blurry due to the shallow depth of field I used (f/2.8) and what parts were blurry because of camera shake due to such a slow shutter speed being used (1/10 sec); this is small, but situationally important, function.<br />
<br />
<span style="font-size: large;"><b>Visual Cues for Stacks (Lightroom Usability)</b></span><br />
<br />
One of the things that I have had some difficulty figuring out is where a stack begins, ends, or if a frame is part of a stack or not in the filmstrip. I tend to use stacks for two purposes: to group bracketed photos or to group corrections or fundamental changes to a photo, yet I want to still keep the reference image. My last outing was to <a href="http://www.nps.gov/vama/index.htm" target="_blank">Vanderbilt Mansion National Historic Site</a> in Hyde Park, NY. The day was both cloudy and bright (high contrast), so my outside pictures tended to be bracketed. I put those in a stack:<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi4fdxHb4sLS53EjaK6yx2s67-EoQJcKjNTzSKCVkn_SQhehh2pncJcX1SYeiKBCrn37EIYql62aMVTK9zwnOdyPNUUgVNSf0UxKAE7KScOFvBNdzclvRmTH_FWNP6IMfp7GFTzj2IrAA3Z/s1600/Stacks+%25231b.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img alt="Two stacks of bracketed photos. Note that there are very few visual cues except for the [3] at the beginning of the stack and the very light break line at its end." border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi4fdxHb4sLS53EjaK6yx2s67-EoQJcKjNTzSKCVkn_SQhehh2pncJcX1SYeiKBCrn37EIYql62aMVTK9zwnOdyPNUUgVNSf0UxKAE7KScOFvBNdzclvRmTH_FWNP6IMfp7GFTzj2IrAA3Z/s1600/Stacks+%25231b.jpg" height="108" title="" width="640" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Two stacks of bracketed photos. Note that there are very few visual cues excepting the "[3]" at the beginning of the stack and the very light line break at its end.</td></tr>
</tbody></table>
<div class="separator" style="clear: both; text-align: center;">
</div>
The problem is, there are no visual cues to show when the stack ends or that these photos are part of a stack with the exception of the number listed on the first photo and a very thin (almost imperceptible) line at its end. If I hover over (or select, as in the example below) one of the members of the stack it does note that it is photo <i>x of y</i> (where <i>x</i> is the sequence of the photo selected and <i>y</i> is the total number in the stack): <br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiczvoIBvKOST4IYqbtQAnLmHkIl3Xw8s7PtkJz6nea7Y57VlNVS3UvqTzkxlLLk2IDbzNPK9ZGTh3eE8VOl6Ra6diGDfDqXA-KllCe5QCPsCvD0_PIMpeh1qsrIomSfBZvrMt60xrHDUx9/s1600/Stacks+%25232.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img alt="Two stacks of bracketed photos. Selecting a photo in the stack reveals its position in the stack relative to the beginning." border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiczvoIBvKOST4IYqbtQAnLmHkIl3Xw8s7PtkJz6nea7Y57VlNVS3UvqTzkxlLLk2IDbzNPK9ZGTh3eE8VOl6Ra6diGDfDqXA-KllCe5QCPsCvD0_PIMpeh1qsrIomSfBZvrMt60xrHDUx9/s1600/Stacks+%25232.jpg" height="104" title="" width="640" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Two stacks of bracketed photos. Selecting a photo reveals its position relative to the stack's beginning and end.</td></tr>
</tbody></table>
I eventually used the tagging feature to color code my stacks. I primarily used red, but when stacks were next to each other I used purple to alternate. It is an easy way around the problem I had seeing them, but some better visual cues would seem to be in order. I should not be guessing whether something is in a stack or not.<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj6q6ufe8Jyft083Tkpe4qsiqfHxVglqLIr2-xdvygLyzaLTSwzJKowUpGPPBlSETW92t4UsNo7DgS4gVP-PenOWX4GHbp4W3H69ZoxlvY5XZAvIize48gOaeoPoaCjUSZyInJxcyUAEk6z/s1600/Stacks+%25233.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj6q6ufe8Jyft083Tkpe4qsiqfHxVglqLIr2-xdvygLyzaLTSwzJKowUpGPPBlSETW92t4UsNo7DgS4gVP-PenOWX4GHbp4W3H69ZoxlvY5XZAvIize48gOaeoPoaCjUSZyInJxcyUAEk6z/s1600/Stacks+%25233.jpg" height="105" width="640" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Two stacks of bracketed photos. Coloring the stacks made them stand out for me.</td></tr>
</tbody></table>
<span style="font-size: large;"><b>Camera Shake Correction (Lightroom -> Photoshop -> Lightroom)</b></span><br />
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; text-align: right;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjF6skZ2wNgwo9AplzgFDkTAASUF0a03MVg3HAhXds92_TCgFH-7ztmICwPcFevWpp_l1FIMBV55Wds5tKCbYB7M1hi8ICEGTMHn7udt8V3kGstzUGh8kEUFX2eyUIFSryKQAsNe9ZXT8eY/s1600/Photoshop+for+Camera+Shake+%231.jpg" imageanchor="1" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjF6skZ2wNgwo9AplzgFDkTAASUF0a03MVg3HAhXds92_TCgFH-7ztmICwPcFevWpp_l1FIMBV55Wds5tKCbYB7M1hi8ICEGTMHn7udt8V3kGstzUGh8kEUFX2eyUIFSryKQAsNe9ZXT8eY/s1600/Photoshop+for+Camera+Shake+%231.jpg" height="181" width="200" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Editing in Photoshop from Lightroom.</td></tr>
</tbody></table>
As I noted earlier, some of the photos I took at Vanderbilt Mansion were in low light. Even at high ISO (2000 in one case), I had four photos that were slightly blurry due to camera shake at the slow shutter speed I was using (e.g. 1/10 sec). Essentially, I moved slightly even though I had braced myself against the wall. In general, depending on the amount of shake, the photo could just look like it is in soft focus or be completely unusable. Since all four photos were not too bad (I could have gotten away with doing nothing at all for two of them), I thought I would see if I could correct the shake in Photoshop.<br />
<br />
The process was pretty simple: right click the photo and select "<i>Edit In</i>" and then "<i>Edit in Adobe Photoshop CC 2014</i>." The photo is then exported and brought up in Photoshop for additional editing. I will not go into the details of how I fixed the blur, but I will note that Photoshop has a handy set of tools to select the area of the photo that requires correction and then sampling the photo and progressively sharpening it; it can use its own selected area and/or one (or more) areas of your choosing. Once the edits were complete, I merely saved the photo and it appeared back in Lightroom as a new version of the original already in a stack. Once re-imported, I finished "developing" the photo (exposure, color, etc.).<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjDha-WiB8CbbWF9VhKoeoF7C8ORRUguodh-3qVWN2BGnrR8xUSTx5FGMTcq2Kq_-TQFqBO-mA4HKB9MXseNv63IUiIcV_vUFQ1RKx7GPZVErfYmU6CmjjEeTaq69OOdpvyjax3uSEuc0Ub/s1600/Photoshop+for+Camera+Shake+%25231.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjDha-WiB8CbbWF9VhKoeoF7C8ORRUguodh-3qVWN2BGnrR8xUSTx5FGMTcq2Kq_-TQFqBO-mA4HKB9MXseNv63IUiIcV_vUFQ1RKx7GPZVErfYmU6CmjjEeTaq69OOdpvyjax3uSEuc0Ub/s1600/Photoshop+for+Camera+Shake+%25231.jpg" height="264" width="640" /></a></div>
For this particular photo, knowing the location of the focus point was important. When I took the picture, I had the lens wide open at f/2.8, so the resulting photo had a very shallow depth of field. It was not easy to tell where the natural focus was that had blurred due to camera shake versus naturally blurred areas because of the shallow depth of field used. Interestingly, Photoshop seemed to know where the focus point was because it picked that same area for its initial auto correction. I then selected a couple of manual areas. I am happy with the result even though I did not post this particular picture when I was done—I had another version that did not suffer from camera shake.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<span style="font-size: large;"><b>Conclusion: Still Happy</b></span><br />
I am still happy with the way Lightroom has performed in this trial period. Despite some of the "missing features" I have noted, the most important thing is that I can effectively and efficiently develop my photographs while having enough creative tools to made adjustments I feel are necessary (or just desired). I have twenty days left, so I'll keep shooting.<br />
<br />
My best,<br />
<br />
Jim</div>
Unknownnoreply@blogger.com016 Wildlife Drive, New Milford, CT 06776, USA41.6502923 -73.394741.650245799999993 -73.394779 41.6503388 -73.394621tag:blogger.com,1999:blog-5819248201921656959.post-33727666937590223782014-07-16T12:17:00.001-04:002014-07-16T12:17:19.874-04:00Moving from Apple's Aperture and Adobe's Lightroom (Part 1?)<div dir="ltr" style="text-align: left;" trbidi="on">
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<br />
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em; text-align: right;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgGpZ4iql7K0Nq4kYAoa9mxlkmsV1zOdapBGVfwE3xRddYB9o1BJE0yg1l9HOSkFM8-PEjPFTfsbUqGW5oG7PQM1A2UIATJXRLmNXpls4NePFv2Oxt5iIB66BGBJkNcCkVRChgznBSjIlTO/s1600/Aperture+to+Lightroom.png" imageanchor="1" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgGpZ4iql7K0Nq4kYAoa9mxlkmsV1zOdapBGVfwE3xRddYB9o1BJE0yg1l9HOSkFM8-PEjPFTfsbUqGW5oG7PQM1A2UIATJXRLmNXpls4NePFv2Oxt5iIB66BGBJkNcCkVRChgznBSjIlTO/s1600/Aperture+to+Lightroom.png" height="118" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Is now the time to move to Adobe Lightroom?</td></tr>
</tbody></table>
<b>On June 27, 2014</b>, <a href="http://www.macworld.com/article/2375212/apple-retires-aperture-and-iphoto-to-be-replaced-with-photos-for-os-x.html" target="_blank">MacWorld reported</a> that Apple would be retiring their pro photography software, Aperture, and their consumer photography software, iPhoto, in favor of a new product called <i>Photos</i> that will (supposedly) serve both constituencies. While Aperture development has now stopped with the exception of updates needed to make it compatible with the next OS X release, Photos will not ship until sometime next year (2015). The last minor update to Aperture was last November (2013); the last major release was four years ago (in 2010). Perhaps they stopped working on it a bit sooner than this announcement.<br />
<br />
I have used Aperture since mid-2007 and have been generally happy with it. With its up-and-coming demise, I decided to investigate <a href="http://www.adobe.com/products/photoshop-lightroom.html" target="_blank">Adobe's Photoshop Lightroom</a> and see if it would be able to handle my rather simple workflow as capably as Aperture has for the last seven years (excepting some major bugs over time) and perhaps be the solution for some of that product's little annoyances. If it seems to be able to handle what I can throw at it after a trial period (maybe the next month—heavy photo season for me), I will switch to it as my primary and use Aperture as a backup until I can figure out a way to migrate my libraries without too much pain. One thing I am not too excited about is that Adobe is renting their software by subscription. Nevertheless, if they keep it maintained and the price is not exorbitant (currently $9.99 per month for Lightroom and Photoshop) I will pony up at the end of my trial period.<br />
<br />
As of today, I have been using Lightroom 5.5 for approximately forty-eight hours. I processed three albums of photos and found the tool be quite usable once I got over educating myself on the interface. I did not get a chance yet to see how the <a href="http://www.hdrsoft.com/" target="_blank">Photomatix</a> plug-in works within the tool (no HDR-eligible photos, in my opinion) or the stacking feature for bracketed photos (all three albums had no bracketed photos); bracketing and stacking is an oft-used feature for me. I also did not use some of the more powerful features of the tool; my goal was simple workflow: can it do it or not?<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<br />
<div style="text-align: left;">
<span style="font-size: large;"><span style="color: #0b5394;"><b>Features and "Features"</b></span></span></div>
As with any time I switch main products, my observations are bound by the fact that I know the original product pretty well. In this case, I have been using Aperture for almost seven years. With scant few upgrades in that time, it is safe to say I know my way around the product. Nevertheless, I have tried to keep my mind open and not fault Lightroom (or Aperture, for that matter) when things are just different. Below is my list of "new" and "missing" features in my forty-eight hour comparison. None are showstoppers, but I did have to invent some workarounds in a couple cases.<br />
<br />
<div style="text-align: left;">
<span style="font-size: small;"><span style="color: #0b5394;"><b><i>"New" </i>Features</b></span></span><br />
<span style="font-size: small;"><span style="color: #0b5394;"><span style="color: black;">These are features that either Aperture does not have or if it does it is cumbersome to use.</span><b> </b></span></span></div>
<ul style="text-align: left;">
<li><span style="font-size: small;"><span style="color: #0b5394;"><span style="color: black;"> </span></span></span>A way to easily upload a subset of my photos to Facebook. Aperture does have this feature, but it stinks. It always wanted to upload previews in such low resolution that the pictures were absolutely terrible. Lightroom's Facebook publisher is better, but even better than the built-in one is <a href="http://regex.info/blog/lightroom-goodies/facebook" target="_blank">Jeffrey Friedl's "Export to Facebook" Lightroom Plugin</a>. It allowed me to create albums, set things to private or just visible to friends, and I could enter any metadata I wanted into the caption field. I like my captions to have my file identifier so that I can locate the original if need be. This takes a ton of time off of my workflow because I do not have to export a slightly lower resolution version of my photos, upload them, and then edit the captions after I upload my photos. Of course, if Facebook kept and showed select metadata I would not feel the need to do that. (Note: the photos did not seem to retain their location information, but I was initially using the plug-in with its default settings, which stripped location information).</li>
<li><span style="font-size: small;"><span style="color: #0b5394;"><span style="color: black;">A way to upload my photos to Google+ (via Picasa). Okay, </span></span></span>this is via a third-party plug-in (also by Jeffrey Friedl; see <a href="http://regex.info/blog/lightroom-goodies/picasaweb" target="_blank">Jeffrey Friedl's "Export to Picasa" Lightroom Plugin</a>). While a third-party plug-in does exist for Aperture, like the imbedded Facebook plug-in it wanted to use the preview. I always just exported the pictures as JPEGs and uploaded them to Google+. This saves a very small amount of time in my workflow because I do not have to export my picture subset for Google+ at a slightly lower resolution and then upload, but it is convenient.</li>
<li> Useful plug-ins. Every Aperture plug-in I downloaded (excepting <a href="http://www.hdrsoft.com/" target="_blank">Photomatix</a>, which is awesome for creating HDR composites) never lived up to its hype. Lightroom's plug-ins (particularly the publish plug-ins) are quite robust. Now if someone could just write a decent, simple metadata export plug-in (see "missing features") ...</li>
<li>More brushes. I noticed a graduated filter brush, which greatly helped me adjust a photo where the sky was just a bit too bright and I did not use a polarizing filter or a ND filter over the lens (I had for some others in the batch I tested). I also noticed a few nice presets that allowed me to easily modify a photo to monochrome through an orange filter. (The B&W filter feature also exists in Aperture and is very easy to use, so perhaps I am giving Lightroom a little too much credit here).</li>
<li>A more accurate white balance eyedropper tool. While Lightroom does not seem to have any sort of automatic white balance via algorithm like Aperture does, I found its eyedropper tool to adjust colors a little bit more accurately when the grey area is identified with it (at least in my eye—white balance can be as much about preference and style as accuracy).</li>
<li>Memory doesn't seem to leak as much and the CPU does not go insane after using the tool for a little while. This is not a feature, of course, but it is much appreciated. Aperture has been making me nuts lately and once the "beach ball" begins to appear regularly it is time to exit and re-start the program.</li>
<li>Mobile! Lightroom's mobile app is not perfect, but it is pretty neat to see your pictures synch up and be able to sort, pick, and reject frames. You can also do some light adjustments.</li>
</ul>
<span style="font-size: small;"><span style="color: #0b5394;"><b><i>"Missing</i>" Features</b></span></span><br />
<span style="font-size: small;"><span style="color: #0b5394;"><span style="color: black;">These are features that Aperture clearly has and I could not find in Lightroom. I believe it is possible that third-party plug-ins may be able to resolve some of these or I just do not know where to find them yet, but it is too early to tell.</span><b> </b></span></span><br />
<ul style="text-align: left;">
<li><span style="font-size: small;"><span style="color: #0b5394;"><span style="color: black;">No built-in spell check for captions. This was a relatively recent add for Aperture and was a welcome addition. Sometimes, when I type comments fast I introduce minor type-os that are not easy to see.</span></span></span></li>
<li><span style="font-size: small;"><span style="color: #0b5394;"><span style="color: black;">No facial recognition. I got into the habit of tagging who was in my photos. I realize I can just add a tag in Lightroom, but the fact that Aperture shows all of the faces and could even recognize some of them make this an easy exercise. I haven't figured out what I want to do here yet. There are some workarounds that I found, but I am not happy with them. For now, I'll either manually add the tags or just not bother until I find a better solution.</span></span></span> </li>
<li>No way to easily export metadata. Aperture's metadata export is easy to use and comprehensive: select the photos you want, right click, export metadata. Lightroom does not have this function at all and the third party tools I found didn't just dump the information (and they wanted me to buy the plug-in to boot!). The only reason I need the metadata is sort of stupid: Shutterfly doesn't automatically load comments when you upload. (I know, I know, I should switch services). It adds a lot to my workflow, but it is a lot easier when I can cut and paste them from a spreadsheet. An easy workaround was to just use Phil Harvey's <a href="http://www.sno.phy.queensu.ca/~phil/exiftool/" target="_blank">ExifTool</a> on my exported photos. I seem to be using ExifTool for a lot of things anyway from fixing time shifts to pushing GPS coordinates and elevation into my pictures. I am still surprised there is no built-in metadata export, though.</li>
<li>I always felt that Aperture's map function was sort of clunky. Lightroom's is too. I had hoped it would be better.</li>
<li>A real "auto" function. I pressed "auto" to see what it would do. A lot of times in Aperture, I would start with the auto and tweak from there (particularly white balance - I never liked the default white balance). Lightroom's auto is just okay. It can't set an auto exposure if its life depended on it, though. If you enjoy blown out highlights, then this is the feature for you. </li>
<li>No auto white balance (without the eyedropper). Aperture's auto white balance was hit and miss, but it usually gave me a good place to start when the lighting was not perfect. You just have to sort of wing it in Lightroom. </li>
</ul>
<br />
<span style="font-size: small;"><span style="color: #0b5394;"><b><span style="font-size: large;">Promising Results Thus Far </span></b></span></span><br />
<span style="font-size: small;"><span style="color: #0b5394;"><span style="color: black;">My results thus far are promising and I have probably mentally made the decision to switch unless I find something even better. I do not want to wait until the very end nor do I want to wait for Photos; I'll check that out when it is released. I have been feeling that things have not been advancing in Aperture for some time, so I had already been considering a switch. This is giving me the impetus to do it.</span></span></span><br />
<br />
<span style="font-size: small;"><span style="color: #0b5394;"><span style="color: black;">My Best,</span></span></span><br />
<br />
<span style="font-size: small;"><span style="color: #0b5394;"><span style="color: black;"> Jim </span><br /><b> </b></span></span></div>
Unknownnoreply@blogger.com016 Wildlife Drive, New Milford, CT 06776, USA41.6502923 -73.394741.650245799999993 -73.394779 41.6503388 -73.394621tag:blogger.com,1999:blog-5819248201921656959.post-70716515346958260472012-11-03T17:20:00.003-04:002012-11-03T17:20:50.879-04:00Mobile Platform Wars Redux<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: left; margin-right: 1em; text-align: left;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhiBmqrFGClfkRm1NgxzbtsVicaqm4_Aq2TUXmZIHsEMWHX1o51L0qMn4cI7fQ7GEp8YVRWgcuckmfi4rUV8f_C39dljEm2g11MOb_1a2SeNLm2jG1MtG-EQ7IVFLwGIZRohZQmy2598JF5/s1600/12618566_s.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhiBmqrFGClfkRm1NgxzbtsVicaqm4_Aq2TUXmZIHsEMWHX1o51L0qMn4cI7fQ7GEp8YVRWgcuckmfi4rUV8f_C39dljEm2g11MOb_1a2SeNLm2jG1MtG-EQ7IVFLwGIZRohZQmy2598JF5/s1600/12618566_s.jpg" height="212" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Image credit: <a href="http://www.123rf.com/photo_12618566_andriod-girl-refecting-a-gift.html" target="_blank">gow27 / 123RF Stock Photo</a></td></tr>
</tbody></table>
In <a href="http://swblog.jimkile.com/2012/04/phone-platform-wars-wasting-time-on.html" target="_blank">Phone Platform Wars - Wasting Time on Trivialities</a>, I expressed befuddlement at the unnecessary vitriol that people had been directing at others who do not use the same mobile platform that they do. I have noticed in the past two months that this vitriol has become even more pronounced. In one case, a person that decided to try an iPhone 5 received death threats from her Android-using followers (see <a href="https://plus.google.com/112241639219303464110/posts/92SDQYNx5Rq" target="_blank">Ashley Esqueda's Google+ post</a> from September 11, 2012) despite the fact that she was and is an avid Android user and wanted to try the other platform for a second phone line. In another case just this past week, William Shatner's announcement of new app initially appearing on the iPhone platform got beat up because there was no Android version yet -- only 5% of the comments were about the app itself (called <a href="http://www.shatoetry.com/" target="_blank">Shatoetry</a>); the remainder devolved into Android fans bashing the "i" products from Apple (see <a href="https://plus.google.com/112859244767729828637/posts/Z2VxMZqFjCe" target="_blank">here</a> for an example). While later posts tended to be from his own fan base versus fans of Android, it was jarring to see those comments vilifying a person for not having an application on their preferred platform first <i>and </i>ripping apart the competing platform. Android users do not have a lock on such lunacy, despite the source for my two examples: Apple users can be just as bad.<br />
<br />
A survey by <a href="http://www.businessinsider.com/smartphone-survey-results-2011-4?op=1" target="_blank">Business Insider</a> from April 2011 had an interesting statistic (as of that date, of course): 55.7% of Android users would <u>never</u> buy an iPhone because they "hate Apple," while 23.8% of iPhone users would <u>never</u> switch to another platform. The survey questions did not list Google or any other company as a reason to not switch off the iPhone (iOS) platform and the questions may have caused some bias in the responses. Nevertheless, it is interesting that there are people that would <i>never</i> switch to an opposing platform even if they provided superior functionality and/or services. <br />
<br />
All of this leads me to the following question: What would make someone decide that they would <i>never</i> switch to a competing mobile platform? "Never" is pretty absolute:<br />
<blockquote class="tr_bq">
<a href="http://www.merriam-webster.com/dictionary/never" target="_blank"><span style="font-size: large;"><b>nev·er</b></span></a><br />
<i>adverb </i>\'ne-v<span class="pr">ər\</span><br />
1. not ever : at no time < I <i>never</i> met her><br />
2. not in any degree : not under any condition <<i> never</i> the wiser for his experience > </blockquote>
<blockquote class="tr_bq">
<span style="font-size: x-small;"><b>Source:</b> Merriam-Webster, <span style="font-size: x-small;"><a href="https://www.blogger.com/goog_744523728">http://www.m<span style="font-size: x-small;">e</span>rriam</a><span style="font-size: x-small;"><a href="http://-webster.com/">-webster.com</a>, </span></span>accessed November 3, 2012 </span></blockquote>
What happens if the platform substantially deteriorates, like Blackberry's did? Would they still not switch? What psychological drivers are at work here? Perhaps there is some sort of platform attachment psychosis in play or perhaps some of these individuals were personally burned when using the competing platform. Maybe they are just surer of themselves than I am. As an eight year Blackberry user that switched to an iPhone earlier this year, I can tell you that Apple does not have a lock on my business: if I find something better when my contract is up, that will be the next smartphone for me.<br />
<br />
Another question: For someone that would never switch to a competing platform, why would a subset of these individuals also believe they need to evangelize the platform of their choice? Perhaps this is the more interesting question of the two. I presume the corporations involved with these mobile platforms are not paying these people. Does the relative anonymity and ease of creating comments on any topic somehow circumvent a more moderated response? I have seen this in other settings beyond the Internet and social media (for example, on the phone versus in person), but what drives a person to turn off their self-regulation is still a mystery to me.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-5819248201921656959.post-30666140636675723932012-10-19T21:47:00.000-04:002012-10-19T21:47:01.510-04:00A New Domain for my Blog<div dir="ltr" style="text-align: left;" trbidi="on">
<div style="text-align: left;">
Earlier this evening, I took care of something that I have been wanting to do for quite some time: redirect a sub-domain on my web site to my blog. I do not think there was any specific reason for it except to begin to "unify" some of my content (a lot of which is out of date, I might add). As it turns out, the set-up was relatively straight forward and my blog remained where it has always been (on blogger). There were four rather simple steps I took to get this working:<br />
<br />
<b>1. Create a sub-domain</b><br />
<br />
My first step was to create a sub-domain on my web site that can redirect to my blog on Blogger. Since I was not sure if I would want to add other blogs outside of the software domain in the future, I chose the somewhat cryptic "swblog" as my sub-domain. The URL for my blog, therefore, became <a href="http://swblog.jimkile.com/">http://swblog.jimkile.com</a> instead of <a href="http://jimkile.blogspot.com/">http://jimkile.blogspot.com</a> with that one decision.<br />
<br />
<i><u>Note</u>: A step like this is very much hosting service dependent. My web site is hosted by <a href="http://www.modwest.com/" target="_blank">Modwest</a> (and has been since 2003), so I merely used ssh to access my account and create the appropriate directory.</i><br />
<br />
<b>2. Verify my new sub-domain with Google's <a href="https://www.google.com/webmasters/tools/home?hl=en" target="_blank">Webmaster Tools</a></b><br />
<br />
I confess that I did not do this step in the order in which I have it here, but I found out that it was a necessary step to complete the process. All I had to do was add the new blog URL, place a small HTML file in its root directory, and let the tool validate the address. Not doing this caused an error when I updated the blog address in Blogger, so take my advice and do it first.<br />
<b><br /></b>
<b>3. Forward my sub-domain to Blogger</b><br />
<br />
Once I had my new sub-domain, I had to tell the Internet's domain naming system (DNS) that one part of my web site would be hosted elsewhere (in this case, Blogger). That required me to add two <a href="http://en.wikipedia.org/wiki/CNAME_record" target="_blank">CNAME</a> records to my web sites's DNS settings, but finding out what to add meant I had to start the process on the Blogger side first. I did that by going into the basic settings for my blog and beginning the process of setting the new blog address using the advanced version of that option. I added my new blogger URL <span style="color: #073763;"><b>(A)</b></span> and then selected the settings instructions link <b><span style="color: #073763;">(B)</span></b> so that it would give me the information I would need to create the CNAME records.<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgyo4rE59t7jBDEtUOTh4IH0QriRfOV7jewgBvsDoHSurGIzG5mZCYkSTZePIYJRZqQrH1PdA6RsjcSBq2d83P_byzwPgWHua_f6q-D2G-t27KKcpEITdmKKApheaRIqSBjR_Uxet-LlVjX/s1600/Blogger+Settings.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgyo4rE59t7jBDEtUOTh4IH0QriRfOV7jewgBvsDoHSurGIzG5mZCYkSTZePIYJRZqQrH1PdA6RsjcSBq2d83P_byzwPgWHua_f6q-D2G-t27KKcpEITdmKKApheaRIqSBjR_Uxet-LlVjX/s1600/Blogger+Settings.jpg" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Blogger's Advanced Blog Address Settings</td></tr>
</tbody></table>
<br />
Once I had the CNAME information, I added the two records to my web site's configuration.<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi6WsKyVMimz_4urawF3UhSDcGI0UszMUXXv5_C71_xlJwP8FjYJkkIFeSk2klZFTKDJ6RLcReqx7Rf0eYnL9p5UYvB4Osk3YpJqsiZGCAgzEVnOkonQ6kL5yojQMuz2YpI-PeDhvs3Ain_/s1600/CNAME.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi6WsKyVMimz_4urawF3UhSDcGI0UszMUXXv5_C71_xlJwP8FjYJkkIFeSk2klZFTKDJ6RLcReqx7Rf0eYnL9p5UYvB4Osk3YpJqsiZGCAgzEVnOkonQ6kL5yojQMuz2YpI-PeDhvs3Ain_/s1600/CNAME.jpg" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Modwest's DNS Configuration Settings (Fragment)</td></tr>
</tbody></table>
<br />
<b>3. Save the Blog Address in Blogger</b><br />
<br />
After I made my changes to my DNS settings, I merely saved the Blog Address I had started to get the CNAME information. In theory, that should have been it except for the next step, which was the hardest ...<br />
<br />
<b>4. Wait</b><br />
<br />
I added this step because at first things did not quite work. After about 20 minutes, though, the redirect seemed to be consistently working. In fact, it should take about 24 hours before the name changes propagate throughout the Internet's DNS system, so 20 minutes was pretty good.<br />
<br />
<b><u>Other Changes at the Same Time?</u></b><br />
<br />
Perhaps one thing that I changed that I probably should not have was the layout of my Blog. In retrospect, had I known the results I probably would have left well enough alone for the time being. While the blog is now using one of Google's new "dynamic" templates, the color scheme is currently rather bland. When I had customized the background and colors, I found that they did not appear consistently across browsers and platforms. For example, the background picture I selected was visible in Google's Chrome, but not Safari or Firefox (all of these on Mac OS X). I will have to play with the settings and perhaps send some feedback to Google after some research to find out how to make their new templates play well with all browsers.</div>
</div>
Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-5819248201921656959.post-77903271308504340322012-05-21T12:45:00.001-04:002012-05-21T12:45:16.588-04:00Traveling Can Be Interesting ...While this does not follow my normal thread about software, it is interesting to me on a personal level (and I'll link it to software at the end). Those who know me well know that I have had my share of interesting travel experiences. From delayed flights to subsequent missed connections to natural disasters that have stranded me one place or another, I am never at a loss for a good travel story.<br />
<br />
As I write this, I am experiencing something a little different from the past. As our plane was waiting in line to take off, it was called back to the gate to pick up a passenger whose bag made it on the plane, but they did not. Because of the return trip, they also need to refuel the plane. When the passenger came on board, air marshals accompanied the person.<br />
<br />
We now await at least two things before we can push off from the gate again: first, the refueling needs to be completed (wonder if the late passenger gets to pay for that? Stranger things have happened); second, the person in my row that got up to go to the bathroom about 15-20 minutes ago needs to return. There are probably a couple other things, but those two would seem to be a must.<br />
<br />
It will be interesting to see how long we will be waiting and how late we subsequently arrive at our destination. The flight is a long one already: 13+ hours from Newark, NJ to Beijing.<br />
<br />
Getting back to software: The airline and/or airport knew they were missing someone whose baggage was loaded onto the plane, yet not soon enough prior to departure to do something about it and save a return trip to the gate. Enhancing their capability to detect this type of issue prior to departure could save them some money and possibly protect their on-time rating (not to mention keeping people at ease): a software enhancement worth thinking about.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-5819248201921656959.post-54567789001542497672012-04-04T23:14:00.000-04:002012-04-04T23:14:50.748-04:00Phone Platform Wars - Wasting Time on Trivialities<div dir="ltr" style="text-align: left;" trbidi="on"><br />
I have been reading with amusement as several people I follow and usually respect on G+ are bashing smart phone platforms that they did not choose for themselves. I now have an iPhone, so apparently I have just become (overnight) an elitist snob after eight years of being neither hip nor trendy by using a Blackberry. Some don't like the closed platform of the iPhone. Others think that Android is too buggy. A lot of people think Blackberry must be going out of business (actually, that one could be close to the truth if they don't fix what's wrong with their technology and business model).<br />
<br />
The underlying theme held by each person that commented was that the other platform -- the one <i>they</i> did not choose -- was not good enough or had some so-called critical flaw in it that should dissuade any <i>normal person</i> (read, like them) from even thinking about using it.<br />
<br />
For me, I have used just about every computing platform out there at one point or another. I have never been wedded to a single technology, though I do currently use a Mac and now all of a sudden have an iPhone. Yet, I still use Windows too (2 machines in my house)... and Linux, AIX, VM, zOS, etc. I started with a Commodore 64, CP/M, and DOS. I used VAX/VMS in college and had a Palm m515 that I used for a time near the turn of this century. During the 1990s, I used OS/2 as my PC platform of choice. Each one of these platforms had advantages and disadvantages and, yes, there are some platforms I like working in more than others. But, my preferences are not everyone's preferences.<br />
<br />
What I believe is key is that we have a choice, but can still communicate regardless of the choice we make. This is one of the great things in IT that I have seen happen over my lifetime: disparate computing environments that can communicate with each other pretty effortlessly.<br />
<br />
So, for those that I follow and have fallen into this trap, please step back and think about what you are writing. Are all those Android users you are bashing _really_ cheapskates (as I saw in one separate article)? Are all those iPhone users so completed bought into the Apple hype that they can no longer think for themselves? Have all those Blackberry users really made an inferior decision just to stay with a dying company with out of date technology? You know the answers.<br />
<br />
As I look to conclude, I realize that my title is tinged with irony, given the length of this article. Humph. Perhaps it is that new elitist snob attitude I just picked up ...<br />
</div>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-5819248201921656959.post-31613329565413840192011-07-20T08:42:00.004-04:002011-07-21T15:13:50.644-04:00Photography Software: Missing Features and Frustrations<div dir="ltr" style="text-align: left;" trbidi="on">Photography is one of my long-time hobbies. It started in my youth with a camera given to me by my grandparents—a Vivitar 110 with a built in flash—and continues to this day with my current Canon 7D digital SLR. I am not sure what attracts me to the craft, but I enjoy being able to record events and interpret the things that I see in the world. I purchased my first SLR camera about a year after graduating high school (a Canon T70 35mm). Up until the turn of the century (that's 2000 not 1900) the one thing that most cameras had in common was that they used some form of film.<br />
<br />
<div style="text-align: left;"></div><div style="text-align: left;"></div><table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: left; text-align: left;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhPDFVWHEDJwYAQLh7G5NZnynz0M1zp_uVmkVLCo8-nDOkPQHCR3MdPW4cNOjFdw47-FksCZi3WcIQ-A1i2JugzdCWtYjpSHDREkFnADS3oTrmIzGX1OLaGUjKdZGYppp-z6beAdTrfob6S/s1600/Canon+T70v2.jpg" imageanchor="1" style="clear: left; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhPDFVWHEDJwYAQLh7G5NZnynz0M1zp_uVmkVLCo8-nDOkPQHCR3MdPW4cNOjFdw47-FksCZi3WcIQ-A1i2JugzdCWtYjpSHDREkFnADS3oTrmIzGX1OLaGUjKdZGYppp-z6beAdTrfob6S/s1600/Canon+T70v2.jpg" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Canon T70 35mm Camera</td></tr>
</tbody></table>Since switching to digital photography in 2003, I have come to realize that film and limited online capability did have at least one advantage: you did not have to deal with image processing and upload software on a regular basis. Instead, you dropped your film off at (or mailed it to) a lab where it was processed on your behalf. As the web became more popular, you even had the option of receiving a digital version of your pictures on 3.5" disks or, later, CD/DVD for an additional fee.<br />
<br />
Working with image processing and upload software can be a frustrating endeavor despite the greater creative control it gives you over your photographs. I think the way I work makes it even more difficult (perhaps I am the problem here). Nevertheless, I use Apple's <a href="http://www.apple.com/aperture/">Aperture</a> for processing and organizing my photos. Once processed, I like to upload my master set (photos that I have not rejected, but are not only the best of the best) to <a href="http://www.kodakgallery.com/">Kodak Gallery</a> and make any prints from there if I need something that looks professional or if I just want to create a book of the year's photos. I also tend to share a sub-set of those photos on <a href="https://www.facebook.com/jim.kile">Facebook</a> and, more recently, <a href="https://plus.google.com/108657706328131954149/posts">Google+</a> so that my friends and family are easily able to see the best of a photo shoot from the comfort of social networking account.<br />
<br />
<div style="text-align: right;"></div><table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em; text-align: right;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjLq3-ukqKEBDyKn6wAfUaa9v5cEAZHnngmbK0Xw6xZi7GKeS4sJxSp3AnZs6pVOV0sYNpOL3Jj18fBphgXiEhjOTTrn_UDArSGOyAUjv7eD_jcplTaKU71C6gGL_RHFLwc29WUO6Gw2LKB/s1600/Canon+7D.jpg" imageanchor="1" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjLq3-ukqKEBDyKn6wAfUaa9v5cEAZHnngmbK0Xw6xZi7GKeS4sJxSp3AnZs6pVOV0sYNpOL3Jj18fBphgXiEhjOTTrn_UDArSGOyAUjv7eD_jcplTaKU71C6gGL_RHFLwc29WUO6Gw2LKB/s1600/Canon+7D.jpg" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Canon 7D Digital SLR Camera</td></tr>
</tbody></table>My current frustration is with exports and uploads for photo sharing. The key phrase here is "lack of integration and features." While I find Aperture to be generally easy to use and powerful with excellent general photo export features built into it, its integration with photo software sites leaves much to be desired. Sadly, this seems to be the case with Adobe's Lightroom (a.k.a. "the competition") as well. Both allow plug-ins, but none that I have tried do exactly what I would like them to do—some do things that do not seem to make any sense to a rational human being. For example, Facebook integration within Aperture happily uses the version name of the photo as the caption (instead of the caption). That means if you want to have a real caption you have to change it in Facebook itself. If you do change it, though, <i>it changes all of your version names to the new caption within Aperture</i>. Yes, you read that right and Apple has yet to address it. In addition, none of the plug-ins I have tried seem to allow you to "build" your caption from metadata or file information (e.g. Caption + Version + date taken, etc.) and most of these services' upload software seems to have the same limitation. Even third parties don't quite do the job. Incidentally, one plug-in that that comes close for Google's Picasa is Übermind's <a href="http://www.apple.com/downloads/macosx/aperture/aperturetopicasawebalbums.html?cmp">Aperture to Picasa Web Albums</a>: it is fast, uses Aperture's export settings, but it does not allow a custom built caption, which is a shame.<br />
<br />
What makes all of this worse is that the various photo sites also do not integrate well with the social networking sites. For example, while I could share my photos to Facebook from Kodak Gallery, people would be redirected to the Kodak Gallery. The result is that I cannot tag people and it becomes difficult to keep track of what I actually shared (e.g. my 'best of' versus the entire album). While there are several plug-ins for the Chrome and Firefox browsers (like <a href="https://chrome.google.com/webstore/detail/idiebfmmkhaffedkhjhapmagabcadjhc">Move Your Photos</a> for Chrome) that attempt to help, I found the ones that I tried to be feature poor and inconsistent with respect to maintaining captions, EXIF information, resolution, etc.<br />
<br />
Unfortunately, I have wound up with a cobbled together and complex photo sharing workflow once I have made my adjustments and added metadata:<br />
<ul><li>I export all of my adjusted photos as JPG files. (I would do this anyway so I have the final version of the photo stored after adjustments).</li>
<li>I use Kodak Gallery's upload software to move my photos into Kodak Gallery. It does not pull captions from the exported JPG files, so I have the pleasure of copying and pasting them. To make my life easier, I export the metadata from Aperture and load it into Excel where I can manipulate the caption to also include the photo's version name. I tried to use the automator, but let's just say that solution was less than successful. (Note: I used to use <a href="http://picturesync.net/">PictureSync</a>, but that seems to have died forever now. That was a nice program because it pulled in the captions and allowed me to append additional information like the version name. I still weep its demise). <b>UPDATE: It looks like there was an update to PictureSync that allows it to work with Kodak Gallery again. </b></li>
<li>I have been using <a href="http://antaki.ca/bloom/">Bloom</a> to upload photos to Facebook. It allows tagging from the software and you can create/manipulate albums before uploading. Bloom also allows you to pull in EXIF data as part of the caption. Unfortunately, it also puts the EXIF tag before it (e.g. "Caption/Abstract" and then the caption) and it does not allow for additional information outside of the EXIF like the file name. I wind up deleting the tag information and adding the version name to the caption manually.</li>
<li>I just started using Übermind's <a href="http://www.apple.com/downloads/macosx/aperture/aperturetopicasawebalbums.html?cmp">Aperture to Picasa Web Albums</a>. This is a plug-in. It is smart enough to pull the caption from the photo, but it does not allow for caption manipulation. One nice thing is that you can use a custom export that does not interfere with my normal exports. Nevertheless, I have to edit all of the captions once it is uploaded to Picasa before sharing with Google+.</li>
</ul>I could solve some manual manipulation by just putting the version name in with the caption, but that just doesn't seem like the right way to go: it would just confuse things and cause me to type the version names into the caption instead of a sub-set into the upload software.<br />
<br />
So, what do I want? Perhaps the impossible, but here it is:<br />
<ul><li>A plug-in or set of plug-ins in Aperture (or Lightroom) that allow me to select the photos I want to upload, export them at the selected resolution, create or update a photo site or social network album with the requisite fields that the social network supports (e.g. location, date, album description, etc.), include EXIF information in the upload, allow me to customize the caption with metadata and file information, and set permissions/shares.</li>
</ul>AND/OR<br />
<ul><li>An application that does the same after I have exported the data.</li>
</ul>AND/OR<br />
<ul><li>A way to do the upload to one sharing site and have the sharing features copy the photos into the others in tact (that is, with captions, EXIF, etc.). I would be happy to do the tagging separately.</li>
</ul><br />
In the end, I think my desires may not be achievable for some time. Who knows, maybe I'll write a plug-in or set of plug-ins myself that does this someday. For now, though, I'll keep looking for new applications and products and hope that one (or more) will eventually fit my needs.<br />
<div class="separator" style="clear: both; text-align: center;"></div></div>Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-5819248201921656959.post-19539469708423320742010-10-22T09:05:00.000-04:002010-10-22T09:05:58.156-04:00Understanding What We've LearnedIn my last blog entry, I wrote about an agile review that I was preparing to conduct with one of my teams. This team began using the agile software development methodology in earnest in late July after receiving training. At that time, several experienced agile scrum masters and independent coaches were inserted to help guide the transition. I noted specifically that the team has some characteristics that make an agile implementation challenging and success uncertain: the team's overall size is greater than 80 individuals and growing; there are inter-organizational and leadership dynamics in play that could derail the implementation; and the technical environment (SAP), with its functional orientation, poses a unique technical challenge. <br />
<br />
The data-gathering portion of the review ended on October 8. As hoped, the number and variety of input sources and forums for leaders, coaches, mentors, practitioners, and customers proved to be quite robust. Indeed, this review approach yielded more data than one could hope to analyze in a short period of time—particularly when other responsibilities begin to intrude. Despite my initial worries, gathering input is the easier part of the review. What remains is much more difficult: fully understanding the data that was gathered, deriving major themes, identifying recommendations, and implementing those recommendations, as appropriate.<br />
<br />
<b>Emerging Themes</b><br />
<br />
While the review is still incomplete, some themes have begun to emerge that suggest the characteristics of this team's working and technical environment are not driving a significant number of unique challenges and problems. That is, many of the concerns raised by the team and their leadership are reminiscent of earlier agile implementation experiences: difficulty breaking down epic user stores, an initial inability to size in story points, general role confusion, problematic team communications, and getting good quality user stories and acceptance criteria. Nonetheless, there are some themes that do appear to be unique or, perhaps, this team has a different spin on an otherwise generic theme. <br />
<br />
<u>Iteration planning</u> is of particular concern in part due to the functional orientation of the team and the underlying product. The functional orientation of the product makes planning an iteration challenging in that the stories selected need to match the team's composition or the work contour will be uneven. This implies that a potentially higher priority story might have to take a back seat to a slightly lower one because resources may not be available to complete it during the iteration. This is not wholly unique—other agile teams also run out of resources—but it is more acute because the functional breakdown of the team is so granular. To smooth out the work contour means you need to know more than just the team's velocity. As one colleague aptly put it: you need to identify and understand the micro-velocity by functional orientation to be successful. In addition, the team does not have a rigorous planning background to fall back on: they are learning it as they learn agile. <br />
<br />
The <u>technical infrastructure</u> surrounding the application and the <u>functional orientation</u> of the product presents unique challenges. The inter-dependencies between modules (which also effect planning) are somewhat mind-boggling. Too, the ability to keep various environments synchronized has become an issue, though not one due to the implementation of agile. Regardless of the source, it is clear these items will need to be addressed as they are a systemic source for blockers during and after an iteration.<br />
<br />
<u>Meeting overload</u>. One of the things that came through loud and clear was that practitioners and leaders felt that they were attending too many meetings. The team itself is distributed, so some "meeting creep" is expected, since in-person communications are not always possible. But, the prevalence of the sentiment shows that it is a larger issue than just adding a 15-minute scrum and another 15-minute scrum-of-scrums call during the day. While there are instances of people who do not need to attend certain meetings being expected to attend—much of which has already been rectified—we failed to consider the impact of these additional meetings on an apparently already busy meeting schedule. In fact, existing meetings have grown to encompass much of the same material covered in the scrum of scrums meaning we now have some redundancy. <br />
<br />
<br />
<b>More to Come</b><br />
<br />
Preliminary insights are just that: preliminary. They only give a hint of the direction you may eventually need to follow. Assuming I can wade through all the data with my review team in a timely manner I am sure we can figure this out. I am also sure we will find a lot more.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-5819248201921656959.post-2565607891053856802010-09-19T22:25:00.000-04:002010-09-19T22:25:14.629-04:00Reviewing an Agile ImplementationIn a couple of weeks, I am going to be performing a formal review of our progress implementing agile software development practices for one of our sub-teams. While agile is a deeply ingrained methodology for most of our team, this one area has some unique characteristics that make adoption both interesting and challenging. Indeed, the team's size (greater than 80 individuals and growing), the inter-organizational and leadership dynamics in play, and the technical environment (SAP) mean that success is not assured. Nevertheless, there does not appear to be anything in this environment that would rule out the implementation of some form of agile software development. While all environments are not created equal, higher productivity, higher quality, and increased developer and customer satisfaction have accrued from past implementations. <br />
<br />
<b>Selecting What to Review and How to Review It</b><br />
<br />
Preparing for a review of this magnitude can be stressful. Each decision made in preparation has the potential to expose useful information and provide a deeper understanding of the team and the environment in which they are now working. Unfortunately, those same decisions may inadvertently suppress useful information, resulting in a faulty analysis that generates incorrect conclusions and follow-on actions. A deep understanding is necessary to determine what is truly working well and what is just not working at all—it has ramifications on what happens next.<br />
<br />
<u>Multifaceted Approach</u>. Gathering the correct information is essential for any successful review. Since information can be lurking in unexpected places, the best approach would seem to be a multifaceted one. That is, using several different techniques may be the best way to reduce the possibility of missing something important. To best understand what the team is experiencing on a daily basis, staying away from using the review period to question people about performance metrics would also seem prudent. Those types of questions tend to make people uncomfortable and, more importantly, a team that has just begun using agile is not going to fully understand what those metrics mean or how they are influenced. Instead, all of the review techniques selected thus far are intended to pull meaning from each of the interpersonal interactions. They are also intended to help the team better understand their own performance and allow them to think through what <i>they</i> might need to do to make this successful: a tall order.<br />
<br />
<u>The Mini Retrospective</u>. Those familiar with agile have most likely heard of the project retrospective. Nevertheless, most have never actually participated in one—at least not along the lines proposed by Norm Kerth [1]. A full-blown review is time consuming, but rewarding. On the other hand, this review is not about a single successful or troubled project (not yet, anyway). Instead, its focus is on gathering enough information about the new methodology surrounding many the projects in this area and to understand where things are going well or poorly. Variations of two exercises that Kerth proposes are well suited to enable the type of breakthrough thinking that will allow the team to explore what they are experiencing: the "develop a time line" exercise [1 pp. 121-126] and the "emotions seismograph" exercise [1 pp. 127-130]. For good or ill, this part of the review is being called a "mini retrospective." While the name may be a bit generous, the goal of deeply understanding what the team is experiencing is the same. Because only a couple of hours are allocated for each scrum team, there there will need to be some work done by the team prior to the discussion so that the entire time is not spent creating the time line. <br />
<br />
<u>Talk to the Individuals</u>. You can learn a lot from a conversation if you ask open-ended questions and listen carefully. When your attention is on more than a person's words you become aware of their underlying mood, energy level, and attitude. You can also develop a better understanding of the person you are listening to. This is called <i>Global Listening</i>—it is sometimes also referred to as level three listening. It seems reasonable to conclude that the ability to listen will determine whether these sessions are ultimately successful. (As an aside, I learned about the three types of listening from a class I took earlier this year. I found a pretty good summary of the three levels themselves, if you are interested <a href="http://careersintheory.wordpress.com/2009/09/08/three-levels-of-listening/">[2]</a>).<br />
<br />
<u>Getting the Team Together</u>. As important as individual conversations with selected team members are, it is just as important to schedule time with the various sub-teams within the wider team to gain insight into the entire group—insight that might not otherwise appear in a one-on-one setting. This group has a complex matrix management structure. That means that there are several different types of groups from which to gather information: the scrums themselves, the management team, the functional leadership team, and the business team, to name a few. These types of gatherings are often called <i>round tables</i> after the table used by King Arthur and his knights: such a table does not inherently grant precedence to any one person. That description seems appropriate for this part of the team review. By maintaining equanimity, individuals are given a forum and the freedom to discuss collective matters of importance about the team, the methodology, or any other pertinent topic. <br />
<br />
<u>Let the Leader Present <i>Their</i> Findings</u>. It always seems best to have the people leading a team take responsibility and ownership for conveying the major themes discussed during the early part of the review with their local management team. This may be somewhat counter-intuitive, but the theory is that by having the team's leader present the findings that they and their team worked so hard to identify will help ensure that the information is complete and accurate. This has the added benefit of giving them visibility to their local management team and giving an overall insight into their dedication and competence.<br />
<br />
<b>Concluding Thoughts </b><br />
<br />
The aforementioned techniques are intended to cover an array of individual and group meetings during the review. Missing is how we intend to conduct an analysis of the information gathered and how conclusions will be drawn. While these rather important topics remain partially open as of this writing, one thing seems clear: a tentative summary of findings should be available to the team quickly -- before the on-site review period concludes. This will give the review team additional feedback and serve as a further assurance that something important was not missed.<br />
<br />
In a few weeks, I will know whether any of this was effective. Either way, I am sure I will learn something.<b> </b><br />
<br />
<b>References</b><br />
<br />
[1] N. L. Kerth, Project Retrospectives: A Handbook for Team Reviews. New York: Dorset House Publishing, 2001.<br />
<br />
[2] S. Smith, “The Three Levels of Listening”, <a href="http://careersintheory.wordpress.com/2009/09/08/three-levels-of-listening/">http://careersintheory.wordpress.com/2009/09/08/three-levels-of-listening/</a>, 2009, Accessed September 19, 2010.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-5819248201921656959.post-61722012340113347882010-08-21T10:44:00.011-04:002010-08-21T11:24:06.619-04:00The Decline of Creativity?Last month, I read an article in Newsweek that put into words a fear I have been having about creativity in America. The article, "The Creativity Crisis" by Po Bronson and Ashely Merryman [2], appeared in the July 19, 2010 issue of Newsweek and can still be found <a href="http://www.newsweek.com/2010/07/10/the-creativity-crisis.html">online</a>.<br />
<br />
<u>A little background</u>: The article refers to scores on a creativity test originally developed by Ellis Paul Torrance in the late 1950s and formalized in 1966 as the <a href="http://en.wikipedia.org/wiki/Ellis_Paul_Torrance">Torrance Tests of Creative Thinking</a> [1]. The test is similar to an intelligence test in that a psychologist administers it and it requires the performance of discrete tasks over a fixed duration. Instead of deriving an Intelligence Quotient (IQ), it derives a Creativity Quotient (CQ). The article briefly explains the difference between the two tests noting that while the IQ test is subject to the <a href="http://www.indiana.edu/%7Eintell/flynneffect.shtml">Flynn effect</a> [3]—"each generation, scores go up about ten points," which requires the test to be re-normalized periodically to maintain an average score of 100—while the CQ test, apparently, is not. The implication is that scores on an IQ test may be inflated between re-normalizations. It is unclear to me whether CQ tests can suffer from a similar phenomenon and whether any comparison to past results is truly valid: the article assumes they are. Nevertheless, up until 1990, CQ scores were steadily rising. Since 1990, they have been consistently falling with the decrease in younger children between kindergarten and sixth grade being regarded as the most significant.<br />
<br />
While it is unclear whether the premise of the problem presented within the article is completely factual—popular magazines tend to skew information to their audience, do not provide peer reviewed references, and are not themselves peer reviewed—I believe the issue itself is real. The vast information we now have available to us via the Internet and the latest trend toward social networking and online communities would seem to be positive development. Indeed, the recession-induced workplace of 2010 with its "always on, always available" philosophy would also seem to be a boon to businesses, albeit somewhat temporary. The negative, in my opinion, is that these advancements in information availability, trends toward hyper-connectivity, and workplace expectations are systematically eliminating the time available to assimilate and process information: to allow people to think through what they have seen and learned and come up with new ways of solving problems or doing things better.<br />
<br />
The need for assimilation time does not mean I think that we should never have deadlines or that we should not attempt to complete our various projects (personal or professional) in a timely manner. Indeed, I have found that in some cases these pressures can help me find new ways of doing things (out of necessity). Yet, these solutions are often not of the same quality as when I have a chance to think them through. While they tend to get the job done in the short-term they may be one-time solutions that cannot be easily repeated or transformed into longer-term success. For me, those ideas that have lasted are those that I had the time to think through, try with some willing participants, and modify upon some reflection and with the input of those same participants. The process is not linear and certainly not easily scheduled against an arbitrary time line. I suspect this is also true of others.<br />
<br />
Unfortunately, time is often seen as something that needs to be consumed efficiently and completely. Thinking about new things or reflecting on your experiences does not give the appearance of being productive—at least in the short-term. Nevertheless, I believe this is an essential part of living a full and complete life and is an integral part of determining whether a business ultimately survives or withers away. Most disturbing to me is that I have also come to believe that this is equally applicable to a country that depends on its innovation and creativity.<br />
<br />
We ignore creativity and its potential decline at our own peril. As the cartoonist Walt Kelly wrote in 1952 and later modified and attributed to his Pogo Possum character for the first Earth Day in 1971: "We have met the enemy and he is us."<br />
<br />
What will we do to ensure we keep our creative and innovative edge? Our future depends on how we answer this question.<br />
<br />
<b>References / Links</b><br />
<br />
[1] "Ellis Paul Torrance", <a href="http://en.wikipedia.org/wiki/Ellis_Paul_Torrance">http://en.wikipedia.org/wiki/Ellis_Paul_Torrance</a>, Accessed August 21, 2010. <br />
<br />
[2] P. Bronson and A. Merryman, “The Creativity Crisis”, Newsweek, vol. CLVI, no. 4, pp. 44-50, July 10, 2010, <a href="http://www.newsweek.com/2010/07/10/the-creativity-crisis.html">http://www.newsweek.com/2010/07/10/the-creativity-crisis.html</a>.<br />
<br />
[3] C. Graham and J. Plucker, “The Flynn Effect”, <a href="http://www.indiana.edu/%7Eintell/flynneffect.shtml">http://www.indiana.edu/~intell/flynneffect.shtml</a>, 2001, Accessed August 21, 2010.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-5819248201921656959.post-39539647094989739502009-11-14T06:24:00.015-05:002009-11-14T08:07:11.744-05:00Combatting Irrational Behavior and your Fear of Correcting it<span style="font-style: italic;"></span>There are times that we all have to work with other people or organizations —sometimes our own—that seem (to us, anyway) to be irrational. Merriam-Webster defines <a href="http://www.merriam-webster.com/dictionary/irrational">irrational</a> as follows:<br /><blockquote><em class="sn"></em><em class="su">(1)</em> <strong>:</strong> not endowed with reason or understanding <em class="su">(2)</em> <strong>:</strong> lacking usual or normal mental clarity or coherence <strong>b</strong> <strong>:</strong> not governed by or according to reason. [1]<br /></blockquote>As always, a real world example is probably in order—the one that prompted me to write this will do nicely.<br /><br />Yesterday, I was contacted by someone who was looking for help. Specifically, they were looking to see if I could help them get a product group to focus on an issue they were having with one of their applications. This issue was happening on two client machines and it was causing them to not be able to complete some testing. The problem had surfaced a few weeks ago and I even recall this same individual mentioning it. At the time, I asked for more details and assigned one of my experienced managers to help, but never got any response. Now, the situation was critical in their mind: if it wasn't resolved, it would go into some nasty sort of escalation that would end in a flurry of accusatory emails deriding our poor support (even though my organization is being asked to help and do not have responsibility for their project—you have to love corporations).<br /><br />My first thought was that maybe I should get them to answer my original questions. Now that it was critical, I got my answers. The answers were interesting, though, because they indicated that they had found a solution to their problem on the product's web site. They were even kind enough to provide me with a link. Essentially, these two clients had a corrupt install of the base software upon which their application was running. The solution offered? Re-install the software.<br /><br />Apparently, this re-installation had worked in every other case where they had encountered the same problem. So, what about these two clients? Did they follow this procedure and are they still having a problem? I was getting myself ready to do battle with the product group on their behalf. Alas, you can probably guess the response: No, they did not follow the procedure. These two individuals did not want to take the time to re-install the software.<br /><br />As I sat dumbfounded looking at the email on my screen, I realized something profound: this type of behavior had to have been encouraged by someone or some cultural factor within that team. Why wouldn't anyone who came across this problem just tell them to re-install the software and move on? The only thing I could come up with is that they were afraid to tell them to do so. (Fortunately, I did not have the same fear and I was pretty blunt: follow the advice of the product's web site and reinstall the software. If you still have a problem, then I will find someone that can help.)<br /><br /><span style="font-style: italic;">Fear</span>. <span style="font-style: italic;">Being afraid</span>. They are powerful emotions even within the confines of a corporate culture. While I have seen the emotion used as a motivator, it is rare and necessarily short lived. More commonly, it seems that this type of fear prevents people from acting as they should while it obscures real and simple solutions to problems.<br /><br />I am sure most of us (including me) are victim to this type of thinking from time-to-time. While hierarchy and customer relationships can make it hard to have the courage to tell someone that they are not acting in the best interest of themselves or the company, it is something we ignore at our own peril. The cost of irrational behavior in the case I described is not calculable yet. Nevertheless, the costs are real.<br /><br />How much will you let irrational behavior cost you?<br /><br /><span style="font-weight: bold;">References</span><br /><br />[1] "irrational." <u>Merriam-Webster Online Dictionary</u>. 2009. Merriam-Webster Online. 14 November 2009 <<a href="http://www.merriam-webster.com/dictionary/irrational">http://www.merriam-webster.com/dictionary/irrational</a>>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-5819248201921656959.post-66901013876978467002008-10-07T08:25:00.015-04:002008-11-08T02:04:49.394-05:00Experience and Enthusiasm - Making Younger Teams WorkWhen (and how) does a new, inexperienced team become that trustworthy stalwart that you can depend upon to get the job done—competently and efficiently? The question is a difficult one to answer. In large part, it seems to depend on the complexity of what they are doing; the personalities of the team members; the length of time the team is together; and the <span style="font-style: italic;">culture</span> that the team develops as a whole.<br /><br />Many of us have been witness to teams that come together quickly, do their job, and disband. Those teams are not the norm, though. Usually, a brand new team needs some time to acclimate to its environment and its individual members. This acclimation time can be lengthened when the members of a new team are distant from each other, the team itself is distant from its leadership structure, or the team has a high number of inexperienced members.<br /><br />To explore this a little further, it seems necessary to define what a team is in this context before discussing the three areas that can impact its acclimation.<br /><br /><span style="font-weight: bold;">What is a Team?</span><br /><br />Perhaps the best definition of what a team is comes from Katzenbach and Smith:<br /><blockquote style="font-style: italic; color: rgb(102, 0, 0);">"A team is a small number of people with complementary skills who are committed to a common purpose, performance goals, and approach for which they hold themselves mutually accountable [1]." </blockquote>Two parts of this definition lend themselves to further interpretation. First is their use of the term <span style="font-style: italic;">small</span>. While the five other aspects of the definition are "absolute necessities," the addition of the word small is of a more pragmatic value: large numbers of people have difficulty cooperating and working as a single unit and tend to organize themselves into smaller sub-teams. The second part of the definition is not specifically stated, but is implied: team members must be able to easily communicate. Note that the definition does not specifically state that the team must sit together to be effective.<br /><span style="font-weight: bold;"></span><br /><span style="font-weight: bold;font-size:130%;" >Distributed Teams</span><br /><br />Distributed, or highly distributed, teams have several unique issues that tend to impact their ability to acclimate quickly. These include: temporal latency, unexposed (hidden) messages, noise, and difficulty establishing trust. There are others (like national and corporate culture) that will not be discussed in this short blog. A short description of how these impact a team's ability to acclimate to their environment follows:<br /><br /><ul><li><span style="font-weight: bold;">Temporal Latency</span>. When individuals are not collocated, communication delays are inevitable. Distance can even <span style="font-style: italic;">encourage</span><span style="font-style: italic;"> additional</span>. While the amount of time and energy it takes to transfer ideas from one individual to another increases, the quality of the communication simultaneously tends to suffer.<br /><br /></li><li><span style="font-weight: bold;">Unexposed (hidden) Messages</span>. Certain communications between individuals would benefit the entire team. Collocated teams more easily disseminate these types of communications due to their physical proximity. For example, if the individuals having a discussion do not realize that the information they are discussing would benefit the entire team, others in the room can bring its significance to their attention. In general, it is difficult to expose surreptitious communications between individuals because the individuals themselves must recognize its importance and expose it. The correction for this is usually communication formality (e.g. documentation), which is the least effective format.<br /><br /></li><li><span style="font-weight: bold;">Noise</span>. Any interruptive influence that can lead to communications misunderstandings or delay is called <span style="font-style: italic;">noise</span>. This can happen in any team environment, but is particularly problematic for distributed teams because of the number of channels a message must pass through and the inherent delay in time between when a message is sent and when it is received.<br /><br /></li><li><span style="font-weight: bold;">Establishing Trust</span>. Lack of trust and cooperation can be fatal to a team. For distributed teams, trust is easy to establish, but is more difficult to maintain over time unless there is continuous interaction. Research suggests that any physical distance can affect the amount of trust and cooperation <span style="font-style: italic;">even if the distance is simulated and regardless of the magnitude</span>.</li></ul>The above items impact the team's ability to form and, in the context of this blog, their ability to cohesively work towards the goals that Katzenbach and Smith so eloquently spoke of in their definition of a team.<br /><span style="color: rgb(0, 0, 102);"><span style="color: rgb(0, 0, 0);"><span style="font-weight: bold;"><br /></span></span></span><span style="font-weight: bold;font-size:130%;" >Distant Leadership Structures</span><br /><br />Perhaps one of the greatest impacts to a team's cohesiveness and their ability to acclimate to their environment is the proximity of their leadership and the structure overall. While the latter is important to all teams, the former is of particular interest in this context, as it seems to have more of an impact when the team is in its forming stage. Additionally, leadership within a team can take many forms: The formal structure surrounding the team is only one such form. Indeed, it is this informal leadership that seems to increase their capability over time.<br /><br />Nevertheless, creating a team that begins with a formal leadership structure that is distant from the remainder of the team tends to impede their ability to acclimate to their social environment, in my opinion. It seems unwise to do this. I have seen teams overcome this, but it takes a lot of dedication and work to make it so.<br /><br /><span style="font-weight: bold;font-size:130%;" >Ratio of Inexperienced Team Members</span><br /><br />Having a high ratio of inexperienced team members can to be a double-edged sword: While it can foster a learning environment and be the source of much enthusiasm, it can also generate a lowest common denominator productivity sink that can run a project into the ground—particularly if there are only one or two experienced members and the team is rather large. I have never found a percentage that is perfect, but I think a good rule of thumb is to use 80-20 where possible: 80% of the team should be experienced in some way and in varying degrees while 20% of the team may be inexperienced. Nevertheless, as with most things related to team theory, success is highly dependent upon the individuals on the team. No one would be happy with highly experienced low performers, for example.<br /><br /><span style="font-weight: bold;"><span style="font-size:130%;">Conclusions</span><span style="font-weight: bold;"><br /></span></span><br />The ability for a team to become cohesive and trusted to "get the job done" relies on multiple factors. These include the size of the team (and whether it can be effectively sub-divided, if necessary); the physical and temporal distance between team members; the physical and temporal distance between tem the team and its leadership; and the ratio of inexperienced to experienced members. While each of these factors affect the team's performance, the final determinant is the amount of time invested in making them a high performance unit. Unfortunately, these additional factors make the amount of time necessary variable.<br /><span style="font-weight: bold;"><span style="font-weight: bold;"><br />References<br /></span></span><ol><li>J. R. Katzenbach and D. K. Smith, The Wisdom of Teams: Creating the High Performance Organization, 1993.</li></ol>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-5819248201921656959.post-13159583575444015152008-09-28T03:16:00.006-04:002008-09-28T04:19:13.522-04:00Parsing Trouble in a Sub-projectLarge, complex projects tend to compartmentalize key functionality into coordinated sub-projects. This allows an organization to divide a complex endeavor into more manageable pieces. These pieces are usually run semi-independently and require coordination between sub-project leaders (or project managers) and at a higher level. The level of interdependency between coordinated sub-projects can be loose or tight. This functional coupling of sub-projects can (and frequently does) change as the project's time line progresses.<br /><br />One of the difficulties that a coordinated sub-project structure introduces is that it stymies the end-to-end leadership team's ability to comprehend and assimilate a sub-project's overall integration with other sub-projects, their on-time/on-budget status, and the soundness of their overall approach. Indeed, it is possible for one or many of these sub-projects to become independently troubled while others may be running smoothly. Unfortunately, these troubled sub-projects can be difficult to anticipate, as information and status is distributed and can remain hidden from those that need it. In addition, those troubled sub-projects will eventually impact the rest of the project when they miss critical inter-dependencies, if they are not addressed.<br /><br />A large, complex project that I am currently working on fits into the above scenario. Three of its sub-projects in various states of "trouble." To be sure, each has different causes and each needs different corrective actions. I have been concentrating some of my time on one of these sub-projects, as it is the one that will have the most impact (today) on whether the overall program is a success. The other two sub-projects will eventually be just as critical, but this one is the most important one to fix at this time, so it grabbed my attention first. This particular problem took me back to Bangalore, India for further investigation — my fourth trip this year.<br /><br />As I began to investigate what might be pushing this particular sub-project into a troubled state, I found that they paralleled many of my findings for other troubled projects. I hesitate to describe all of the details, as I do not wish to offend anyone who may by chance read this, but I have written about some of these root causes in the past: Team leadership, project management, and team cohesiveness. This sub-project also uses an unorthodox approach to reaching their ultimate goal that has a high probability of failure (not that unorthodox approaches are necessarily bad, but in this case it probably is).<br /><br />To correct such a problem requires a parsing of the trouble areas to ensure that they are each addressed. The difficulty is that each time you address one area you tend to find others that also need attention. Gathering information from existing project artifacts can be helpful to identify the overall context of the problem, but it is more important (to me, anyway) to talk with various members of the team from its top leadership right down to its so-called "worker-bees." Since I was already going to India anyway, I took the opportunity to talk with some of the team members while there. As one might expect, I found some of the things that were "fuzzy" when I discussed them with the leadership team were more clear when discussed with the team itself. It should be noted that it is not that the sub-project's leadership intentionally hid the information, but because it was a strategy they were following for what may have initially been very good reasons, they did not think to highlight it as a a serious issue — one of the team's leadership did reference this problem as one of the areas that should be addressed, but it was not clear to me how much impact this was having until I talked with the team. (Note to self: Dig harder when someone makes a vague reference like that).<br /><br />Ultimately, the ability to move this or any other sub-project out of troubled status will rest on how well we understand the problems they are facing and make the right decisions to correct those problems.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-5819248201921656959.post-46979998139276454762008-08-15T13:36:00.003-04:002008-08-15T13:54:14.977-04:00Using Theoretical Proofs to "prove" Program CorrectnesssI read an article the other day called "<a href="http://cordis.europa.eu/ictresults/index.cfm/section/news/tpl/article/BrowsingType/Features/ID/89864">Goodbye to Faulty Software</a>." The article had one of those catchy titles that I saw while I was catching up on <a href="http://technews.acm.org/archives.cfm?fo=2008-07-jul/jul-18-2008.html">ACM Technews</a>. The title itself intrigued me because faults in software (or, defects) are something that I tend to deal with on a regular basis. The author(s) of the article talk about writing a proof using the language of logic that will ensure that software does what it is supposed to do.<br /><br />I began to dig into the content that the article referred to and found a bunch of open source tools that help you specify a logical proof that can then be generated into a program. I would be telling falsehoods if I even insinuated that I understand both the theoretical foundation or the contents of the tool documentation at this point, as I have only begun to look it over, but there are some questions that come to my mind. For example, how can the proof be proven to be true unless the developer and the customer are able to speak the same language? Or, have I missed something extremely basic whereby the languages used are merely a manifestation of some specification that is (somehow) reduced to its mathematical form? In either case, I am intimating one thing that seems to make sense to me: If the customer(s) and the developer(s) can speak (or write, or formulate, etc.) the same language and it can be guaranteed that the language will produce the results that the customer is looking for, I think it would be a step in the right direction. Of course, if it gets good enough, would we need a programming staff to implement this stuff? (I know we would, but it is an interesting question to let my mind play with).<br /><br />I am hoping I can get someone (or some paper) to give me the reader's digest version of this whole topic so that I can at least grasp the entire concept before wading into the details, but that may not be possible. The topic itself seems to be complex and it goes into areas of mathematics that I have not used for some time. So, we shall see. Telling will be what I write my next blog entry about.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-5819248201921656959.post-7550287403428130872008-04-22T05:36:00.003-04:002008-04-22T07:05:52.929-04:00What are People Doing?Perhaps the biggest difficulty in taking over a troubled (or, formerly troubled) project is knowing what people are doing and whether what they are doing is what they should be doing. Add in the staffing changes that typically take place in such a situation and you can quickly wind up with a mess where you do not know all of the people on the project, you do not know what they are doing, and you are not sure whether you will be able to meet the client commitments set forth when you took the project over. So, what can you do?<br /><br />Here are several techniques that I have used to understand what is going on within a project that has experienced great turmoil. Hang on, these are not for the faint of heart.<br /><br /><span style="font-weight: bold;">Organizing Techniques</span><br /><br /><ol><li>When things are too big to get your arms around, make them smaller. Large projects are the most difficult to gain control over. I had one project where there were over 150 people working on it. One person just could not understand what everyone was doing. Nevertheless, those little organization boxes that people like to display can be helpful because they break the team down into "bite-sized chunks." You can leverage that structure to find out what people are up to. Of course, a risk here is that you do not get all of the information, but it is probably a necessity.<br /><br /></li><li>Begin collecting information, even if it is not completely organized. A lot of times, plans are still being created or "worked." That means, people are just doing things that they <span style="font-style: italic;">think</span> need to be done. You need to find out what that is. Scrum gives a valuable method for getting underneath some of what is going on. With those sub-teams, institute a scrum with the leaders (hopefully, there are not too many of them!). Initially, this can be a weekly event, even an asynchronous event if you need to do it that way. The key is to get each team to provide you with what they worked on in the prior week, what they are working on this week, and if there are any road blocks. The information can be used to link it up to any plans that are being created.<br /><br /></li><li>Leverage the project's leadership team. You can't do it all. Let the leadership do their job and get you the information you need to understand what is going on and what time line they are working towards.<br /><br /></li><li>Leverage the client. In theory, they know what they are asking for. Do not be afraid to ask them what they have requested of the team to date. Of course, take that advice with a grain of salt: they may try to add something that was not originally specified.<br /><br /></li><li>Leverage your executive management. Many times, projects are creatures of many groups within an organization. Navigating the groups is time consuming and can be quite difficult. The executive team knows what these groups do and, hopefully, why they are on the team. Do not be afraid to ask them for help when you need it. After all, they asked <span style="font-style: italic;">you</span> to take over this project on their behalf.</li></ol><br /><span style="font-weight: bold;">Information Collection and Analysis</span><br /><br /><ol><li>Simple is best. Use a data base, a wiki, a spreadsheet—whatever works.<br /><br /></li><li>Use a tool you are comfortable with to collate the information. I have found that mind mapping tools work particularly well here.<br /><br /></li><li>Collect only enough information to understand what people are doing. Leave the details for when the plan is ready. (Remember, you are trying to find out who is doing what. The plan itself is an important part of this, but if it is not in good shape, you need to understand what the team currently thinks is important—whether it is or is not.<br /><br /></li><li>Organize the information by team, but put some intelligence into the collection. That is, if something seems interrelated, mark the relationship somehow. If you are using a mind mapping tool, a dependency link will probably do it. If you are using something like a spreadsheet, you may need to create some sort of identifier. The key is to be able to follow your logic later!<br /><br /></li><li>Have someone else review what you have collected and get their thoughts on what you have. What do <span style="font-style: italic;">they</span> see that is happening? Does it match what you see? If it doesn't, find another person to do the interpretation again. You may wind up with several opinions as to what is going on. You need to listen to them all and somehow judge which opinion is most trusted. Try to stay away from your own if everyone else is saying it is something different!<br /></li></ol><span style="font-weight: bold;">Understanding What You Have</span><br /><br /><ol><li>When you review the information you have collected, you need to see if it matches up with what has been requested of the team(s). This can be difficult if scope is not under control or is currently open. Nevertheless, this is a critical task! It is the only way you will ever know if what people are doing is what they should be doing.<br /><br /></li><li>If things do not seem right, ask questions. People are usually more than willing to tell you why they are doing something. Just because it was not requested does not mean the task should not be done, as it may be a dependency for something that was requested.<br /><br /></li><li>Create a scope to activity traceability matrix. This can be time consuming, but it will show you where you have gaps. This works best when the scope is reasonably defined. By understanding what should be done and matching it up to what is being done, you can re-direct efforts as necessary to protect the schedule, cost, or deliverables of the project.</li></ol><br /><span style="font-weight: bold;">Concluding Remarks</span><br /><br />Most of the above "techniques" may seem like common sense (and they are). But, I have found them to be most useful when a project I have assumed is in a state of transition. Hopefully, you will find them useful as well.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-5819248201921656959.post-85502290461032572952008-03-29T15:28:00.007-04:002008-04-22T05:36:26.311-04:00Can a Death March Project be Healed?How many times have you found yourself on or in charge of a project that seems to be cursed, ill conceived, and just too visible for its own good? You know the kind: all of the people on them seem to have lost their mind, nothing seems to get done, and there is more time put into status and how things look than actually doing the work. The problem with these types of projects is that any reasonable person would seek to avoid or cancel them for the good of the company and their own sanity and health if they could. Nevertheless, these projects seem to be all to common. The larger they are, the worse they can get. Their prevalence makes it virtually impossible to avoid them, so what do you do if you find yourself on one of these cursed spawns of the devil and can you reclaim your sanity by making them better somehow?<br /><br /><span style="font-weight: bold;">What is a Death March Project?</span><br /><br />Ed Yourdon defines a <span style="font-style: italic;">death march project</span> as:<br /><blockquote>"... one for which an unbiased, objective risk assessment (which includes an assessment of technical risks, personnel risks, legal risks, political risks, etc.) determines that the likelihood of failure is ≥ fifty percent [1, p. 3]."</blockquote>Sadly, some may look at that definition and note that all of their projects begin that way. The key part of Yourdon's definition, in my opinion, is that the likelihood of failure is greater than or equal to fifty percent. One of the ironies is that nobody ever really does an objective risk assessment on these types of projects, so you never really know what the true likelihood of failure is. Also, the definition of failure is highly subjective in some cases. Is it missing a date? A key feature? Low quality? All of the above?<br /><br /><span style="font-weight: bold;">Why not Walk Away?<br /><span style="font-weight: bold;"><br /></span></span>Walking away from a death march project is almost always the right action, assuming you can recognize it early enough. But, there are times when you just cannot walk away from them. Their prevalence is one reason: How do you walk away from something that happens so often? There are other motivations as well. Some wish to take on the challenge that these projects offer in the hopes that it will advance their career. Others remain out of fear that if they do not they will be penalized. Whatever the motivation, there appears to be sufficient evidence to suggest that we may want to find a way to heal these projects because they are going to continue regardless.<span style="font-weight: bold;"><span style="font-weight: bold;"><br /><br /></span>Healing the Death March Project</span><br /><br />The definition of failure (and success) seems to be the key ingredient for understanding whether you can heal a so-called death march project. The problem is, the true dependent variable may not easily make itself easily known. That suggests that you need to understand what the organization is trying to accomplish and somehow gain control over the variables that cause the project to fall within the "death march" category.<br /><br />The most common problem I have seen in difficult or troubled projects is uncontrolled scope. Regardless of the software methodology, if there is no control over scope, I do not think healing the project is possible. While poor requirements (or stories, depending on your methodology persuasion) may be a sub-dimension of this, when I have seen projects that were otherwise aggressive yet have a sufficient control over scope they never seem to devolve into a chaotic death march.<br /><br />It is much to simplistic to state that controlling scope (or, just understanding scope and changes) will fix a death march project. Sometimes, the scope is all-too-well known and that is part of the problem: it's too big to fit. Nevertheless, I think many such projects would benefit: it could move them out of the category or, at the very least, you will know what you are in for!<br /><br /><span style="color: rgb(51, 51, 255); font-weight: bold;">References</span><br /><ol><li>E. Yourdon, Death March. 2nd ed., Upper Saddle River, New Jersey: Prentice<br />Hall, 2004.<br /></li></ol>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-5819248201921656959.post-76775257245620657142008-02-08T20:16:00.001-05:002008-02-08T20:45:18.487-05:00How Does an Agile Team Work from Day to DayI got a question the other day about how an agile team works on a day to day basis. It is an interesting question because the individual that asked me was trying to figure out how to explain it to his vice president. It got me to thinking about a couple things: what really does happen on an agile project each day? Sure, there is the daily scrum (or stand-up, depending on your preference), potentially pair programming, test driven development, etc. But, can those activities be characterized in such a way that someone who is not familiar with agile software development can understand it?<br /><br />Boehm and Turner have a good description about a day in the life of an agile project and a more traditional plan-driven project in their <span style="font-weight: bold;">Balancing Agility and Discipline: A Guide for the Perplexed</span> (it is in Chapter 3). Nevertheless, our organization has the additional challenge of using distributed (or, more correctly dispersed) teams. While the basics of Boehm's and Turner's "day in the life" does not change, I have outlined a couple small adaptations that are important for a distributed team:<br /><br /><span style="font-weight: bold;">The Stand-up Meeting</span><br /><br />When the team is sitting together (collocated), communication is generally face-to-face. In most cases, this is the most efficient form of communication (an exception is when personalities are so strong that face-to-face is detrimental). For a team with dispersed personnel, communications need to be by another means. Nevertheless, a stand-up meeting needs to be near real-time to be effective (this is based on my own research). Instead of standing in a room, the team needs to agree upon a time to meet and hold the meeting by teleconference. We have typically enhanced this audio-only medium with instant messaging support and a shared web conference (with our without a digital white board, depending on the topic). At the end of the meeting, a diary (or minutes, if you prefer) entry is made on the team's wiki page.<br /><br />Just like a normal stand-up or daily scrum, each individual gives a brief summary of what they accomplished yesterday, what they intend to accomplish today, and whether they have anything blocking their progress.<br /><br /><span style="font-weight: bold;">Communication Throughout the Day<span style="font-weight: bold;"><br /><br /></span></span>Unlike their collocated counterparts, dispersed and distributed teams cannot just call across the room if they have a question they need answered. Instead, we have used instant messaging. At the beginning of the day, a group instant message chat is begun for the day. When a team member has a questions, they enter it in the chat. This includes clarification questions for the customer and their responses. If a more comprehensive discussion is necessary, the phone is the primary medium.<br /><br /><span style="font-weight: bold;">Summary</span><br /><br />The fundamental difference between collocated teams and dispersed teams performing agile software development is not in the activities, but the modes and methods of communication. Dispersed teams are not as efficient in their communications, but it can be made to work when all of the members are dedicated. I hope my colleague's description goes well.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-5819248201921656959.post-41459114375594433982007-12-16T07:56:00.001-05:002007-12-16T08:18:00.627-05:00Recognition for a Job Well DoneThis time of year, many companies and organizations begin to evaluate their employees to give them their annual appraisal. It occurs to me that the way organizations evaluate their people is most likely related to their theory of management and employee high performance. Two basic methods come to mind: The collegiate method and the ranking method.<br /><br /><span style="font-weight: bold;">The Collegiate Method</span><br /><br />I called this first method of appraisal the <span style="font-style: italic;">collegiate</span> method because it follows what one might see in a college setting. That is, each person can vie for the top spots and if they complete a set of requirements or goals they get rated at the top. So, if I get a 100% on a college exam, I get an A. If my neighbor gets 100% they also get an A. Since knowledge of the topic is the primary concern, multiple people meeting high standards <span style="font-style: italic;">can</span> mean that there is a broad understanding of the topic. Unfortunately, it can also suggest that the measure may be flawed.<br /><br />I see the advantage of this method of appraisal being that each person has an opportunity to receive a top rating if they follow certain guidelines. If done properly, employees that work hard and meet the goals of the organization are rewarded, while those that do not are not. The problem seems to be that just like college grades, the top slots may become inflated because the managers are not doing their jobs—they avoid the tougher conversations with the employee.<br /><br /><span style="font-weight: bold;">The Ranking Method</span><br /><br />I am calling the second method of appraisal the <span style="font-style: italic;">ranking</span> method. Unlike the collegiate method, only a select few can be at the top—and some people <span style="font-style: italic;">must</span> be at the bottom. The advantage of this type of appraisal method is that you reward the best of the best and can concentrate on improving the lowest contributors (at least, lowest relative to their peers). So, even though I may meet a set of goals for the organization, I may not have gone above and beyond: in my prior analogy, I cannot get the A because someone else did.<br /><br />I see the advantage of this method of appraisal in trying to initially build a higher performing team. It gives the team and you a way to understand where your top contributors are. On the other hand, doing this for too many cycles would seem to erode trust in the employee population—especially if you are not continuously replacing the lowest people. Since people's performance does not always change that much from year-to-year, the same people may wind up at the bottom. That cannot be good for their morale.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-5819248201921656959.post-32438161542153754022007-12-01T09:26:00.002-05:002007-12-03T14:51:40.880-05:00Agile Software Development - Business Culture and ChangeTraditional software development methodologies primarily focus on the process that an organization follows to build and release software. Agile software development methodologies approach software from a social perspective and advocate collaboration over strict processes. This is not to say that traditional methodologies ignore the social perspective or that agile methodologies ignore the process perspective.<br /><br />Nevertheless, the methodological emphasis of traditional software development can become woven into the culture of an organization, making it difficult to adjust to agile methodologies. Large organizations would seem to have the most difficulty making changes to their culture (in general) due to the number of people they need to convert and the higher probability that individuals and teams are not in one location, making communication and reinforcement more difficult.<br /><br />I have heard that deep cultural change in an organization can take 7-10 years to be successful—particularly in a large organization. While individual agile techniques predate some of the traditional methodologies, their working in synergy and the social emphasis did not come about until the late 1990s. But, putting it all together and gaining traction in an industrial environment are two different things.<br /><br />As we sit on the cusp of 2008, I am starting to see some real traction in large organizations. Agile has matured as well: the zealots who wanted us to do everything in a one-size-fits-all fashion (while decrying similar calls from their more traditionally oriented bretheren) seem to no longer dominate the conversation. Nevertheless, I find myself wondering when that 7-10 year period began (or will begin, as the case may be) and whether we will be moving on to something else once that transformation is complete, as I am sure we will be.<br /><br />In my own case, I think I can peg the beginning of that cultural change in my organization to early 2004 when, after a series of highly visible internal project failures, people began to ask whether they were developing software the right way. I have to admit that I was in the right place at the right time. I have always had a solid record of delivery and was asked to lead and "clean up" this troubled area. The fact that individuals were more likely to try something new is something I was happy to take advantage of. In the end, I was only able to go so far before the culture got in the way.<br /><br />I guess that means we are only four years in. The next three-to-six years will be interesting.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-5819248201921656959.post-60013029361486726202007-11-24T05:59:00.000-05:002007-11-24T06:49:56.461-05:00The Evolving Large Project StructureDefining the structure of a large software development project can be a daunting challenge. The functions designed into a project's governing model are highly dependent on the goals of the project, the organization into which the resulting product will be deployed, and (to some extent) the project's technological selections and/or constraints. In my experience, most large project structures evolve in an organic manner and as a response to some condition or stimuli. For example, a dependency coordinator function is added to address deficiencies in upstream and downstream management.<br /><br />An evolving project structure would appear to be a good thing, so long as the organization always focuses on what it needs and is able to adapt to the new reality within a reasonable time frame. Nevertheless, all too often no attention is paid to a project's structure until an event occurs that exposes a serious weakness. In traditional projects, this could mean that critical functions (like how change is managed) can be left undefined until the project is in trouble and unable to meet its dates. Agile projects do not appear to be immune to this phenomenon even though frequent process and scope change are expected.<br /><br />Why do organizations undertake large multi million-dollar projects and not take the time to prepare themselves for the inevitable pitfalls that the lack of a flexible, well thought out governing structure bestows? A myriad of reasons come to mind: lack of perceived time to set up governance, lack of experience, a desire to not spend project funds on scaffolding, etc. Perhaps the more important question is what should we do about it?<br /><br /><span style="font-weight: bold;">Start Small, but Start Smart</span><br /><br />Despite our desire to jump right into a project, some time needs to be spent up front identifying how a project will be organized and who will be assuming certain roles to make sure that essential functions are covered. In an agile project, this may take the form of defining the project's stakeholders and how they will be represented to the team(s) or how inter-team communication will occur (between multiple agile teams, the so-called "scrum of scrums" concept, or between agile teams and their non-agile counterparts). In a traditional project, the traditional functions of change management, dependency management, etc., should be dealt with up-front—even if one person owns them initially.<br /><br /><span style="font-weight: bold;">Look at Past Successes and Failures</span><br /><br />It would seem to be a rare case that an organization would staff an entire project with inexperienced team members. Even if the majority of team members lack specific development experience, there are always those that have done it before. This knowledge needs to be mined. Expert help and best practices can also help avoid some of the pitfalls of a bad project organization structure.<br /><br /><span style="font-weight: bold;">Don't be Afraid to Change Course</span><br /><br />If a structure is not working, change it! Sometimes we try to push a bad position just to maintain the status quo. It is inevitable that you will not identify all of the structural components that you need up-front. When you encounter one of these deficiencies, address it. Be equally mindful of outdated structural components and get rid of them.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-5819248201921656959.post-13021414850382850072007-11-20T21:02:00.000-05:002007-11-21T10:08:09.653-05:00Doing Things the Old-fashioned WayMy work gives me a lot of insight into how software projects can (and frequently do) go bad. Much of my focus of late has been on the more adaptive software development methodologies (the distributed agile software development experiments I did for my doctorate, for example). But, one project, or perhaps more correctly, program that has caught my attention as of late is one that is traditionally considered too large for using agile as a methodology -- with 250+ individuals involved. Officially, they used a plan-driven methodology.<br /><br />Some agile purists might point out that the methodology they chose (actually, that they were forced to use) is the root of the problem. Perhaps it is, but as I look deeper into the project and its troubles I notice that they really did not pay much heed to any particular (official) methodology. As they move out of their dark days and into their next project, I wonder whether just <span style="font-style: italic;">following any</span> rigorous methodology would help them be more successful (yes, I consider agile methodologies to be rigorous -- some of the most disciplined and rigorous, actually).Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-5819248201921656959.post-85500613702273198092007-11-19T15:13:00.001-05:002007-11-21T10:07:06.353-05:00My First Entry<span style="font-family:verdana;">This is just a test entry to get things going. I currently have this blog marked so that everyone can read, but comments are moderated. I am going to test it out and see if I like it or not. I do not expect this will replace my normal journal, but I may be able to include some thoughts that are less personal, but are running through my head.</span><span style="font-family:verdana;"><br /></span>Unknownnoreply@blogger.com0