Steele Bit programming & development musings by Andrew Steele

I am in the process of preparing a presentation on Stack Overflow for the Sandia .NET User Group. In simple terms Stack Overflow is a programming question and answer site that's free. If you have not heard of it you are either not a programmer or have not been standing near me when I am singing the site's praises.


I will link to the presentation when I have it prepared, but for now I wanted to thank Jeff Atwood and Emily Yacus at Stack Overflow for being so cool as to provide me with t-shirts and stickers to handout after my presentation.



Thanks again guys and keep up the great work!

Setting up an Android development environment is not a terribly hard task, but there are several steps involved. Before I document those steps a note about the hardware I used for my forays into Android development.
Development Machine Specs

• Windows 7 64 bit
• Processor: Intel Core  Duo T9800 @ 2.93GHz 2.94GHz
• RAM: 4.00 GB

Android Platforms

• Motorola Droid
• HTC Incredible

The following steps are merely the ones that I used to develop Proximity Alerter and are definitely not the only options for setting up an Android development environment. Accounting for download and installation time the following steps should take less than 2 hours.

1. Step 1 - Android SDK & Components
   
   • Download and install the Android SDK
   • Once the SDK has been installed, you'll need to manually add the 2.1 platform and Google APIs, see Adding Android SDK Components
2. Step 2 - Phone Drivers
   
   • Download and install the Motorola Mobile Phone USB Driver
     
   • At the time of this writing I could not find an easily downloadable HTC driver but the Installing HTC Incredible Android SDK Drivers instructions provided by Andrew Westberg work.
3. Step 3 - Setup Android Devices for Debugging
   
   • On the device, go to the home screen, press MENU, select Applications > Development, then check all three options
4. Step 4 - Setup MOTODEV Studio (a fully contained Eclipse plug-in) for Android
   
   • Download and install MOTODEV Studio for Android (might require account creation)
     
   • Start MOTODEV Studio for Android, create a new workspace
   • Select: "Use an existing SDK from the file system" and point MOTODEV Studio to the location where you installed the Android SDK

At this point your Android development environment is setup and ready for the obligatory Hello, World.

I have spent the month of June recovering from a lot of travel and catching up on work. Thus far it has been an outstanding summer filled with a lot of learning. We started a new project at work which is stretching my capabilities and providing excellent learning opportunities.

In addition to work I've spent the last six weeks in a Smartphone Application Development course. The course focused on developing applications for the Android Platform. The course was taught by Ted Selker who pushed us to come up with innovative project ideas. I had some of my own but polled my social graph for additional ideas.

The best ideas are below

Service Disabler

An application that is location aware turning off features depending on location. This would have practical use for the government as even government owned portable electronic devices have restrictions inside of limited areas. This idea could be extended to the consumer market to turn off specified features/notifications when at particular locations i.e. I am at/near my desk I don't need to be notified of Twitter mentions.

Bicycle cadence measurements

Bicycle cadence measurements. This measurement could be obtained by listening for the "swoosh" of a bicycle pedal using a Bluetooth headset or by calculating a virtual cadence using the accelerometer. In either case as a cyclist I am interested in this application because I presently have no option like it.

Photo Geo-tagging

A photo geotagging application. The application would communicate with your service of choice (Flickr, Picasa, etc.) and update previously uploaded photographs with a prior recorded geotagged location. The application would be smart enough to ignore photographs where it was not on at the time of the picture being taken. This would be useful for photographers who already carry additional devices to provide similar utility.

Grocery Food Item Locations

An application that provides the location of food items based on a specified grocery list. I.e. cereal can be found on aisle 3 and produce in this section of the store. This application would provide the details of where to go in the store to get all of the items on a list and provide suggestions for available coupons. To make this truly work would require the eventual buy in from multiple grocers as keeping store layout information up to date would be difficult.

Exposure Calculator

An exposure calculator for pinhole photography. Capturing light values and displaying flash calculations to photographers. This would be of value as photographers already carry additional devices to provide such calculations.

Advanced Phone Locker

Provide the ability to lock the phone with more than a simple pin or connect the dots unlock mechanism. This application would use multiple sensors to unlock the phone. It’d be interesting to allow for audible, location, gesture, and accelerometer based unlocking. A user could create a profile combining up to two unlocking mechanisms.

Some of these are more cute than useful. I ultimately chose to write the Service Disabler application though it morphed into Proximity Alerter.

My post What's in a Name should provide a general sense of who I am but if you are really interested read on.

My name is Andrew Steele. I am married, have two dogs and work for Sandia National Laboratories as a Programmer Analyst. Which is an overly complicated way of saying computer programmer or software engineer.

