I Am Not Myself


Category Archives: Commentary

Why Most Solutions to Gilded Rose Miss The Bigger Picture


A couple years ago, I had the pleasure to work with one of the best teams I have ever and probably will ever get to work with again. There was a certain amount of magic we had over the span of a few months that I will probably be chasing the rest of my professional life. I still have links to the members of that team on my blog titled “Team Awesome”, even though I have long sense moved on and so have many of them.

One of the things that made this team so spectacular was the constant dedication to learning and helping to make each other better. We even had management’s buy off and encouragement which is a rare golden egg. They let us get away with a lot in the name of learning.

At one point we started having team competitions around Code Katas. One member would present a Kata and the other team members would have a week to come up with their best implementations. The presenting member would then publicly critique the implementations and pick a winner. This critique was really cool because you learned a lot about what the presenter considered important and how they thought about problems.

One of these little competitions lead to Terry Huges presenting The Gilded Rose Kata. He actually wrote it himself while he was deep into his infatuation with World of Warcraft. I loved it so much I blogged about it and even put up a starter project on github. The basic gist of the kata is this: Here is a piece of crappy legacy code that works. Along with it goes a textural description of what the code does, some modifications the customer wishes you to implement and some constrains you need to adhere to.

I also posted it to the Software Craftsmanship mailing list, a popular programming meme that I was infatuated with at the time. They went gaga for it. Todd Sedano at Carnegie Mellon University used it in his craftsmanship course. And most receiently, Emily Bache included it in her book The Coding Dojo Handbook.

A couple of things that gnawed at me about the proliferation and spread of the kata where that most of the early commenters credited me as the author, which seems to be mostly resolved with most modern references to the kata. To be clear, it was all Terry. I just really liked the concept.

I was also bugged by all the ports of the kata into different programming languages. The original was done in C#, using the most basic console program structure. Within a week there were Java, Ruby, JavaScript and Python versions. Currently you can find C, C++, SmallTalk.. pretty much any language you would care to do the kata in. I have not seen one in Lua, but it would not surprise me in the slightest. Just hit github and search for Gilded Rose and you will find what you are looking for.

I found this ironic considering the kata is about inheriting someone else’s code and having to implement new features while ensuring that you do not break existing features. The obvious choice to accomplish this is to reimplement in another language.

Imagine you having a conversation with a client that goes some thing like this.

Client: I have this system that a developer who is no longer here wrote a couple years back. The system has been running solid for a long time, but I would like to make a couple modifications. These modifications should be pretty simple. Can you give me an estimate on what you think it would take to implement them?

Programmer: Sure! This is totally doable. The first thing we need to do is rewrite the entire app in another language.

Client: … Really? That seems a bit redundant.

Programmer: Next up we will need to recreate our production environment to support running the new languages platform. Oh and we better migrate all of our data to a new Database platform as well.

Client: .. But how does that help with implementing the new features? This application has run for several years on the existing hardware costing me next to nothing.

Programmer: Oh and now that I think about it we will need to fire all our production support staff and hire new people who understand the new hardware, OS and database infrastructure.


Programmer: After all that, it will be a breeze to implement these new features.

Now I realize that katas are meant to be simple problem solving exercises that allow you to practice your skills. But I would suggest that one of the skills you should be practicing is entering an unfamiliar environment and being productive quickly. I would like to challenge the kata community to attempt the original kata. See what it is like to live in somebody else’s shoes and be productive.

If you can’t bring yourself to taint your machine with a .NET environment, give it a shot with Mono it runs fine. Or you could pick some other programming environment that you are less than familiar with, there are certainly enough ports of the original. 😉

Today I Learned: You Cannot Transfer Ownership of iOS Applications

I have recently completed my first iOS application on behalf of Furnishly, the local furniture exchange. All the release bugs have been worked out and the app is available on the app store. Yesterday, I started looking into how to transfer all the assets over to the owner of Furnishly so he could continue development and review download data on iTunes connect.

On github, this was a snap. Simply go into the administration section for the private repository, scroll down to the Danger Zone and click the transfer button under transfer ownership. Then type in the name of the repository and the new owners user name and hit transfer. Simple, easy.

In iTunes connect, it is a completely different story. There is no obvious way to transfer the application in the UI. Searching around in the FAQ surfaced this gem.

I sold my app to another developer and can no longer distribute it on the App Store. Can I transfer the app to the new developer’s iTunes Connect account?
No, you can’t transfer the app to another developer account on iTunes Connect. To add the app to another account, remove the app from the current account and upload it to the new iTunes Connect account.

Note that uploading the app to a new iTunes Connect account will disable current customers from receiving automatic and free updates of your application. All customer reviews, rating, and ranking information will be reset. You will not be able to reuse the app name and SKU in the old account. If you have uploaded a binary or used the app with the iAd Network, your Bundle ID will not be reusable either.

So apparently the way to transfer ownership of this app to the non technical owner is to:

  1. ask him to create a apple developer account
  2. wait to get accepted
  3. generate new application keys
  4. rebuild the application with the new keys
  5. delete the old application build from my account
  6. resubmit the new application via his account

