Archives for January 2016

Plan to serve cup cakes at your software wedding

January 18, 2016 Leave a Comment

The wedding ceremony is past and your tummy rumbles. The food at these events is somewhat hit and miss as it isn’t easy to feed this many troops. Chicken or fish? Hopefully the cake will save the day! At some parties as of late the decoration may be traditional, available for the cut and face smash, but we all for cup cakes.

It was this memory that fired whilst thinking about software that setup the analogy that you should consider shipping cup cakes vs. large wedding cakes.

The wedding day is your ship date for a major release. As time goes by you need to make adjustments to the schedule.

You may have a suites of products all working to come together, or you may have a series of features in a release. You don’t want them all relying on each other to create that one spectacular cake. With a cup cake approach you can have differing types that come together on their own schedules.

Your users don’t know the plan

I can’t tell you how often I have seen the following happen, falling for this bias myself. You build your plan and although everyone is running hot to ship the entire cake you all kinda feel like it would be wiser to focus and cut. But how can you, the cake will be so delicious! If you don’t have some of the ingredients it won’t reach its potential! We quickly forget that the users don’t know the plan and would probably prefer a cake with some ingredients missing, if the quality of the pieces we do ship is higher.

If something shows up half arsed it is obvious, and sets the tone. It may be enough to turn off a user who may never come back.

With be One Big Cake there are ingredients you can’t just skip else it will taste bad, but with cup cakes you could offer fewer options and no one would know. You need to be crystal clear on which is which, and say no to the items that aren’t critical ingredients.

Having come from the world of retail where shipping features in February has an insignificant impact compared to October, it is crucial to play this game well. You can’t move the holiday season, so you need to plan accordingly.

In general though I am a huge fan of the flywheel. Chrome is a perfect example of this. The trains run on time and a process helps the progression of features from ideas to canaries to beta to stable. New cup cakes show up every six weeks.

As you plan the narrative of how you are making your users bad ass in 2016, remember that they don’t know the details that you know, so allow for a flywheel of quality rather than risking the Big Bang of meh.

The Evolving State of Web Development

January 12, 2016 Leave a Comment

Wow, it looks like the web development is in a really sorry state! As I read the bileblog-esque post I found myself acknowledging some of the points, but also feeling like the baby was being thrown out of the bath water.

Writing my first web page to serve to lynx and mosaic was so simple. Man I miss it. I could telnet to my web server, pop open vi or emacs depending on my mood, add some <markup>, hit save (:wq!), and reload my browser.

Why can’t life be that simple?

The Web platform can do a lot more…. you know… useful things for people
The bar for great experiences has gone up.

I love developer ergonomics. I want to invest in my tooling so I can live reload to enable a very fast change, run, test life cycle. It is possible to wire up your babel build so they are watch’d, and you can tie into live reloading. Does it takes some upfront work? Sure. Is it worth it? yes.

The React Ecosystem, So Complex!

One of the poster boys for complaining about the complexity of Web development is taking the 2015 hot fave and tearing it down. Pete Hunt does a great job of reminding us how we got here. The initial concerns that React tried to solve hit a nerve for some folk, but once people got building applications we kept running into more issues and decided to do what we do as developers: we created abstractions to try to solve them.

If you haven’t been through this ride yourself it can be tough to understand what is going on. When we are born and join the world we are placed in environments where we use a ton of abstractions. Tools like knives, forks and spoons. Outlets at a particular voltage. They are everywhere and we don’t understand the evolutionary path that had us end up at this particular point.

Web development is evolving, and it needs to evolve fast. Many of us wish it would evolve faster, but this evolution always brings tension and pain. The problem is that true app developers who just want to build the right widget get tricked into the world of the engineer. They have to tie together a world that is changing rapidly, one that easily gets out of date. This is where you have a choice: do you reach for the new rung, knowing that you will pay the tax of keeping things up to date? Or, do we stick with something simpler, something that isn’t changing at quite the rapid rate.

You could easily argue that too many people join the rat race of the new shiny, and they jump on something that looks new but it won’t have any effect on the end user experience. It feels like you are jumping to a new rung, but really you just moved sideways.

One clue for us to understand how fast something changing is how “packaged” a solution can be. If the ecosystem is moving so fast that you can’t have a stable answer to the stack then this is a sign greater than the velocity of new releases (although breaking API changes is another sign).