The internet is fully integrated into my daily activities. I am the epitome of a digital native. As a curious professional looking to improve I spend a lot of time participating and lurking on Stack Overflow. I get more out of my Twitter account than my Facebook account. I spend a lot of time reading about computers and technology.

I am an avid road cyclist, snowboarder, hiker, and UNM Basketball fan. Thankfully, living in the City of Albuquerque in the Land of Entrapment Enchantment (New Mexico) allows for plenty of opportunities to pursue these passions. During the summer I tend to spend enough time outdoors to cultivate a serious farmer's biker's tan.

I have been enamored with computers since I was a toddler. I became interested in programming when I figured out how to tweak the variables in the turn based artillery game Gorillas. A few years later with a friend I built my first web site which received a cool rating from Yahoo!. This happened because at the time our site was one of only a few that featured Doom 2 WADs. This was pretty awesome until my parents received a bill for the bandwidth (hard for a kid to explain in 1995). During high school and the early part of college I worked for America Online. When AOL lost its identity during the Time Warner merger and subsequent fallout from the dot-com bubble I took an internship with Sandia and have been there ever since.

After a four year hiatus I decided to return to school to earn another master's degree. With the support of my employer in the fall of 2009 I started the Master of Science in Software Engineering program at Carnegie Mellon Silicon Valley. The experience has been rewarding and I've enjoyed being a student again.

Since the weekend of May 14th I have been traveling relentlessly. At one point I was only in Albuquerque for 16 hours before leaving again and while I enjoying traveling being gone this much has been both hectic and tiring. My travel has been for school, pleasure, work, bicycling and a wedding.

My first stop was a student gathering at Carnegie Mellon Silicon Valley.
I spent the Friday before the gathering in San Francisco and was lucky enough to get a great rental deal on a brand new 2011 Ford Mustang. The car only had 62 miles on it when I picked it up and added a lot of fun to the weekend. The gathering’s theme was "Innovation and Creativity" and featured a panel on creativity, a Comedy Sportz performance, a presentation on Improvisation and Creativity from Patricia Madson and various other workshops. The sessions were a lot of fun, but the highlight of the gathering was the opportunity to interact with my fellow students in the flesh. We all met last August at orientation but meeting again was nice as virtually attending class and holding group meetings only takes you so far.

While at the gathering I received a Motorola Droid to use over the summer for a smartphone development course. I was happy to have the phone as I intended to use its features to assist with my next trip.

After returning from San Francisco I was in Albuquerque for three days before leaving for a conference in Long Island, New York. Having never visited New York City I decided to play tourist and leave a bit early for the conference. A friend of mine who lives in Bronxville allowed me to stay at his place. He gave me three pieces of advice before leaving me alone on a train into midtown Manhattan:

• Never screw up the city’s flow and never hesitate.
• If you don’t know just ask. People in New York are generally pretty nice.
• Don’t think about what you look like as no one is paying attention to you anyways

Armed with this advice I spent a few days taking in as much of the New York experience as I could as quickly as I could. By utilizing my Droid and BlackBerry to navigate the city I was able to get around pretty easily. In fact other than getting on the wrong subway train once I always knew where I was going. In addition to navigation I used Yelp with great success to get recommendations on good touristy and un-touristy restaurants.

The Droid also led to my coolest social networking experience to date. I took a picture of the arch in Washington Square Park and immediately published it to a Facebook album. Within moments the photo had received a comment from a friend who lived near Washington Square. We commented back and forth and were able to meet for lunch. None of this would have happened without the ability to instantly tap my social graph. By the time my co-workers arrived for the conference I was able to play tour guide taking them on a whirlwind tour of the city. I certainly did not see everything and would have liked to spend more time at particular sites but do feel like I got a taste of the Big Apple. In fact in the short time that I was there I was able to take in a Broadway show (American Idiot) and was even so lucky as to have my name drawn to attend a taping of The Late Show with David Letterman.

The vacation portion of my trip east was awesome and so was the conference. The National Laboratory Information Technology Summit (NLIT) is always great; the content is stellar and everyone there is focused on similar work which saves the usual conference pain pleasantries of trying to convey exactly what it is that my company does. At NLIT I gave two presentations Progressive Enhancement to the Rescue and Goal Directed Design Prevents Dancing Bearware. The session on Progressive Enhancement was lightly attended but I had a great turnout for Goal Driven Design. Both presentations netted some outstanding hallway conversations. I gained a lot from the presentations that I attended and look forward to next year’s conference in Colorado.