Oh and all the folks that have downloaded the app in the mean time from my account are pretty much never going to get an update. All the ratings you might have received will disappear.

Seriously this is a horrible way to handle what seems to me would be a common occurrence. Did Zinga have to follow this process when they bought DrawSomething?

Anyone have advice?

The Day the LOLcats Died


Refactoring Javascript with Derick Bailey

I have subscribed to Derick Bailey’s blog for several years. He is one of my favorite Los Techies. I think he has a firm understanding of agile development practices and is one of the many progressive .NET developers to jump ship and start doing Rails development. So I was pretty excited to see he was producing his own screencast series over at WatchMeCode.net.

I am a rabid consumer of screencasts and even attempt to produce some of my own. So I am aware of some of the time and effort needed to create a quality screencast. Derick’s initial offering is a bit pricey at $14 for a single screencast, but you do get to download the video and do whatever you want with it. Derick offers HD 1680×1050 and iOS ready 720p versions. The encoding is very good, text is quite readable and the sound quality is great.

The screencast is on Refactoring Javascript. Derick uses a real world project, his Backbone plugin Memento. Using a suit of Jasmine specifications for the existing codebase, he walks through a set refactorings to modify the codebase while not causing the any tests to fail.

Derick starts out by first wrapping his current plugin’s implementation in a module and explicitly exposing a public API. In this refactoring he introduces a Memento object that represents the public API he wants to expose to users. He then moves on to introduce an internal Serializer object that handles all serialization concerns. This refactoring leaves his original code fairly lean and responsible for stack manipulation, so he names it as MementoStack. While he is focusing on clearly defining single purpose types, he identifies several minor smells like excessive guard clauses and repetitive if switches related to the type of Model being stored. He introduces a TypeHelper type that encapsulates the type decision and exposes a single API, which removes the concern from the other objects. This was a particularly clever refactoring which was worth seeing. After all the refactoring, Derick is able to identify a couple of bits of redundant code that he quickly explains and removes. This refactoring was interesting in that it wasn’t very apparent until the other refactorings had paired his code down to small easily digestible functions. Finally, he breaks a dependency from the MementoStack to the Serializer, by pushing the interaction concern up into the main Memento object greatly simplifying the two and giving the Memento object behavior.

Derick was able to completely refactor his plugin and end the session with his original Jasmine test suit all green. It was very enlightening to to wach him make a modification, run the tests, troubleshoot any failing tests until they passed, then start the whole cycle again. These failing test situations were not simple contrived examples, you could hear the surprise in Derick’s voice as tests failed. Listening to his troubleshooting techniques in these real situations was pretty fun.

So, was the video worth the $14? Yes, absolutely. I will most likely watch it several times and will revisit when I am working with Javascript. I would not recommend the video for javascript beginners though. You should probably have some javascript experience, at least be comfortable with free form jquery, before watching. There are some advanced concepts here that might confuse you at first.

My Ideal Development Shop

Adron Hall posted “My Top 4 Ideal Dev Shop & Product Characteristics, Yours?” to his blog the other day and solicited responses from other developers he knows, including your truly. I wanted to take some time to think about it and put my thoughts in order before responding, so I started a draft blog post.

I have worked with Adron in the past and think we have similar thoughts on what makes an ideal development shop. But I did want to add a few thoughts on what he said.

For me, the ideal development shop starts with how that shop fits into the organization as a whole. Does the organization see the development shop as a set of interchangeable resources whose output needs to be closely managed and directed or as a tightly integrated group who contributes to the bottom line value and leadership of the entire organization? Are the developers locked down and told what tooling and techniques to use to deliver software or is the team empowered to make their own technical decisions and held accountable to delivery? Does that culture rise above the immediate two layers of management?

The other side of that coin is how the developers themselves fit into the organization. Do they come in and do their time, punching out at 5:00PM or are they actively engaged in the business attempting to add value every day. Do they think in terms of the business domain or attempt to hide in technical jargon? Do they attempt to deliver functionality to the customer as they requested it, asking for feedback to perfect it or push back adding constraints on what can be done based on vendor tooling? Does the team share a sense of common code ownership with no fear of modifying any portion of the code base or do they silo in areas of expertise refusing to let anyone in to their little playground? Does the team feel a sense of responsibility for the quality of their output or do they delegate responsibility to a faceless QA department?

I also want to know how the development shop relates to itself. Do the team members respect each other’s contributions and skills or are they constantly talking other people down? Do team members educate each other bringing the competency level of the whole team up or do they horde knowledge forcing peers to learn things the hard way? Do team members feel comfortable asking for help when they need it without fear of judgement? Does the team actively seek out and destroy friction, constantly looking for a better way to accomplish things or do they allow every possible road block to halt progress?

Finally, I want to know the quality of developers that make up the team. Do the developers actively try to improve themselves, both on their own time and the companies? Do the developers work on projects outside of work to help sharpen their skills? Do they enjoy learning and teaching others in a collaborative way? Are they active in the community both attending user group meetings and presenting? Do they feel a professional responsibility to produce good code, going out of their way to prove a feature works as requested?

