Q: Why do I need Yammer?

A:  It’s simple… I want access to my fellow software engineers and technologists that live on the other side of boundaries that get created around other Departments, Products, Business Units, and Acquisitions.

True story. I had to quickly come up to speed on a technology I had not been introduced to previously.  I took the normal approach of aggressively searching online to find examples, white papers, blogs, anything to help.  Time was running out, and while I had learned a lot in a short amount of time, I wanted a little help connecting all of the dots and selecting what I needed to focus on to complete my task in a timely manner.  I needed 15 minutes with an expert in this technology to guide me down the right path, because I didn’t have time to go down the wrong one.

I jumped on Yammer and put out a call for help.  A development manager responded with the name of a person who he knew to be experienced with this technology.  He introduced us over email and a few minutes later, I was getting exactly what I needed.

We’ve all seen too many blogs and articles along the lines of “10 reasons you’re organization isn’t ready for Agile”.  I believe that buried under all of those ‘reasons’ are fundamental problems that will keep your organization from reaching any high level of productivity.  Here it is, the real top 10 list:

1. you’re not hiring the right people

2. you’re not hiring the right people

3. you’re not hiring the right people

4. you’re not hiring the right people

5. you’re not hiring the right people

6. you’re not hiring the right people

7. you’re not hiring the right people

8. you’re not hiring the right people

9. you’re not hiring the right people

10. you’re not hiring the right people

Hopefully this comprehensive list will help you and your organization.  Cheers.

For pure curiosity reasons, I wanted to know the ratio of lines of code to unit tests.  I’m writing all production code in Java and tests in Groovy.

LOC

Finding the lines of code:    grep -v -r –include=”*.java” “^[[:space]]*$” * | wc -l

Number of Tests

grep -r –include=”*Test.groovy” “@Test” * | wc -l

Results

LOC: 706, Tests: 82

This yields a ratio of:   8.6 to 1

1. Skip Inbox

When filtering incoming mail, if it’s not something you need to read as soon as you have time, just tell it to skip the inbox.  This will cause the email to be immediately archived, but keeps it marked as unread.  This works especially well for many of the automated emails you receive from companies and websites (like Facebook) and gets you one step closer to Inbox Zero.

2. Hide Read Lables

Go into Settings and then to Labs.  Find “Hide Read Labels”, and enable it.  This causes labels that don’t contain any unread email to be hidden from view.  It keeps your screen a little less cluttered and allows you to focus on new emails.  Your labels are still very easy to reach, just start typing the label name in the search bar and it will pop up as one of the auto-fill options.

More to come as i figure them out!

I’ve actually been coding a lot at work recently. The system I’m building at the low end interacts with a Web Service to retrieve data. At the high end, it reports this data in custom forms and at configurable intervals. I’m building a few different API layers in between. A small, convenience API that interacts directly with the Web Service to simplify gathering of data. On top of that, I have several more wrapper-style APIs that allow the developer to work with the generic data types as wrapper objects for what they really represent. On top of those is the framework for forming and sending off the data to another system.

In this situation, I knew what the system must do, but not the exact details of how it would work at the lower levels. I did enough work on a POC interaction with the Web Service to know that the basic direction I wanted to go was possible. At first I took straight to developing the lowest level API, as that’s where I had my most detailed requirements. From the knowledge I gained doing the POC, I had enough to start there. However, in the end this hurt more than it helped.

After TDDing my way through several of the requirements I had of the low level API, I found myself in a sticky situation.
1. Too many tests tied too closely to implementation
2. I felt like I was progressing a little slowly, having to stop and think too long about what needed done next
3. I ended up having to heavily refactor about 2-days worth of code because the tests I came up with, did not reflect the true needs of the system

Luckily at that point, I realized right away that my lack of higher-level tests were allowing me to steer the system off path. I needed these higher level tests to drive the requirements for the behavior of the lower level API. So, I started fresh, writing a single acceptance level test that defined a small feature of the system. I continued to work my way down writing more tests until I couldn’t write a smaller more precise test without controlling the implementation details. That was my cue to start coding, and get all those tests I had written to pass.