After returning from New York I spent only 16 hours in Albuquerque before heading to Durango, Colorado for the Iron Horse Bicycle Classic. Iron Horse is a race from Durango to Silverton over two mountain passes. It attracts 2,500 riders who attempt the trip on road bikes, beach cruisers and unicycles. The ride is hard, but a ton of fun. I did well in the ride but not as well as I would have liked. I think all of the traveling had started to catch up with me (that’s my excuse anyways).

At any rate, I have been back in Albuquerque since Sunday afternoon but am headed back to Durango Wednesday evening for a wedding Friday. I had considered attending Tech-Ed North America in New Orleans but am glad that after this weekend I am done traveling for a while.

My team is in the process of transitioning our development methodology. We have never had a formally documented development process. At best our practices have been most akin to waterfall and at worst haphazard. We have succeeded in developing this way because we have been in a perpetual maintenance mode, tested relentlessly, and new development has largely been completed by small groups of developers. Over the course of the last year we have been slowly transitioning to agile practices while incorporating the interaction design philosophies espoused by Alan Cooper. As we are beginning a major redevelopment effort we felt we were finally ready to take the next evolutionary step, adopting an agile methodology, Extreme Programming (XP) and more fully utilizing Cooper’s personas.

In Extreme Programming and Inmates I argue that the use of personas can assist XP teams in generating user stories. What I do not explain is that on the morning I set that post to publish my team was gathering to do exactly that. We spent all of last Thursday in a conference room. Our meeting began at 8:30 AM with a roughly outlined agenda.

In the weeks prior to the meeting we had worked to create a cast of characters representing our identified user personas. These personas were based on the demographics and unique goals of our intended user base. At the meetings outset our intent was to identify those personas which were positive and negative. After some deliberation we identified three positive personas and nine negative personas. Of the three positive personas one was clearly primary.

Having culled our cast of characters we began a traditional brainstorming session. This brainstorming session was not like others that we have had as our discussion and ideas were focused. Knowing who we were talking about allowed us to quickly generate a valuable mind map. After a morning in a conference room we decided to take a break for lunch.

Even after the successful morning I was nervous to return from lunch. While my team had responded well to the use of personas for brainstorming I feared their unfamiliarity with user stories and some lingering tentativeness toward personas would hamper our productivity. I had visions of us sitting around a table just staring at each other.

To my great pleasure I discovered that my fears were unfounded. The team adapted to creating user stories quite readily. We had the same experience that we had had in the morning in that the personas focused our discussion and allowed us to zero in on who a particular story was for. We turned on music and laughed our way through the remainder of the afternoon.

At our meetings conclusion we found that we had generated over a hundred user stories. Many more than we can complete in several iterations. I am happy to report that using personas in conjunction with story cards has thus far been a resounding success.

Story cards and use cases are both mechanisms for documenting user goals. Story cards are part of the agile software methodology Extreme Programming (XP). Use cases are part of the more formal Unified Process (UP) methodology. The two approaches share similarities but differ in their application. It is these differences that make one method more appropriate than the other depending on the type of project.

Story cards are user goals written in the form of two to three sentence stories on index cards. A story card contains enough information for the customer and developer to understand the story’s intent and estimate its implementation difficulty. In contrast, there are three use case “dressing” levels. A “briefly dressed” use case does not differ greatly from a story card in the amount of information documented. A “casually dressed” use case captures additional information but is not as detailed as a “fully dressed” use case-- a highly detailed document including pre/post conditions, alternative paths, and exception handling.

While story cards and briefly dressed use cases resemble each other in the amount of information documented, their function differs. Briefly dressed use cases are essentially placeholders for future fully dressed use cases. Fully dressed use cases are the final result of many customer and developer implementation conversations. While not every use case must be fully dressed before development begins, generally no development work towards implementing a particular use case begins until that use case is fully dressed. Conversely, story cards act as a conversation starter allowing programmers to begin development while still engaging the customer for implementation details. Establishment of user acceptance criteria for the story cards occurs during these conversations. From these criteria developers are able to create automated user acceptance tests. Automated user acceptance tests are a code form of the formal written documentation in a fully dressed use case.

XP story cards enable concurrent conversations during development, while UP use cases enable preemptive conversations prior to development. The difference between preemptive or concurrent conversations goes to the heart of the differences between agile and formal development methodologies. Agile methodologies and XP in particular attempt to engage the customer throughout a project’s development lifecycle. Story cards are a means to continuously engage the customer while developing a product. Formal methodologies like UP primarily focus on detailed documentation before implementation work begins. A fully dressed use case attempts to detail all possible usage outcomes creating a blueprint for a developer to work from.