I do agree with the pain of working with a package that doesn’t do anything out of the box. Convention over configuration works well when there are intelligent defaults that cover the majority use cases, while allowing people the escape hatch.

Jumping between top frameworks such as Ember, React, Angular, Polymer, etc isn’t going to do much for your users as is. I do think that we are at a point where it is time to reach for the next rung, and that is by re-thinking your web application to be offline-first.

When Google Maps came out, MapQuest instantly felt old and wrong. This is one of the apps that sparked the AJAX revolution (even though the panning Google Maps experience didn’t use XMLHttpRequest at all!) I think we will see similar examples as folks use service workers and friends to create offline capable applications. It will be stark, and it will happen fast. This time, users are already used to the capability via apps. Nothing frustrates me more than when I expect something to work, and find that it doesn’t. For example, using a task system that doesn’t allow you to add a new task unless you have a connection.

As you kick start 2016, what can you change that can genuinely change the user experience? Is there a change to your dev tool chain that allows you to build that experience so much faster that it will get more features to your users?

Human concurrency

January 6, 2016 Leave a Comment

“There are only two hard things in Computer Science: cache invalidation, naming things, and off-by-one errors.” — Phil Karlton++?

Concurrency is hard. It is a world of trade offs and you often see some junior engineers thinking they have found the one true solution by adding in a caching layer to fix their performance problem.

I have been there. So many of us have. We need to be able to offer predictable and reliable scalability, and to do that we need to minimize bottlenecks. If we get this wrong though it takes more time to manage replication and invalidation and we have just created a potentially worse, and more complex problem.

As hard as it is to architect a solution that maps to product requirements and SLAs, I often think about how the same problem lies at the heart of organizations.

We have come a long way in how we try to scale humans:

But we may have a ways to go, even in 2016:

Thanks to Adam Tait and Stuart Argue for the inspiration and these photos 🙂

How can we predictably and reliably scale?

It is also tempting to grasp for the “simple” solution. If you have grown up around silicon valley for example, you think that the answer is talent density and small teams.

You can’t outgrow those pizza teams, you just need to split them up and you are all set!

However, it may not be that simple. This works just fine if you don’t need to communicate or rely on each other. Normally this isn’t the case. If you have team A relying on team B for some infrastructure (which is defined here as “the stuff you don’t want to worry about to get your work done”) then you could be bottlenecked on their velocity. If team B have multiple client teams then they have to prioritize and work out how to solve for that.

You can easily get frustrated here, especially if there is a lack of transparency around how prioritization happens. Do you have a way to offer up head count or resources so you aren’t just sitting there saying “when are you done” but are diving in to help? Is that even possible given the skill-set needed?

That is often the rub. Humans can’t scale in the same way as CPUs as each one of us is so different, and each one of us has very different software onboard 😉

It is so very easy to get into a log jam. Let’s look at a hypothetical example that you may have seen yourself.

Your company has a team that provides an infrastructure as a service. In general you want to use shared resources, especially if they have domain knowledge that you lack, and if by supporting you all of the ships that they support can rise.

It turns out that they want to support you, but they don’t have the resources to jump on this work. Now begins the prioritization game. Can you collectively get support for this work to be done?

There is nothing worse than being the small fry when it comes to these discussions. Let’s say you are a global company, and you are sharing a central payment service. A small country has a payment solution that is The Gold Standard where they are, so it is crucial to get it integrated into the Global Solution. But then a long comes the Big Gorilla. The country that is so large that one compliance feature goes through the ROI analysis and it knocks the small guys solution below the line. Ouch.

Well, screw it, just go off and do a custom build! We can move fast! Talent density ftw! It feels great while you do it, but you may have created a new cache to invalidate. Fast forward a little and you notice that there are now a slew of other groups that have done the same thing. Team members have moved around and some of those systems are hard to keep alive, let alone gaining features.

How will this play out in the long run? It may still make sense to take this path though, and as someone once told me:

“The life blood of a company is momentum.”

This is why scaling companies can be hard. It will be wasteful and you need to be OK with that. It will be messy and you need to deal with that. You can build a framework to help you make the decisions that you need to make as they come up, and then you need to paddle as fast as hell.

p.s. I am looking forward to seeing what comes out of Scaling Teams. There is a dearth of content on engineering management.

« Previous Page