Developing Software Productively through selective automation

How do you increase your software development productivity over the long haul? Here's how: Examine your daily task work to identify tasks that are amenable to automation, and then automate it. For me, this means to do the following:

1. Maintain a constant awareness of all of your development activities, specifically patterns of behavior or groups of actions that are repeated multiple times throughout the day.
2. Of those patterns, identify the ones that are comprised of tasks that do not change regardless of the circumstances.
3. Determine if those tasks are amenable to automation (some will, some won't). This excludes tasks that should be delegated to someone else to do.
4. Schedule time to encapsulate the tasks in a software routine.
5. Make executing that routine mindless and effortless, by associating the execution of the routine to a new and unique combination of key-bindings in the main window of the primary editing tool you use (e.g. Emacs, Eclipse, Jedit, etc.).

Some may think that the "schedule time" item will eat into their productivity. However, I have found in practice that the time saved by automation will pay for itself over time. But there is one more benefit: Having a machine execute the tasks frees up your mind to think at a higher level of abstraction, in a given project. Making a task mindless and effortless has the goal of not distracting your mind from the flow of adding, deleting, and moving code around. Any requirement to pull down menus, bring other windows to the front, type in and execute long command lines, etc., are distracting to the mental process of software development and should be gradually eliminated by delegating those tasks to push-button automation. Therefore, as a software developer, those activities are best done right there in the text editing window itself, to be driven by carefully chosen key sequences that are easy to memorize. Below are some examples of tasks I discovered fit the above criteria, and that I could automate (this is specific to my focus on code development, but they could be generalized for other work domains):

1. When the cursor is on a full or relative path to a file somewhere on the filesystem, typing a keystroke to open the file in the text editor. Compare that to opening up a new window, moving the mouse cursor into that window, navigating a file browser to find the file or typing in the full path to the file in the file system. Think about how often that task is done in given developers work day.
2. When the cursor is sitting on a URL, typing a keystroke to open the URL in a browser. Think about how often you need to refer to reference material that is only on some remote web server somewhere.
3. When the cursor is sitting on a symbol whose definition you need to alter, typing a keystroke to drive your editor to view and edit that definition. Compare that with using a file search to find the definition, and filter out the false positives.
4. You need to go back to where you started when editing some code, so type a keystroke to go back to the place where you started. The idea here is that each time you navigate to a new view on some source, there is the equivalent of a "back" button in the form of a key sequence. This should be applicable for all types of navigation to some file, symbol, or web page.
5. You need to reload your brain with the context after an interruption. The thing being automated away is the time wasted wondering where you left off, or clicking through various windows or views to answer that question. The solution is to track notes of decisions you are making in a searchable set of interlinked note files. This excludes writing them down on paper, since there is no search capability (and filing cabinets and other filing systems are yet another mental distraction). In my case, I use multiple text files that are interlinked (Muse mode in GNU Emacs). This also pays dividends later on when you need to refresh your memory on decisions that were made on the project done months later.

Verifying OpenID works with Gmail, Blogger, and Eviscape

I tried using an OpenID to understand it more fully, and to see how well it works in practice. This initial foray involved Gmail, Blogger, and Eviscape, with Blogger being the OpenID provider. My experiments (shown later on in this blog post) seems to work for the most part, with the exception of a few productivity problems:

1. Registration at new sites may (in the case of Eviscape) require you to add a site-specific password that is not needed since OpenID provides the authentication.
2. After having logged into the main web site that manages the OpenID, ideally I should not have to even type in the OpenID itself when browsing to the other site that is aware of my OpenID. However, again in the case of Eviscape, I did have to type in the OpenID. It is a usability issue because the OpenID is a long URI, which will be cumbersome to type in or retrieve from some other page or text file (especially in my case, since I know I will not be able to remember it).

From my experimental scenarios below, this is what I believe the main requirement is for OpenID:

On a given browser session, when the user provides a single username and password, all other sites that are aware of that OpenID, should not then prompt redundantly for any password. If the user closes down the browser completely, and restarts the browser, the user should be required to provide the OpenID and associated password only once when logging into any of the sites previously mentioned, in that new browser session.

Below, I am also using FireFox 3 running on 32-bit Debian Linux on an IBM R51 laptop:

Scenario #1 (Registration with Eviscape prompted for an extra, unnecessary password):

1. Logout completely from Gmail and Blogger, and close all tabs and windows in the browser to any those websites¹.
2. Without being registered already with Eviscape, register using the OpenID.
3. At some point in the registration, it prompts for a new password, so give a different password than the one associated with the OpenID provider². This is unexpected behavior since the registration should provide a way to specify that only the OpenID usename and password is to be used, and not require the user to add a redundant password specific to that website.
4. Finish registration.
5. Logout of Eviscape
6. Login to Eviscape.
7. Type in the OpenID into the OpenID field.
8. The site then prompted for the OpenID username and password. Supply the username and password.
9. The site is now authenticated, which is expected.

Comments: Not once did I have to provide the Eviscape-specific password that I was required to supply during Eviscape registration. Hence, that Eviscape-specific password is unnecessary and redundant. I do realize that the Eviscape login web page has text entry fields for the Eviscape-specific username and password, as well as the OpenID, so obviously they have to support both methods of authentication. But, given that I provided the OpenID, Eviscape should (during registration) offer an option to use the OpenID username and password exclusively, thus avoiding the prompt to create the extra username and password.

Scenario #2 (Initially logging into Eviscape, without being logged into any other sites, using my OpenID):

1. Logout completely from Gmail, Blogger, and Eviscape, and close all tabs and windows in the browser to any of those websites¹.
2. Connect to the main Eviscape home page and enter in the Blogger-provided OpenID.
3. A new web page opens up requesting the Google account username and password². Note that the Google account username is requested, and not the Blogger account name. That makes sense given that my Blogger account was set up to use my Gmail account name and password.
4. I enter in the Google account username and password. Supply the username and password.
5. The site then prompted for the OpenID username and password. Supply the username and password.
6. The site is now authenticated, which is expected.

Scenario #3 (Does OpenID login with Eviscape seamlessly log me into Blogger?):

1. Do Scenario #2.
2. Open up a new browser tab, and browse to the Blogger site.
3. Notice no password prompt is given and that Blogger shows that you are signed in. This scenario works as expected.

Scenario #4 (Does OpenID login with Eviscape seamlessly log me into Gmail?):

1. Do Scenario #2.
2. Open up a new browser tab, and browse to the Gmail site.
3. Notice no password prompt is given and that Gmail shows that you are signed in. This scenario works as expected.

Scenario #5 (Does a Blogger non-OpenID login seamlessly authenticate Eviscape via OpenID?):

1. I logout completely from Gmail, Blogger, and Eviscape¹.
2. Connect to the main Blogger login page and enter in the Google² username and password.
3. Connect to the main Eviscape home page and enter in the Blogger-provided OpenID.

Note that I did not have to provide the Google username and password, but only had to provide the OpenID itself. This is mostly expected, however, it would be nice to not even have to type in the OpenID itself, but that is probably asking too much. Footnotes:

1. This forces these websites to not use existing authentication state that might be in the browser or on their respective servers.
2. My OpenID provider is Blogger, and Blogger is managed by Google, so the OpenID username and password is equivalent to the Google username and password.