On Getting Better

Big Visible Charts

2012-01-23T18:45:00.002-05:00

Nor do people light a lamp and put it under a basket, but

on a stand, and it gives light to all the house. - Mathew 5:15

I've been trying to lose weight for years and carefully monitored my weight every morning. In 2000 I was 180 pounds and I hit a peak of 215 this year. I've tried nearly everything I could think of other than what works in my professional life. So I decided to add hard work and big visible charts to my weight loss regimen. Hard work came in the shape of a dog. Big visible charts came in the shape of recording, analyzing, and changing behavior and seeing the results of that change.

Some wise guy once said, "If you can't measure it, you can't fix it," or something like that. Measurement alone cannot change a situation (outside quantum mechanics); action affects a situation. Measuring, tracking, and analyzing data can provide insight into cause and effect relationships. Making that data visible to the problem solvers and stakeholders can provide motivation to taking action necessary to affect change.

There are many measurements available to software development teams. At the developer level there are lines of code, commits per sprint, and unit tests. The team can look at static code analysis, automated test coverage, broken build counts, and build times. The business side can gather data on defect rates, customer contentment, lost sales due to feature gaps, and profitability. This list is by no means comprehensive, but gives some ideas of common measurements.

After the data is collected it must also be analyzed. Analysis is non-trivial as some things appear to have obvious relationships and analysis show them to be unrelated. Other times relationships are subtle and require looking for non-obvious connections. The goal of analysis is to point to practices or product which will provide improvement.

Making the analysis available, indeed presenting the analysis to the team, will encourage change by generating the force required to create action. Even though measurement and analysis appeared to be action they are only tools to ensure the force generating the action is applied in the correct direction. Visibility is the key to driving change. When measurement of work is easily available and visible each part of the organization can be held accountable for providing their value. Behavior which benefits the organization can be rewarded by reviewing those same big visible charts for results of action.

Only performing measurements on my weight had no effect on my weight gain. In fact, I could plainly see that it was going in the wrong direction without taking concrete action. I knew why my weight was going in the wrong direction, I kept eating and didn't exercise enough. What finally made it possible to make headway in addressing the issue was keeping track, analyzing the data, and making a nice visible chart of my weight over time. It became much easier to hold myself accountable for my actions when it came to eating. The visible charts help me avoid dessert and make me willing to put in the occasional extra mile.

Google Maps API on Android

2011-12-09T18:17:00.001-05:00

At the GR Mobile Dev group this month there was discussion on the topic of using mapping capabilities on the Android and iOS platforms. This document describes the steps necessary to setup an Android application, acquire a API key to access map tiles, and implement a simple mapping application. Below is the basic boilerplate to getting started with the Google Maps API. This doesn't look at any geo-location or overlays, but will get you to the point of being able to start exploring these topics.

Requirements

SDK
The Google Maps API is not part of the core Android SDK, however access to it is available through the Android tool chain. Running the “Android SDK Manager” and verify that the “SDK Platform” and “Google APIs by Google Inc” for the API version you are interested in developing an application are installed (recommend API version 7 [2.1] based on current usage statistics).

AVD (Emulator)
Once the SDK Platform and Google APIs are installed we will need to create an AVD which will support the Google Maps API. The target will need to be set to “Google APIs (Google Inc.) - API Level #” instead of “Android #.# - API Level #” for the Google APIs support. This will create an AVD which includes the normal Android and Google APIs.

Basic Application

Create a basic Android application, except on the step where you select the “Build Target” choose the “Google APIs” for the target API level instead of “Android #.#.” Otherwise the application creation process is the same as the any other project. In the instance where you are working on an already existing project, you can update the project by going to the properties for the project “Android” options and select “Google APIs” for the existing target API level.

Include Map

Manifest
The manifest has two updates required to enable using the Google Maps API. The application will need to know that it should use the Google Maps library. In addition the INTERNET permission is required to load the map tiles.

AndroidManifest.xml

    <manifest ...>
        ...
        <uses-sdk ...>
        <uses-permission android:name="android.permission.INTERNET">
        <application ...>
            <uses-library android:name="com.google.android.maps">
            <activity ...>
        </application>
    </manifest>