Whether story cards or use cases are more appropriate for a particular project depends on whether an agile or formal methodology is most appropriate for the project. Projects that are life critical, require a very high degree of precision, or the development team is highly distributed will benefit from the use of fully dressed use cases and a formal methodology. Projects that allow for repetitive iterations, have a low fault tolerance, and lend themselves to close developer/stakeholder collaboration will benefit from the use of story cards and an agile methodology.

Much like agile and formal methodologies, story cards and use cases have advantages based on the type of project under development. Developers should be aware that while they may prefer one methodology over another, project requirements may determine which methodology is more appropriate.

In The Inmates are Running the Asylum Alan Cooper makes a compelling argument for interaction design which Cooper contends requires thorough exploration and documentation before any programming begins. Kent Beck in Extreme Programming Explained describes that the methodology uses a pull development model which specifies stories in detail immediately before implementation. When juxtaposed these two assertions seem contrary but upon reflection can be made complementary.

At their core agile methodologies like Extreme Programming (XP) emphasize creating good products, not just good programs. This distinction while subtle is important. By embracing the external input of customers, users, managers, and stakeholders XP practitioners acknowledge that a product is more than just a program comprised of features. Cooper similarly believes that a successful product is not just a feature compilation arguing that achieved goals, not features, compel users. Cooper’s advocacy for goal driven design leads to his suggestion of utilizing personas-- hypothetical archetypes of actual users. In XP projects developers can use personas as stand-ins for onsite customers. Personas allow XP teams to vet features through the lens of accomplishing a persona’s goals.

XP developers document external input in the form of user stories. An XP user story is a mechanism which estimates and describes units of customer-visible functionality. In his Agile 2008 Conference keynote, Cooper contends that creating user stories is arguably an agile programmers’ weakest skill and is an interaction designers’ strongest one. Cooper goes on to conclude that while agile methodologies like XP bring outsiders into the software construction process it is interaction design that makes the contributions of outsiders effective and useful. Simply stated, XP puts developers and stakeholders in direct collaboration while Cooper advocates placing an interaction designer in-between stakeholders and developers. Utilizing an interaction designer in conjunction with an XP team seems reasonable; allowing developers to focus on technical problems and interaction designers to focus on human factors. XP programmers can take Cooper’s advice by investing time to fully frame user stories, which ultimately speeds up programming and reduces costs.

Both Beck and Cooper are advocates of an iterative process. In Chapter 3: Wasting Money Cooper warns against using iterative product delivery as a means of product refinement. Later he declares that “getting to the right product is always a matter of iterating” (Cooper p240). What Cooper does not stress in Inmates but does so in his keynote at the Agile 2008 Conference is where the iterative process should take place. Cooper believes it is folly to iterate where customers are subject to abuse by those iterations and instead urges iteration during the design and engineering phases. While Beck urges that in an XP project the product should be in a releasable state at an iteration’s conclusion, he does not suggest that it must be released.

Incorporating Cooper's goal driven design with Beck's XP practices improves software product development. Beck acknowledges that there is no litmus test for certifying a development team extreme and Cooper is ultimately a proponent for the tenets of agile methodologies. While at first glance Beck and Cooper may seem to be in conflict regarding iterative software development, in reality they both offer valuable suggestions which should be leveraged. It is therefore up to an agile development team to incorporate the suggestions of each practice in a sustainable and effective way.

I have been kicking around the idea of starting a blog for a couple of years, but with this post am jumping in feet first. One of the reasons it has taken me so long to begin blogging is I could never commit to a name. Generally, the names I came up with were too restrictive and locked me into too specific a topic. I did not realize the problem with one name until after I had registered the domain and realized it was a dirty word in Dutch. To have reaped the benefits of blogging earlier I should have damned the naming torpedoes and proceeded at full speed ahead, but am glad I did not because I am exceedingly pleased with the name I finally selected: Steele Bit.

Steele Bit covers everything I want my blog to be about. I imagine that some posts are going to be personal in nature, including my last name covers that. That said bit is the more interesting part of the name.

The word bit is fun because it has a long list of definitions. I use it here primarily because the relation bits have to technology. I intend to focus my writing on programming and related topics. Further, as a card carrying geek I will not be able to keep myself from posting on new technology. Finally, the word bit invokes the sense of something small which is to say I do not intend to be unnecessarily verbose in my posts.

In summary Steele Bit will primarily be a blog about programming, a smattering of technology, and with a bit (see what I did there) of personal anecdotes thrown in for good measure.