May 29

Social Development adds the Third Option; Friends Can Now Fork

Tech with tags: No Comments »

Tools enables new ways to build. Distributed version control and the tools that are enabled on that platform (as highlighted by Github) have hit mainstream. Some graybeards will scoff and talk about how they did this and more decades ago…. And they typed up hill both ways! Now, it is available for all.

I have seen the shift in the way that projects can now be run, and how software product can be shared. Take an example, such as where I work now. Ben and I run mobile engineering for Global eCommerce at Walmart. This means that our products scale in different dimensions. One axis is the number of platforms for a given locale: iPhone. iPad, Android, mWeb, etc. Then within that locale a platform can have multiple products: grocery app, general merchandise app, etc. Yet another axis is the various locales. The apps and platforms for the different countries may not fully align. As you can imagine, we think about the topic of “leverage” across these axis a lot. There are extremes.

One True App

This is the mega platform. It is generic in a way that lets you customize it for varies experiences, but it has to know it all. I have rarely ever see this approach as it means that you need to think up and agree to the constraints of he system for all parties up front. Can you take a look. At the businesses from China to the US and say they can happily live with the same guard rails? If so, great, you have gotten a winner. Even so, you quickly find yourself in a resource allocation quandary. The owner of the core platform is the parent, and each locale is now a child shouting for resource. The largest baby bird often wins, even if the runt is actually growing, or had the potential, to grow fastest. The sibling rivalry can become a pain too. The parent may want to push back to the children, and can try to do so by developing the core APIs and letting the kids have at it on their own. Awesome, loose coupling. The other massive benefit is that the kids can go outside of the family. We see this a lot due to the fact that the parents use popular and/or standard libraries with well trodden API. This is where API shine the strongest anyway. Great a small piece of functionality that can be shared and extended. If you are building a mobile Web application client, why wouldn’t you build off of a Backbone, socket.io, zepto, underscore, handlebars stack (or your own favorite equivalent version)?

The Third Option

There is a middle ground between “here is my code” and “here are some APIs”. The greatness of the pull request enables this in spades. Give the kids some safe rope to help them climb. If the platform is evolving fast and one kid wants to go off in a direction they can fork away and use the tools available to diff and merge. When over for Sunday dinner and you are all chatting about what you did that week, you can see if it makes sense to pull something into the mainline.

The parent product now has evolved into others that are able to steal good ideas from each other all the time. When taken to an extreme you see Linux. Linus has his Truth, but his lieutenants have their own, and there are folks who have their own under that.

This is all non-trivial to manage from a process standpoint. It also takes time to keep up to date and sync early and often so you aren’t looking at a mutant form that can’t breed with the core no ‘more. There are many new tools that could enable us to visualize and work with the forks, but it seems like we have hit a new norm, and the nuance of this approach can be just what the doctor ordered for certain platforms and products. It enables truly fluid structures. You can get up to speed with something new quickly, without having to fully by in.

May 25

A touch of class; Customer-driven design at work

Tech with tags: 1 Comment »

As a company, do you focus on the customer? Many companies do so only when the focus is to lock in the customer. How many services have you used that when it came to leaving said service you ended up running around like a blue arsed fly on their Web site. This is the norm. Many will say “duh, we don’t want to put effort into that side of the business where we are losing a customer!”

Every now and then I see companies that care about the entire experience, and I just saw another example in Sprint.ly.

I love their service, but recently have been (due to reasons not to do with the quality of the product or what I would personally like to us) using other products to develop software. I stayed signed up as I want to come back to the service, and the following email just came in:

Your credit card was NOT charged!

Inactive account disabled

It looks like you haven’t used your Sprint.ly account in the last 30 days or so. We don’t like getting billed for things that we don’t use and we don’t think that you should either so we’ve disabled your account.

Fear not! Your data has NOT been deleted and you can always log into your account to reactivate your account and access all of your data.

We hope to see you again sometime soon. If you’d like to reactivate your account now you can do so by logging into your account and updating your billing information.

If you no longer plan to use sprint.ly, there’s nothing left to do on your part. Your account has been disabled and we will not continue to attempt to bill your credit card.

Sincerely,

The Sprint.ly Team
http://sprint.ly

Now this is classy. Not only did they pro-actively stop taking money from me, think about the fact that they had to code this into the system. This story made its way up through their large backlog to a point where they did this.

The net effect is that my trust and emotional connection to Sprint.ly has risen. I look forward to re-activating my account soon.

Joe Stump and friends, you are a classy act.

May 07

The Product Engineer

Tech No Comments »

clothespegg

I have been thinking about the shape of teams. I have built software products in teams as small as 1, and as large as “I don’t actually know everyone who is involved in this project”. You are probably not shocked that I prefer closer to 1 than infinity (ignoring the fact that we all build on the shoulder of computing giants!)

What is the ideal size for a team? It obviously depends on the problem, but I have changed my view over time. For awhile I would see the skills that I lack, and think of the roles that need to fill in the gaps.

  • You need a developer to write code (and then there is front end vs. backend)
  • You need a visual designer to create assets
  • You need a UX person to get the right experience
  • You need a product manager to define what we are building and garden the backlog
  • You need a QA person to test the application
  • You need a project manager to keep everything moving and unblock blockers
  • … and you can keep going …

For some projects this can make sense, but for many…. maybe it is overkill?

The other extreme is the team of 1. There are some real advantages to a team of 1:

  • Easy to build consensus :)
  • The entire team thinks the same way.

You often here the “Linus was able to do the core of Linux by himself” (even though it grew into a case study for distributed collaboration). Solving a narrow problem can be ideal for 1, especially when they can collaborate in a loose way with others. We have been doing this in academia for a long time.

In the modern time I look to folks like Joe Hewitt as people who can go off and do something brilliant in a short time with their style. If you look back at the early Firebug your hair may curl when you see his with()y style. Pairing him up with the wrong person would not be productive. He also happens to be solid at all of the other skills (not just a great developer). He is a perfect “Product Engineer”.

Two heads are better than one

I am often a fan of pairing up on problems. There is a reason that I love working with Ben for example. The advantages here are:

  • You have a built-in sounding board / reviewer
  • If you complement each others skills, the match can be golden.

One of the pairings that I really enjoy is that of a product focused designer and a product focused engineer. I have seen more and more companies with job openings that they call “Product Designer”, but I have only just started to see the “Product Engineer” term. I have changed the view of myself and my roles over the years (developer, engineering manager, advocate, technologist) and I often have conversations with myself (bicameral mind and all) about what I want to be when I grow up. I find this hard because I like each of those roles. When I am in the mood to be a “maker” I find myself much more interested in the software product than the pure technology that gets me there.

Thus, I enjoy being a “Product Engineer”. Someone who doesn’t sit in the corner hacking up some code, but someone who loves building products with software, and programming is the tool at hand.

One of the reasons I am so impressed with the GitHub team is that they tend to hire product engineers. It helps greatly that the product they are engineering is something for a developer, so they don’t have to dig deep to see how their user base would want something to work.

Every team is different. If the engineer on your team is an amazing hacker but just wants to be told what to build? get a strong UX/PM to cover that role. There is no “right structure” for all projects with all types of people.

When I think of developer super heroes though? I will be day dreaming of the “Product Engineer”, “Product Designer” duo. And, at the very least, I will make sure that my engineers are as invested in the product as they want to be, and that my teams are as small as possible (but not smaller).