Map API Key
Google requires that an application has a map API key to load the map tiles from their servers. This map key is based on the signing key used to sign the application. Under development conditions there is a debug key used to sign the application by the development environment which can be found in ~/.android/debug.keystore, though you will also want to use the release signing key when submitting to the Android Market.

To generate the map API key you will need to use the keytool application which ships with your Java installation. On windows you will find it in the bin directory of your java installation, on Mac OS X or Linux it will probably already be in your path.

Terminal

    % keytool -list -keystore ~/.android/debug.keystore
    ... 
    Certificate fingerprint (MD5): 94:1E:43:49:87:73:BB:E6:A6:88:D7:20:F1:8E:B5:98

Browse to the Map API Key Signup page. Copy the MD5 into the form and submit the form. This will generate the map key for your the debug.keystore. Follow the same steps after you generate a release key for submitting to the Android Market.

Browser - http://code.google.com/android/maps-api-signup.html

    Your key is:
        0UUnupTxbpdGofOV-UQi2jQHV0z6xwGh_kDu3NA

It is good to store the map API key as a value in a strings file to make it easy to change out in case you need to generate a new debug map key for multiple developers working on the project. This file can then be set within the version control system as ignored. Also, a release key can be added and easily be switched between release and production by updating the map_key between @string/map_key_debug and @string/map_key_release.

res/values/map_keys.xml

    <resources>
        <string name="map_key_debug">0UUnupTxbpdGofOV-UQi2jQHV0z6xwGh_kDu3NA</string>
        <string name="map_key_release">0UUnupTxbpdHBqSgZFLLqTmFGezrtAJBEUCUWgw</string>
        <string name="map_key">@string/map_key_debug</string>
    </resources>

Application

Layout
The layout can now have the map view included. In this example we are using the full screen to display the map view.

res/layout/main.xml

    <linearlayout
        xmlns:android="http://schemas.android.com/apk/res/android"
        android:layout_height="fill_parent"
        android:layout_width="fill_parent"
        android:orientation="vertical">
        <com.google.android.maps.mapview
            android:id="@+id/map"
            android:apikey="@string/map_key"
            android:layout_height="fill_parent"
            android:layout_width="fill_parent">
        </com.google.android.maps.mapview>
    </linearlayout>

Activity
Maps require that you use a MapActivity. The MapActivity is an abstract class that requires the implementation of the isRouteDisplayed method, though with a simple example this method can be left as a stub returning false. The setupMapView method is setting the map to be clickable and enabling the built in zoom controls.

src/...package.../MainActivity.java

    package ...package...;

    import android.os.Bundle;
    import com.google.android.maps.MapActivity;
    import com.google.android.maps.MapView;

    public class MainActivity
        extends MapActivity {
        @Override
        public void onCreate(Bundle savedInstanceState) {
            super.onCreate(savedInstanceState);
            setContentView(R.layout.main);
            setupMapView();
        }

        private void setupMapView() {
            MapView map = (MapView) findViewById(R.id.map);
            map.setBuiltInZoomControls(true);
            map.setClickable(true);
        }

        @Override
        protected boolean isRouteDisplayed() {
            return false;
        }
    }

Resources

http://developer.android.com/resources/dashboard/platform-versions.html – Usage Statistics
http://developer.android.com/guide/publishing/app-signing.html – Application Signing
http://code.google.com/android/maps-api-signup.html – Map API Key Signup
https://github.com/crazydays/AndroidGoogleMap - GitHub Project

Android, Ant, Emma, Robotium

2011-09-13T21:36:00.002-04:00

We started a new android project at work today. Since there isn't any legacy development we wanted to get it started right, with a continuous integration environment so we wanted to automate the build and testing as an ant task. I was unable to find anything on the android developer site outlining the process to set this up, so I turned to the internet. Nothing on the first couple pages of google results had a complete recipe so I figured I ought to share the solution we used.

Requirements

Eclipse
Android SDK
ADT
Ant
Robotium jar

Create Android Application

File -> New -> Other...
Open Android -> Select Android Project -> Click Next
Set Project name, Android <Version>, Package name (The rest should be filled out with reasonable defaults)
Click Finish