The results..
1. Just enough code to meet the requirements. No more, no less.
2. Fewer tests tied directly to implementation details
3. A thin, vertical slice of functionality

This past Friday (the 16th), I did a brown bag presentation on reducing feedback cycles on software development projects. Slides here: http://bit.ly/bORrkW. Unfortunately, the slides contain only talking points.. the real value came from the discussion. Also.. while we did record the audio, it contained some discussion specific to internal projects/processes that I’m not going to share.

First of all, I want to mention that a lot of the conversation went back to the Cost of Change curve. Take my code compilation example. Finding a compilation error in real-time will (theoretically) make the cost of fixing the error cheaper than finding it after a day of coding. The example was that using an IDE that performed real-time compilation was a much shorter feedback cycle than going to a command prompt and running your build manually. The other notable example that builds on the Cost of Change Curve was scheduled code reviews (montly/weekly/etc) vs. pair programming.

One of the final feedback cycles I presented was that of the completeness of an individual feature of the system. We talked about the Cost of Change Curve here as well, but most of the discussion focused on what other things we may get by reducing this feedback cycle.

I began by talking about how a single feature progresses through the Waterfall process. Pointing out that you won’t get feedback on the completeness of a single feature until you’ve reached the Validation phase where your QA has had a chance to test the feature. This gives us a feedback cycle of the length of time between when dev initially started on this feature and when it was tested during the Validation phase. How long are we talking here? Months probably.

So, now it’s time to ask how one would reduce that feedback cycle. In order to do that, we need to bring the validation phase closer to the point at which development began on this feature. Since the traditional Waterfall approach moves the entire software system from phase to phase, it’s not possible without re-defining the process.

We then took a look at this feedback cycle in Scrum. Sometime after the start of a sprint, you start development on one of the user stories you’ve selected (aka feature). Considering the goal is to deliver this feature at the end of the sprint, at some point you’re going to validate this feature, completing the feedback cycle. So, here, the feedback cycle is at most 1 sprint.

We continued the discussion down the path of what things we get by reducing the feedback cycle in this way. The most profound impact is on our feature estimation because the feedback cycle on feature estimation accuracy is directly tied to the feedback cycle on feature completeness. Now that we’re attempting to complete individual features within a single sprint, we’ll also get feedback on our estimation of that feature within the same sprint.

We spent some time talking about what you can do with this information. Essentially it means that you can better estimate the remaining features of the system. This in turn gives you a more accurate project schedule, which in turn allows you to confidently discuss project timeline and budget predictions with stakeholders and customers. Also, when someone asks what features won’t make the deadline, you’ll be able to answer that question and others like it.

Hopefully that’s enough text here for you to get a feel of the presentation. Feedback cycles is a broad topic. In this presentation I hit some things at a very high level and went a little more detailed on others. My goal was simply to communicate that reducing any feedback cycle is beneficial (some to a much smaller degree than others). I also needed to address a wide audience: devs, qa, project managers, etc. While I did get some great feedback from a few of the attendees, I do remember seeing a few faces that looked lost. Maybe I’ll follow up with those people.

Joda Time is a Date/Time API proposed for Java SE 7. Below, I have a Groovy script that uses the 1.6 Joda Time library to find the difference between two dates.

 import org.joda.time.*
    ...
 def i = new Interval(startDate.getTime(),endDate.getTime())
 def p = i.toPeriod()

 println "Time Difference: " + p.getSeconds() + "." + p.getMillis() + " Seconds"

In addition to Seconds and Milliseconds, you can get the number of Days, Hours, Minutes, Months, Weeks, and Years.

This one eluded me for way too long considering how straight-forward it is.  So, in an effort to help others who may have the same question, I thought I’d write it down..

Problem: For a Basic MSI Project in InstallShield 2009, I need to pass in 1 or more custom command-line arguments to use during installation/un-installation/etc.

