New Beginnings

Back in May I accepted a new role at LinkedIn as a Partner Engineer. My role is to serve as a developer advocate for our LinkedIn Developer Platform. It’s been pretty exciting so far. I have the privilege of helping developers leverage our LinkedIn APIs to build some pretty cool apps.

Feel free to check out some of our work and start building your own application!

My growing appreciation for State Machines

I remember the first time I learned about State Machines in my computer science classes. Actually, I don’t remember too many things about finite-state automa other than the fact that there were way too many mathematical models and UML diagrams in that class!

It wasn’t until I started working at ShoeDazzle last year that I was re-introduced to the pattern. Here we use the state_machine Ruby gem, which serves as a nice, simple library for Rails.

I’ve found state machines to be extremely useful and I’m surprised why I’ve never used them before (whether using an existing library or just writing one from scratch). Instead of keying off of objects, arrays, booleans or other data types/data structures to determine a certain action, we make use of states in our models. It makes things clean and consistent. In my PurchaseReturn model, for example, I could implement several states and transitions which clearly define before/after transitions along with their transition requirements

state_machine :initial => 'approved' do

  after_transition :to => 'received', :do => :process_receive
  after_transition :to => 'cancelled', :do => :process_canceled

  event :receive do
    transition :to => 'received', :from => 'approved', :if => :is_valid?
  event :cancel do
    transition :to => 'cancelled', :from => 'approved'

As you can see in this example, it’s pretty simple to implement. You have ‘states’ as strings then ‘events’ which cause transitions from one state to another. In my example model, it initially gets created in the ‘approved’ state and based on certain events can either transition to ‘received’ or to ‘cancelled’. Then I invoke certain methods based on which state I transition to. I can also have conditional checks before making a transition (e.g. is_valid?).

Not all data models will greatly benefit from creating state machines. However, I think I’ll be making more use of them – particularly in the design phase of data modeling. If anything it helps you think of all the different states a model can be in. And if you can think in that respect, then I think you can avoid a lot of issues and bugs that will surface from bad design.

Cherry-pick commits from one branch to another in Git

For those that don’t know (I recently find out myself), cherry-picking a specific commit from one branch to another couldn’t be simpler in Git. Recently I worked on a feature that needed to be merged into a release branch sooner than planned. The git commands are pretty straight-forward

git checkout http://you
git cherry-pick [commit]

Of course, if there are any merge conflicts you need to resolve them. In my specific case, I was working out of a feature branch in which myself and other developers had numerous commits against. We only needed a single commit to be picked out and merged into the release branch.

Out of hibernation

It’s been a long time since I’ve updated this blog. A month after my last post I took a job with an eCommerce startup that’s becoming one of the hotter companies in LA. The technologies I’ve been focusing on are Ruby on Rails 3 and Pentaho Data Integration (both of which were new to me when I started a year ago). So far it’s been a blast! More updates to come.

Should Product Managers Always Be the Product Owners?

I’m sure I’m not the only one who’s ever pondered this. As more and more shops move towards SCRUM as their development methodology, the role of the product owner becomes increasingly important in defining.

Well, what the heck is the product owner supposed to do in the first place? There are a lot of formal definitions, but the main objectives of their role are as follows (taken from

• Setting objectives for the Sprint (or iteration)

• Prioritizing and maintaining the backlog

• Participating in the Sprint planning meeting

• Elaborating stories on a just-in-time basis with the team

• Accepting stories into the baseline

• Accepting the Sprint

• Driving release planning

By definition, a product owner’s involvement in the SCRUM process is daily. They need to be constantly involved with the dev team as far as clarifying user stories at the sprint planning level and even the daily stand-up level, among other things.

A traditional product manager has other duties outside of the SCRUM realm that becomes hindered when following the product owner definition. The product manager is ultimately the poster child of the product they’re managing. They have a responsibility to achieve success in the market of their product in addition to insuring success in the delivery of that product. In other words, a lot of their work involves meeting with customers and analyzing current market trends. It’s difficult to be fully focused on these duties when you have to attend daily stand-ups and be available to the developers at all times.

Ideally, I think an agile product team could gain value in having both a product manager as well as a product owner. The product manager can continue to focus on being the face of the product from a design and marketing standpoint. The product owner can be someone who is more technically-inclined and is able to fully engage with the SCRUM team. The product development is still handled mostly by the product manager, but the product owner takes on the role of prioritizing the user stories and being a conduit between the business stakeholders and the dev team.

Obviously this situation won’t work for all companies. Some product teams are small enough to have one person handle both roles without becoming overwhelmed. Other teams simply don’t have the budget for both. However, I think it would be interesting to see how a dual role situation would pan out.

If you fail to plan, you plan to fail

I generally don’t like throwing quotes around to get a point across, but in this case I really like how it applies to the importance of documenting specifications in software development.

Engineers hate writing documents. And I don’t blame them. When you spend most of your time writing code and thinking in conditional statements, the last thing you want to do is open up Word and start writing specs (plus, that’s what we have product managers for!).

Any product requires careful analysis and information gathering before a single line of code is written. Surprisingly, in most projects the important stakeholders fail to answer one or all of the following questions:

  • What is the application supposed to do?
  • Who uses the application?
  • How is it supposed to work?

Seems simple enough, right? Unfortunately, in software shops throughout the world, these questions are either ignored or hastily answered due to business pressures without spending the proper time discussing them among the role players of the team.

Here’s another quote for you: “Communication is what you get”. In other words, if the product is defined poorly then it will be developed poorly. How can you build a solid product if you don’t know exactly what it’s supposed to do? Defining what the product is (and isn’t) early on in the process will save time and money.

Regardless of what development methodology you use in your company, functional specifications should be obligatory in any product development scenario. You know what the application is supposed to do – but you also need to know how it’s supposed to do it. Functional specs give you that clarity early on. I like when product managers and developers (and invite the QA folks too!) get together at this stage because everyone’s on the same page as far as defining the product.

Sure, it may seem tedious. It may even seem excessive at times. However, proper specifications go a long way in ensuring the success of a project.