Add Ant Script

Open terminal to project directory

% $ANDROID_HOME/tools/android update project --path .
Updated local.properties
Added file ./build.xml
Updated file ./proguard.cfg

Create Android Test Application

File -> New -> Other...
Open Android -> Select Android Test Project -> Click Next
Set An existing Android project (The rest should be filled in with reasonable defaults)

Add Ant Script

Open terminal to test project directory

% $ANDROID_HOME/android update test-project -m ../BigMeanRobot --path .
Resolved location of main project to: /Users/daya/src/BigMeanRobot/BigMeanRobot
Updated default.properties
Updated local.properties
Added file ./build.xml
Updated file ./proguard.cfg
Updated build.properties

Test Coverage Report

Open terminal to test project directory

% ant coverage
...compile/install project...
...compile/install test project...
coverage:
        Running tests...
...cleanup...

Open <test project root>/coverage/coverage.html

Add Robotium

Download robotium-solo-<version>.jar to <test project root>/libs
Add to test project
File -> Properties
Select Java Build Path -> Libraries -> Click Add Jar...
Open Big Mean Robot -> libs
Select robotium-solo-<version>.jar -> Click OK
Click OK

Create Robotium Test

Fail Fast to Restart Quicker

2011-09-07T21:28:00.000-04:00

Theterm fail fast in software has its origins in fault tolerance. Theidea is that something has gone awry and the safest way to handle thecondition is to shut down the whole system to prevent further damage. It is an acceptable trade off since the damage which could be doneis worse than the loss of the service the program is providing. Theidea is also commonly found in entrepreneur circles where the damagecaused is the waste of capital. I am sure there are a number ofother areas where fail fast can be applied beneficially, but sinceI'm a software developer I'd like to show some benefits of fail fastin software development.

Oneof the applications I have been working on recently has a littleannoying UI bug. The top element of a spinner component is nothighlighted properly to indicate it is the prompt rather than aselectable option. I decided I would spend a few minutes trying totackle the bug. I started by verifying that I had an up to datesource tree without any uncommitted changes. The cause of the UI bugwas determined to be how the adapter was being built giving all ofthe options an offset of “+1.” Figuring that was silly I justremoved the first element, removed all of the “-1,” and set thefirst item as the prompt. The component was visually correct afterthis and I was about to commit the changes. However, one last runthrough application showed another bug. I came to the realizationthat the UI bug I was fixing was a work around to another bugexhibited at another level. At that point I decided I simply did nothave time to run down that rabbit hole for such a trivial bug. Arevert command to the source control and I was back onto anothertask.

Onthe same project I was adding two features to the application. Feature one went in really smoothly, so much so I had forgotten tocommit my changes prior to moving on to the next story. The secondstory was a little bit hairy. I had a bad false start and was aboutto revert the changes when I found my problem of not committing theprior story's changes. Instead of being able to revert I had to workthrough my bad false start to complete the feature. I had tocarefully evaluate all the code to make sure I wasn't leaving badbits in and make sure that the feature was successfully implemented. By not being able to fail fast I probably doubled the time requiredto implement the second feature.

Theability to fail fast allows a developer to quickly try out ideas forviability before committing to them. Some solutions appear to be agood idea at the start, but over the course of implementationfailings can be revealed. Following the course laid out by a badstart can cause design flaws or overly complex code to handleoriginally unforeseen issues. The complex code can be refactored,but it is often easier and cleaner to start from scratch with abetter understanding than to modify the existing bad start. Failingfast is another tool in a developer's skill set which will allowcleaner and better code.

Resources

http://c2.com/cgi/wiki?FailFast

Gracious Judgments

2011-07-28T20:56:00.000-04:00

