software engineering

BTW – if there is an SEC filing about your deployment, something may have gone terribly wrong.

From Doug Seven explaining how, in 2014, that’s exactly what happened.

What we do first is we build very simple foundational building block services … we will build the simplest possible service that you could think of.

The next thing we do is we encourage an open marketplace within Amazon so individual teams can use, optimize, and extend these basic services.

We use our individual [teams] as a test lab to experiment on better ways to do things, and when we find something that seems to be working, we look for ways to [grow it and use it more] broadly.

Then, on the value of open repos:

We want this ecosystem of learning from each other because we are all leveraging each other’s web services. We have these hardened contracts, it’s incredibly high leverage to be able to go and see how someone else used a web service quickly, and rip a piece of their code—steal it—and make use of it for your own purposes.

Andy’s slides are at Slideshare.

The following line in a post about the difference between declarative vs. imperative programming caught my attention for the way it echoes product management best practices:

[I]t’s often good not to think of how you want to accomplish a result, but instead what the component should look like in it’s new state.

Of course it does matter how you get to where you’re going, but it’s a whole lot easier if you first focus on aligning everybody on goals and where you’re going.