Brandon's Notepad

February 13, 2018

Agile: Online Resources


This is a list of interesting articles and videos concerning Agile Software Development. I have read, watched, or listened to each one. They have been added here because I found the content useful, either in my current situation or for future discussions. Expect the list to grow.


The articles and ‘blog posts listed below are grouped by topic, but the topics are in no particular order. I tried to find the originating article for a topic (if possible) and then list below it (indented) other articles that respond to or built upon it.


At the moment, the list of videos is less-stringently organized than the articles in the previous section. The reason is that there are far fewer videos worth watching than there are articles to read, and I tend to favor long videos, which shortens the list even further.



January 30, 2018

Agile: A Conversion Story


This is the story of how I became an Agile convert. After sixteen years of denial, I finally opened my eyes to the benefits of this wonderful framework. Writing this post was a very humbling experience. I was seriously tempted to blatantly rip off Kubrick and title this post How I Learned to Stop Worrying and Love the Scrum.

My first exposure to Agile was sometime in 2001 in the form of XP (Extreme Programming). I was active on several developer discussion forums at the time and XP started coming up as a topic more and more frequently. One of my favorite discussion points was the need for proper traceability from concise, structured requirements to design elements and ultimately to code. XP, with its paper-based story cards strewn about on tables or cork boards and then entombed in boxes or banded stacks when the project was over, seemed to mock the sheer beauty and efficiency of a well-maintained requirements database that could be easily searched and reported upon. And paired programming? What a waste of developer hours! Why dedicate two people to a single programming task? What kind of coder needs someone constantly looking over his shoulder and critiquing every little typo anyway? I conceded that such foolishness may be tolerable for small applications or short-term engagements, but it would never work for real applications, the stuff of corporate I.T. projects that took many months or even years to deliver.

I happily ignored Agile for many years after that. Doing so was easy, as none of my clients or employers used any of the Agile frameworks, that is, until about four years ago when the new CIO at my company started talking about it…a lot…and not as a joke. No one in the department seemed to be taking him seriously, so I dismissed the notion that it would actually take hold, but I also knew that I could no longer flat out ignore Agile. If the CIO was talking about it, then I had to make sure he (and everyone else) knew that adopting it would be a mistake. I didn’t want to look like I wasn’t willing to be a team player, but I also didn’t want to throw away all of the hard work we had invested in creating a very stable and controlled development environment. That CIO left the company within a year. An interim CIO seemed to like the Agile concept, but admitted openly that he had no plans to change the strategic direction of I.T., preferring to “keep the lights on” and let the permanent replacement call the shots. Whew! We were safe. So I thought. The new permanent CIO, though not heavy in development experience, arrived already convinced of the efficacy of Agile.

Any attempt to derail Agile at this point would have been what we call a serious CLM (career-limiting move). It was time to adapt. But how? Our development, test, and release policies and procedures were hardly what you might call Agile-friendly. Frankly, our Project Management policy read like an excerpt from the PMBOK. I had no idea what this was going to look like or where to even start, When one consultant started managing his development team using Scrum, I asked to shadow him so that I could learn more about how Agile was supposed to work. I admit, I would not have been disappointed had I found evidence confirming my previous notions about Agile, but I attended the team’s events with an open mind and tried to leave my skepticism at the door. By the time he left for his next assignment, I still wasn’t convinced that Agile was going to be the right fit for our department, but I had learned enough to understand how it might work if everyone got used to it and agreed to play the game.

My biggest takeaway from this exercise was that, in terms of software development, Agile wasn’t significantly different from traditional development (i.e. the waterfall methodology), in that requirements still had to be gathered, software designed, code written, the product tested, and user documentation produced. What was radically different was that it severely limited the scope of these activities for a specified, short-term period of time; thus, it allowed for course correction at any point should (read: when) requirements change.  I learned that requirements needn’t be quite so formal or design so rigid, and that documentation can be limited to a sane amount that might actually be read again later. I still felt like a lot of useful information — mostly artifacts from the development process useful internally in many ways — was going to be lost in the process.