Within Temptation has a song called Destroyed (http://www.youtube.com/watch?v=KA_KdRhG9OI) with the refrain, “It is so easy to destroy and condemn the ones you do not understand.” Who knew that a symphonic metal band knew so much about working with legacy code? Okey, they are probably not singing about doing maintenance work on a software system without test cases, documentation, design patterns, and looks like a mess of spaghetti.

Anyone who has worked on a legacy system knows how easy it is to condemn someone else's work. When in that position myself I have often found it is easier to destroy and condemn by rewriting the legacy code rather than spend the time to understand to code. Rewriting leads to obliterating the original implementation which may have special cases littered throughout and on the next release customers depending on those special cases will start calling support. And that doesn't make anyone happy.

Working on a code base written by another developer is an intimidating task. Every developer is going to work out solutions in a different fashion, applying a different pattern or algorithm to the problem. Wrapping your mind around the original developer's thought pattern is challenging and often frustrating, especially when the original developer's background is very different from your own. Failing to understand the intent of the original developer can lead to belittling the code or writer, especially if they are not around to defend their work. Most bosses or customers are not interested in who created a mess, they want to have product shipped.

Destroying or condemning is not productive or conducive to shipping product and having happy customers. It is a developer's job to write the software and ship. The original developer already has a leg up on you since he has shipped something. So he is obviously not completely incompetent. Granted you are performing some sort of maintenance (bug fixing or feature enhancement), but that doesn't take away from his accomplishment. Judging or condemning the prior work does not add business value. Perhaps it is you or your point of view which needs adjusting, not the existing code or its developer.

There are many reasons why the original code is difficult to understand completely unrelated to the original developer's competence. The original developer had a different set of circumstances under which they were writing. Their personal style could be completely different or the styles they have picked up over time could be foreign to you. Many languages and toolkits have styles and patterns which are unique to them and you may unfamiliar with them. A hardware engineer may be excellent at their job of circuit board design, but unfamiliar with software engineering practices.

A better outlet is to work towards understanding the existing code using various techniques. Searching out the original developer and pairing with them if they are still available is a great way to become familiar with difficult code. Reviewing the original artifacts created during the development will give a high level understanding of the product, as it actually using the product itself. Writing unit test to stimulate particularly difficult segments of code can quickly reveal their purpose and leave an executable documentation of features. As you learn the purpose of particular portions of the code make sure to update identifiers to reveal their purpose for the next developer who will be working in this area.

Let me challenge you to be gracious in your judgment of existing code bases. There is value in the code otherwise you would not be maintaining it. The original developer was neither malicious nor out to make your life difficult. Assuming the worst intention or capability of the original developer does not improve the situation. Your boss and customer do not want to hear excuses, they want a time frame and the best possible value. Working with unfamiliar or difficult code is an opportunity to be explore new patterns, expand your repertoire, and become a better developer.

References

http://www.youtube.com/watch?v=KA_KdRhG9OI

Learning Agile

2011-07-18T06:22:00.001-04:00

During my search for a new job over the last couple months I wrote this essay for one of the positions I submitted an application. The position did not pan out due to some classic interview blunders, however, it seems like a waste to let this essay go otherwise unread. It covers some of the highlights of a team I participated on for several years transformation to several agile practices.

My manager had a great interest in various development theories. He would spend hours mapping out ideas while trying to wrap his head around the latest methodology he had read about. When he began to introduce agile practices to our team I was skeptical. I tended towards a conservative approach to my development, preferring tools and methods which have a proven track record or at least the status quo until value can be shown. A poor tool or method could yield many times the initial effort to replace or even discontinue. Introducing what amounted to overhead in our near constant fire fighting stance seemed like it would only slow down the team.

Stand up meetings were our first foray into agile practices. The manager sent us a couple articles to review on stand up meetings and told us a story about pigs and chickens. What was supposed to be a quick ten minute daily meeting quickly ballooned to thirty minutes or more. Minutiae of each team member's work would be discussed at length and it was rarely pertinent to more than a single member. For quite a while our stand ups amounted micro management voyeurism. Improvement occurred as the team started feeling empowered (through additional agile practices) and holding each other accountable to follow standard stand up procedures. Stand ups became a useful tool to increase transparency throughout the team and allowed members to assist each other on blocking issues. Despite our early problems we were able to bring value to the team by persisting.

As a team we had some false starts with test driven development. Our initial attempts still haunt us today. Large, fragile, and poorly conceived tests which were written after the production code usually testing only success paths and took minutes to fire up and execute. The code which was covered by these tests became rigid and the supposed benefits were not realized. Unit testing waxed and waned at the developer's whim since there was little accountability. Occasionally one of the team members would add a new tool to our belt which would get everyone excited. Database fixtures allowed us stop depending on a fragile example database when testing. The first GLSEC the team attended together was when we really turned the corner and made TDD useful for us. A handful of us attended a session on mock frameworks which opened our eyes to isolating our tests. Another session on clean code helped us practically apply TDD by showing how writing the test first was supposed to guide development. With these lessons the team was able to truly begin TDD and reap the benefits. We added a code coverage report which we then began reviewing excitedly during our sprint review meetings. In addition when a new team member begins we spent a large portion of our time teaching this skill.

At the time of the same GLSEC we were working with month long iterations. Our planning meetings took several days time to complete between writing stories, planning poker, and finally assembling stories into the iteration plan. The overhead seemed too large to even entertain the idea of shorter iterations and developing a complete feature took about that long anyways. At GLSEC a couple of presenters from Menlo sat with our team during lunch. The whole meal we discussed some of the topics we had heard that day and the progressions of our agile transformation. One of the Menlo women continually challenged us during the meal to consider week long iterations and see if things changed for the better. Uncertain there would be any improvement we decided to give it a try. Just as promised improvements in estimation, transparency, and flow occurred. Our epic stories were forced to be broken down into much smaller stories to fit within a week's time and we wound up with more spike oriented stories. We were able to more accurately judge the rate we would deliver features, produce usable features earlier, and trim feature sets in accordance to delivery time. At the next year's GLSEC I was delighted to find the same woman from Menlo and thank her for her suggestion and told her of our success with single week iterations.

In retrospect our manager did a great job in leading the team to pick up a number agile practices. Rather than forcefully push immediate compliance with the defined agile practices he sought team buy in and to empowered team members to direct our implementation. Despite my concerns I earnestly attempted to do my part to follow through in the implementation of various agile practices. I was pleasantly surprised when the practices my manager introduced helped improve our team. After the manager left the company the team continued the agile practices which he had started and we have extended our toolbox to include other practices. Seeing the success of many of the agile practices I am more willing to seek out new ideas which will help deliver better software quickly to the customer.

Agile and Bus Number

2011-06-22T14:53:00.000-04:00

I announced to my boss that I would be hit by a bus in two weeks. After my tragic encounter only two development team members will remain with more than a year of experience with the products we have developed, a developer and QA guy. With 9 years of experience at the company I have accumulated a great deal of knowledge of the product. The inevitable question, “What does he know and how can we get him to share that knowledge in two weeks,” was posed. In formulating an answer to this question I quickly realized the areas which I would spend the most amount of time documenting and training would be things done prior to adoption of a number of agile practices.

What Hurt

Silos

As a fairly small development team we had some small silos of expertise. Projects were often tackled by a single developer from start to finish. The developer would set the design, implement, and release with little review. And when defects or change requests would come in it would be passed back the original developer. Occasionally a second developer might try to provide some insight into one of the steps, but most of the time the development process would be worked on by a single developer.

Code Review

Effective code reviews are hard to actually implement. And we were no exception. On the rare occasion that we would perform a code review it would be over a small percentage of the code. Suggested changes were rarely implemented because the feature was working and there was little to no incentive to actually change the code. The design had been settled and changing it would introduce additional cost in development and risk.

What Helped

Collective Code Ownership

Breaking down the silos was not a major hurdle in our agile transformation by applying the concept of collective code ownership. Our story writing and planning process quickly brought the entire team in to advise on the design of features. We tried to keep implementation details out of the stories, but by having the entire team available ideas would be tossed around. Members would suggest code from their silos to encourage component reuse, permission given implicitly to modify to their own needs. Rather than waiting for another developer to implement a required component or reinventing the wheel a developer felt free to modify any piece of code.

Pair Programming

Beyond just granting permission to modify the code, pair programming allowed developers to actually work together in developing a feature. Short of a Vulcan mind meld, pair programming is the best way to ensure multiple team members fully understand the design and implementation. While the code is being developed the code is under constant review, so improvements actually happen instead of being noted as suggestions and ignored.

References