I think all of these attributes add up and contribute to the type of team I like to be apart of and work with on a daily basis. Technical things like what tooling, frameworks and techniques to use all fall out of these attributes and at the end of the day don’t really help you ship software if the team is simply a cog in the waterfall with no sense of ownership or responsibility.

Are You of South Asian Descent?

As a professional software developer, I have worked with many folks over the years whose families came from or are still in countries like India, Pakistan, Bangladesh, Nepal, Bhutan, Maldives, and Sri Lanka. If you happen to be one and you read my blog please consider becoming a bone marrow donor. For this particular segment of society the odds of finding a marrow donor are 1 in 20,000. You can help change that, here are a few ways to help:

1. If you’re South Asian, get a free test by mail. You rub your cheeks with a cotton swab and mail it back. It’s easy.

2. If you’re in NYC, you can go to this event organized by friends of Amit.

3. If you know any South Asians, please point ’em to the links above. Thank you.

Why do I care? Because Amit is one of us and he deserves a chance at a long productive life.

Portions of this post were taken from this BoingBoing post.

It Is How Others See Your Accomplishments That Matter

As I leave my amazing team at Russell to take on new challenges with a new team at Milliman, it is good to look back at what I have accomplished here. It is even better to see the appreciation of the value I helped to deliver to Russell.

Bobby Johnson has had a large impact in a relatively short tenure at Russell. His leadership in improving software development practices throughout the organization has been significant. He has provided mentorship and guidance beyond to various development teams throughout GT&O and our Business Partners. His project contributions have been diverse as he has had roles on the Indexes Research and Reconstitution, OATS Reporting and YODA/ETF applications. He recently was appointed as a Manager of Application Development.

While the loss of these teammates and their knowledge, skills and energy are significant, I would like to express my gratitude for their hard work during their time at Russell. Their contributions have elevated our capabilities as a development team.

Now that is an endorsement I can take pride in.

Why drop the I if you’re going to just add an Impl?

I was perusing the TopShelf source code this morning, trying to track down a change in the hosting API, when I discovered that the TopShelf team has succumbed to the new drop the ‘I’ in interface names meme. It’s new to the .NET scene anyway, the java guys have been doing it for a while like all new good ideas in .NET. That were not stolen from ruby anyway.

If you are unfamiliar, the gist of the meme is it is unnecessary to add the ‘I’ in front of an interface name because the consumer of the interface does not care that it is an interface and the ‘I’ is a form of Hungarian notation that the civilized world has all agreed is a bad practice.

So your..

public interface ISomeBehavior { }

..should be..

public interface SomeBehavior { }

And this makes a kind of sense. Where it breaks down is when you see a class that implements the interface that is named like this.

public interface SomeBehavior { }
public class SomeBehaviorImpl { }

I am not quite sure what benefit is in moving the ‘I’ from the interface to the implementation and adding three characters. What have I gained beyond adding to my carpel tunnel? Does my consuming code care somehow that that this is an implementation of some ‘I’-less interface?

At some fundamental level, an interface is a contract. That contract states that the class that implements the interface provides an specific usable set of methods and properties. An other way to look at this is that the interface is a behavior.

Consider the IDisposable interface provided by .NET. There is no DisposableImpl floating around. The interface describes a characteristic of the implementing type, that it behaves like a disposable thing.

Your interfaces need not be a one to one relationship with the implementing class. In fact, your classes can implement multiple SRP friendly interfaces. To quote Brett L. Schuchert:

class Manager : public ISing, public IDance {}

😉 Keep your interfaces clean, let the managers violate all they want

So, I am sure you making angry face at my blog right now thinking, “Ok, mister smarty pants, what should I do then.”

To that I say, I like the ‘I’, but I use it so that it reads like a declaration.

public interface IReadFiles { }
public interface ICalculateRates { }
public interface ISingAndDance {//OMG SRP VIOLATION!}

And you may find that as preposterous as I find the ‘I’/’Impl’ meme. But that’s cool. To each his own, but that damn ‘Impl’ stuff is not mine.

This post brought to you by Negatron.

James Shore & Diana Larsen’s Proficiencies of Planning

During Agile Open Northwest, James Shore and Diana Larsen held a session called Proficiencies of Planning. They presented a concept they had been discussing to the group of standing room only people and solicited feedback and input. This blog post is what James posted after the conference. I felt this was one of the best sessions at AONW. It was the one that made me think the most.

I really like the progression of agile adoption shown:

  • Level 0: We build code.
  • Level 1: We create business value.
  • Level 2: We deliver business value.
  • Level 3: We optimize business value.
  • Level 4: We optimize our organization’s business value.

During the session we documented a progression of customer involvement in projects along these levels which also showed an interesting progression starting at level zero with a “disconnected customer” to level four having a “customer as investor/constituent/strategic partner/co-inventor.”

In my organization, I can see a spread across the first few levels based on the attributes described on these sticky notes. We do some things well on most of the levels and fall over on some of the other things. But I do feel that my team is pushing in the right direction and now we have a blueprint to help us identify targets of opportunity.

Where does your organization fit? Are you and your team pushing toward a productive mutually beneficial relationship with your customers?

Every reform movement has a lunatic fringe