A few months passed and I continued to monitor the growing use of Agile within the development teams. By this time, most of them had latched onto Scrum terminology in particular. Overall, things didn’t seem to be going well. The teams were struggling with many different things, and it was becoming obvious that most of them were not truly adopting the Agile mindset. Then a golden opportunity arose! I managed to volunteer to be the Scrum Master on one of the teams. “As long as it doesn’t interfere with your regular duties,” my boss said as he gave me permission to fill the role temporarily. The project was failing and the team disjoint, so I figured it was going to be a serious opportunity to experiment and see what Agile could do to improve the situation.

The first sprint was rocky and I spent half of my time figuring out how to produce a proper burndown chart in the task management system we had selected. With the second sprint I began every daily scrum with the burndown chart on the large screen in the conference room. The (positive) impact this made on the team was shocking. Tired of watching me update tasks with hours spent and hours remaining, the team started keeping their own metrics up-to-date sometime in the third sprint. By the fourth sprint, we were “flying by instrument” as I like to put it. It was beautiful! The sprint backlog (in hours) was at about 85% of capacity, leaving a little wiggle-room for error, and we trended downward more-or-less as one might expect. I’d love to report that the project had made a sweeping turn just in time and became a stunning success, but sadly, it did not. Despite the great strides the team had made, it was not happening fast enough, and management pulled the plug on our experiment. The software was eventually released for production use, late, using conventional project management, but I walked away with a completely new perspective. I finally understood why and how Agile worked! I was no longer a critic, but an advocate.

Within two months, half of the department (including myself) had been formally trained and I jumped fast at the chance to be on the Agile transformation team that would be responsible for the formal adoption of Scrum. Half a year later, I earned my certification. Looking back, it amazes me how quickly my view of Agile changed so completely. I have since learnt a great deal beyond what was covered in training, but I will have to write about such things another day.


January 19, 2018

Agile: My Journey


About a year before I wrote this post, I set out on a journey that I was not expecting to take. I became seriously involved in Agile software development, the Scrum framework to be more specific. Prior to that time, I was not only completely uninvolved, I was an outward opponent of Agile as a result of my initial exposure to Extreme Programming (XP). What changed? Where am I headed now? That’s all part of my story.

This is a work in progress. If you find what I have posted so far to be interesting, please feel free to follow me on Twitter and/or

My Journey

In the spirit of Agile, I’ve decided to document my journey in the form of stories, the sum of which constitute an epic. Cute, eh? No, I didn’t plan for it to happen this way. The stories have just emerged. This is the landing page. As I publish the parts of my story, I will link the posts to the list items below. This will take time. I am still on the journey.

  • My conversion story
  • Why Agile Works
  • I think I’m missing something here…
  • A (Hard) Lesson in Writing Stories
  • Let Them Eat Cupcakes
  • more to come…
  • The Agile Blogger

I also plan to post an Agile reference page, which I will probably link in this space.

My Goal

As with all of the content on this site, my primary goal is to record my personal notes on this topic for later use. A secondary goal is to make this information available to anyone who may find it useful. Another huge personal benefit is that the preparation required to write on this topic almost ensures that I will ingest the material

Why Now?

So, why am I writing about Agile in 2018? It’s been seventeen years since the Agile Manifesto was penned, and even then, some of the Agile variants had already been in use for ten years or more. Agile isn’t new anymore, it’s not the next big thing. In the grand scheme of things, I arrived on the Agile scene quite late and I am far from being an expert (yet). The answer is that this post (and its related content) is as much about me and my experiences as it is about Agile itself. I’d like to think that this makes the material unique, but I know that I am following where many other developers have already trod. Nonetheless, I hope that writing my thoughts will provide value.



December 27, 2017

The vi Text Editor

Home > My Lists > Technology > Software Development References > The vi Text Editor

User Guides & Tutorials

Tips & Tricks

  • Insert contents of another file into current file using :r filename
  • Open second file in split window using :sp or :vsp. Use Ctrl+w to switch between window panes.


September 14, 2017

TFS / VSTS Customization


I started working heavily with Microsoft Team Foundation Server (TFS) in the summer of 2016 and may be migrating to Visual Studio Team Servcies (VSTS) in the not-so-distant future. The need to customize TFS operations was almost immediately obvious, and the complexity of the customization only increases in proportion with the use of the tool. This page is a (growing) list of links that I’ve found useful.