Step 1 – Accessing your custom command-line arguments

First, accessing these values are as easy as accessing other variables in InstallShield.  All you need to do is use the format [MYARGUMENTNAME].  So, for example, if you want to use one of the arguments when invoking an executable from a custom action, it may look like this image below.  My custom action is invoking an executable called myapp.exe and I am accessing a custom command line argument named FILENAME to use as part of the invocation of my executable.

Step 2 – Passing in your custom command-line arguments

It’s really this simple.. each argument needs to be preceeded by a /v and wrapped in quotes.  Continuing the example above, here is how I pass in my custom command line argument named FILENAME:

     setup.exe /v"FILENAME=\"myfile.txt\""

This would result in my custom action invoking my executable as follows:   myapp.exe -f myfile.txt

To be clear on multiple custom command-line arguments, the following example adds a second argument to my example above:

     setup.exe /v"FILENAME=\"myfile.txt\"" /vSECONDARGUMENT=\"value2\""

I’ve had my new phone for a week.. a Motorola Droid. Without including any games, here are my top 10 favorite apps so far.  I’m curious how this list will change over the coming months.

1. Google Maps Navigation – This is the free app from Google that transforms your phone into a mobile GPS Navigation unit.

2. Seesmic – Twitter client

3. GMail – Do i have to spell it out?

4. Pandora – Music, like last.fm, but much better.

5. Facebook for Android

6. Flashlight – I have the version that just turns your screen bright white.. not the version that uses the phone’s camera’s LED flash bulbs.

7. Calendar – Syncs to your Google calendar.

8. FourSquare – Location based social application, allowing you to ‘check-in’ at venues.

9. WorldTour – Retrieves images to be used as your wallpaper from all over the world.  Can be set up to randomly change every 30 minutes, or choose a static site.

10. Yammer – A client for Yammer (much like Twitter except for internal corporate use).

A little while back, I decided I would try and come up with some fun things to try and accomplish in Groovy and blog about them. The primary goal being to learn more about the Groovy language.

The adventure I chose for this post was to somehow make the use of a Factory transparent by allowing what appeared to be the instantiation of an Interface or Abstract Class. I looked for ways to override the new keyword so that when new was used with an Interface or Abstract Class, it would call a factory behind the scenes. I figured out that I could not override the new keyword, but ended up finding this example of overriding the getAt method as a way of constructing an object. I thought this was very innovative and it be best to use this approach for the task at hand.

In this code segment, you can see I have an interface Animal, two implementations, Dog and Cat, along with a factory AnimalFactory. Now, the factory here is not very useful. It simply calls the first constructor of the Class passed in as a parameter to its only method, create(). However, the focus in this post is how we can transparently use a factory, not the logic used by the factory itself.

    interface Animal {
     def talk();
    }

    class Dog implements Animal {
     def talk() {"bark"}
    }

    class Cat implements Animal {
     def talk() {"meow"}
    }

    class AnimalFactory {
     static Object create(Class c) {
      c.getConstructors()[0].newInstance()
     }
    }

This following segment is where the magic happens. First, I’m creating a static method on all classes called registerFactory() that allows us to register a factory with an Interface or Abstract class. The second thing i’m doing is what you saw in the example I linked to above by Alex Tkachman, where we override the static getAt method, allowing us to use square brackets for object instantiation.

    Class.metaClass.static.registerFactory = { clazz ->
     delegate.metaClass.static.getClassFactory = { -> clazz}
    }
    Class.metaClass.static.getAt = { c -> delegate.classFactory.create(c)}

Now, you can see an example of using the registerFactory() method and instantiating an object through the getAt method on an interface.

    Animal.registerFactory(AnimalFactory)

    def c = Animal[Cat]
    c.talk()

Finally, the output from this previous segment is shown below.

    Result: meow

I thought about taking this post even further and making the factory more useful by trying out some dynamic constructor invocation based on the arguments passed in through the square brackets, but I think I’ll save that for later. For now, I hope you can see past my useless factory implementation.