Runtime Environment Variables

Environment variables are available for use during both build and release operations. These are my go-to references when I need to figure out how to get to runtime data.

Marketplace Extensions

The Visual Studio Marketplace offers many useful extensions for TFS & VSTS. Some implement or extend features such as dashboards, but the ones I’m most interested in (at least for now) are the build and release tasks. Like apps on a smart phone, these little gems eliminate the need for writing extensive scripts to compile code and deploy products. I’ve found it important to check the Marketplace often for new items as well as for updates to extensions already in use.




  • Hopefully, I won’t have to add any extensions in this section.

Custom Scripts & Extensions

If you can’t find what you need in the Marketplace, you can always write your own deployment scripts and extensions. These can be published or retained for internal use only, your choice. Here is a list of useful resources for beginners.




More to come…


June 5, 2015

Playing WAV Files In PERL

Filed under: Perl,Programming — Brandon @ 3:42 pm
Tags: , , , , ,

Home > My Lists > Programming Notes > PERL > Playing WAV Files In PERL

I don’t remember why exactly, but a few years ago I wrote a countdown timer that would sound a chime when it reached zero. I decided to keep the code that plays the sound for future reference. Note, this works using ActiveState PERL on Windows.

use Win32::Sound;

$wav = 'C:\path\to\file.wav';



January 30, 2012

Getting Google Maps

Filed under: How-To,Online Tools,Perl,Programming — Brandon @ 4:08 pm
Tags: , , , , , , , , ,

So, I’d like to have a current traffic map delivered to my e-mail at the precise moment I’m leaving work for the day. Call me lazy, but this is the sort of thing that can be automated pretty easily and I don’t want to go look it up, I want it delivered. Someday, I’ll get around to setting this up, but as they say, a journey begins with a single step. In this case, the step is to find a way a good to download Google Maps with a script. For now, that is the scope of this post.

Here’s some initial research to plow through:
Mapki: Google Map Parameters Best reference so far!
Google Static Maps API*
A PERL/Wget solution
A Python script
MapTileCacher in PERL
In Bash
Discussion on Google blocking tile downloads

* On 2/7/2012, I tried using the Google Static Maps API and received Error 400 (malformed or illegal request) when using the URL described therein. I have had more luck using Google Maps directly to frame the map, getting the (perma)link, and tweaking the parameters.


October 7, 2011


Filed under: Programming — Brandon @ 10:00 am
Tags: , , ,

Home > My Lists > Programming Notes > Semaphores

A semaphore is an abstract data type used to control access to a common resource in a parallel programming environment.

Javaworld Q&A article from 1999
Java Named Semaphores by Mark Nadelson, C/C++ Users Journal
Concurrent Programming Using Java by S. J. Hartley, Drexel University


March 1, 2010

The Mark Of The Web

Home > My Lists > Programming Notes > HTML & CSS > The Mark Of The Web

Starting with IE for XP SP2, web pages generated locally (e.g. in a temp directory) do not load properly in Internet Explorer if they include Active Content. This is a result of improved security surrounding the Local Machine Zone. Depending on your operating environment, it may not be possible or desirable to change IE’s security settings; moreover, such changes would have to be applied to all machines accessing local content. The “Mark of the Web” is a better solution.

Microsoft has implemented a new feature called the “Mark of the Web” (or MOTW for short). It is a specially-formated HTML comment that directs IE to open the page in the same security zone as the specified URL. Two valuable examples are:

<!-- saved from url=(0014)about:internet -->


<!-- saved from url=(0016)http://localhost -->

Under default security settings, IE is forced to open the page with the former code in the Internet Zone and a page with the latter code in the Local Intranet Zone. The number in parentheses is the number of characters in the URL.



July 30, 2009

HTML Special Characters

Filed under: HTML,Programming — Brandon @ 10:43 am
Tags: , , ,

Home > My Lists > Programming Notes > HTML & CSS > HTML Special Characters

I often need the HTML codes for special characters. I’d love to compile a definitive list of my own here, but until I have the time this reference will have to do.

Next Page »

Create a free website or blog at