Shared: Why I think GCP is better than AWS

Both AWS and GCP are very secure and you will be okay as long as are not careless in your design. However GCP for me has an edge in the sense that everything is encrypted by default. For example their buckets and their logs are encrypted in transit and at rest. For some bizarre reason AWS does not encrypt buckets or logs by default, you have to enable this. Who the hell would NOT want their data encrypted on AWS servers?

Fernando Villalba: Why I think GCP is better than AWS

When I saw this post come across I thought it was going to be some serious clickbait. Surprise, surprise – it’s anything but, filled with specific examples of where GCP is superior to AWS. The (sad) truth is that GCP has taken far too long to get to its current state. Google seemed to treat GCP as a side project, while Amazon created the market for cloud infrastructure. Regardless, there are many things Amazon could learn from GCP, including simple things like sane defaults, wrangling the mess that is their account system, and putting together a more coherent story for developers. -Josh

Shared: Do I Need an API Gateway if I Use a Service Mesh?

I believe the confusion arises because the following:

  • there is overlap in technologies used (proxies)
  • there is overlap in capabilities (traffic control, routing, metric collection, security/policy enforcement, etc.)
  • a belief that “service mesh” replaces API management
  • a misunderstanding of the capabilities of a service mesh
  • some service meshes have their own gateways

The last bullet is especially confusing to the discussion.

Christian Posta: Do I Need an API Gateway if I Use a Service Mesh?

Good post, especially relevant for my current work where we’re deep diving into Kubernetes/Istio land. Previously, I was working on products that had an API Gateway as a main component. I noticed right away a lot of overlap between what Istio provides and products like Apigee, Kong, etc. provide as API Gateways. Confusing. Christian’s post helps identify the overlaps while digging into the differences. -Josh

Shared: Only 15% of the Basecamp operations budget is spent on Ruby

For a company like Basecamp, you’d be mad to make your choice of programming language and web framework on anything but a determination of what’ll make your programmers the most motivated, happy, and productive. Whatever the cost, it’s worth it. It’s worth it on a pure cost/benefit, but, more importantly, it’s worth it in terms of human happiness and potential.

DHH: Only 15% of the Basecamp operations budget is spent on Ruby

True. A similar argument can be made when people debate Kubernetes vs. Serverless vs. PaaS vs. ??? In most cases, whichever approach you go with for running your apps/services, that’s just the tip of the iceberg. Data stores, file storage, messaging, networking, and more all need solutions and will often make up more of the financial (and operational) pie than your service/app layer. – Josh

Shared: Why I Listen to Podcasts at 1x Speed

On my microblog I mentioned that I always listen to podcasts at 1x speed.

Here’s why:

We’re in danger, I think, of treating everything as if it’s some measure of our productivity. Number of steps taken, emails replied-to, articles read, podcasts listened-to.

Brent Simmons: Why I Listen to Podcasts at 1x Speed

Same. It’s strange though, I listen to most audio books at around 1.5x speed. Podcasts are always played at 1x speed. I think this is mainly because I enjoy the regular cadence of the podcast conversations, but the audio books feel painfully slow in comparison, mainly because it’s usually just one narrator reading. If I felt a similar need to speed up podcasts, I don’t think I would listen to them as much as I do. – Josh

Shared: Reorganizing Product Teams

People want to know what worked well at other successful companies because there is an assumption that it might work well for them… this is understandable. But what worked at Spotify or Shopify or Stackify will not necessarily work for them.

And recently, a product leader at Spotify shared that her group (and many others throughout her company) have evolved to very different organizational models than described in Henrik Kniberg’s 2012 Scaling Agile @ Spotify.  I’ve repeatedly seen that cutting and pasting someone else’s organization ignores the hard retrospection about what’s not working (and what works well) at your own company.

– Rich Mironov’s Product Bytes: Reorganizing Product Teams

So much good advice in this article by Rich Mironov. His section on Professional Service organizations trying to build products is spot on. There is such a mindshift necessary in going from pro services to building products that most organizations can’t pull it off. Not to mention the practical issues that arise from focusing on a product that generates zero revenue and demands 100% focus from a product dev team that would be billing for their time if they weren’t working on the product. There is immense discipline required to pull this off.

Product Owner != Product Manager. Amen. I’ve been practicing Scrum for about 15 years now. I received training from one of the creators of Scrum, Ken Schwaber, and one of the go-to people for product owner training, Mike Cohn. Great training. And yet, most of the focus was on overcoming problems that internal IT departments face versus building full blown products that generate revenue. As much help as I think technical PROJECT management needs in various areas, technical PRODUCT management is in desperate need of help across the board. Too many people have the title/role with little training, mentoring, and/or coaching. For all the excellent resources available for Agile and lean project management and software development training, there is little (in comparison) for product management. The gap is felt by product development teams churning, with a common complaint about how “Product” is incapable or even incompotent. The problem is left unaddressed mainly because those in the Product org responsible for fixing it are in just as bad (if not worse) shape than those they hired. Rough. – Josh

Shared: The Blue Tape List

Having been through this experience many times, I’ve discovered that a simple fix is patience. In time, that which is different will feel normal. It’s why when a team member reports moderate concerns with a new hire that I gently always ask, “When did they start?” If the answer is less than two months, I suggest, “If it’s not heinous behavior, give it another month. They’re still adapting to a new environment, and we don’t know who they are.”

Rands in Repose: The Blue Tape List

Solid advice in this post. Adjusting to a new job or role takes time. We notice things that appear to be broken in these situations. Some things are broken, some are not. Keeping a list is good during this adjustment period. Revisit once some time (3 months is good guidance) has passed to determine what needs fixed, what needs improved, and what is actually OK to leave as it is, at least for now. – Josh

Shared: How to break the “senior engineer” career ceiling

Remember, your job is to help others become better versions of themselves, not to make them become you!
You need to show, not tell. And use your power of influence to level others up. Help other engineers improve their decision making and their ability to execute effectively. This can be slow and challenging and 80% of what you do is communication. How to break the “senior engineer” career ceiling

Moving from an individual contributor as a senior software engineer to a tech lead or principal engineer is not for the faint of heart. I’ve seen people struggle with it over the years in my career in tech. The biggest “gotcha” is when the person realizes they’re no longer measured based on their output but on their impact, and that impact often has little to do with what they were best at prior to the promotion. Making myself better is one thing. Making others better is next level and then some. – Josh

Shared: Crypto can’t scale because of consensus … yet Amazon DynamoDB does over 45 Million TPS

Infrastructure ignorance comes at a cost. Cryptocurrency developers largely ignore the fact that the cloud exists (certainly that managed services, the most modern incarnation of the cloud, exist). This is surprising, given that the vast majority of cryptocurrency nodes run in the cloud anyway, and it almost certainly accounts for at least some of the large differential in performance. In a system like DynamoDB you can count on the fact that every line of code has been optimized to run well in the cloud. Amazon retail is also a large user of serverless approaches in general, including DynamoDB, AWS Lambda, and other modern cloud services that wring performance and cost savings out of every transaction.

A Cloud Guru – Medium: Crypto can’t scale because of consensus … yet Amazon DynamoDB does over 45 Million TPS

Lots of interesting info on DynamoDB in comparison to blockchains. One big difference that I think the author downplays is that DynamoDB is a completely controlled and optimized database from one owner (Amazon), while the most popular blockchains like Bitcoin are open projects running in a completely open enironment. If DynamoDB was running across AWS, Azure, GCP, as well as less “corporate” data centers, and had Microsoft, Google, and miscellaneous individuals running DynamoDB nodes, would DyanmoDB performance take a hit? How big of one? And how comfortable would Amazon be with trusting that type of DynamoDB deployment?

Also, DynamoDB is not even close to being censorship resistant. This may seem like a minor point, but, as the recent events in Hong Kong remind us, censorship resistance can be very important. – Josh

Shared: This Feature Should Be Easy

It’s everything around the feature that makes it harder: UI design, localization, refactoring, accessibility, state restoration, getting new artwork (for a toolbar button, for instance), dealing with errors, testing, updating the documentation, etc. This Feature Should Be Easy

If you want to make sure your feature request is dismissed or put at the bottom of the list, make comments about how easy it should be to implement it. Maybe it is easy. But, as Brent notes, it’s likely not so easy and saying it is can be perceived as condescending. – Josh

Wardley Maps for product development

Wardley Mapping is most commonly associated with higher level business strategy. When I’ve talked to people familiar with Wardley Mapping, they’ve been quick to dismiss it as a tool for the C-level suite, not for mere mortals developing products. I disagree. The following will attempt to explain why I find Wardley Maps not only relevant but vital to product development. If you’re unfamiliar with Wardley Maps, I recommend watching Simon Wardley’s 2017 Google Next talk for a good overview. If you want to take a deeper dive, I suggest Simon’s free online book.

Digital Beanie Baby: Husky
Welcome to the future. Digital Beanie Babies. Trade them on your favorite exchange!

Imagine. We’re transported to a time where it seems like anything with the label “beanie” is drawing attention, mostly because a new form of Digital Beanie Babies (DBB) has been skyrocketing in value for over 12 months. An entire ecosystem has sprouted up around the digital critters. In the midst of this beanie bonanza are exchanges launching to enable trading DBB, much like other exchanges exist for trading stocks, fiat currency (e.g. USD), etc. Each new DBB exchange has its strengths and weaknesses.

A few entrepreneurs identify an opportunity to create a new exchange that fills the gaps left by even the most successful DBB exchanges, while also adding a couple innovative features. They’re focused on meeting existing customer needs in a burgeoning market, not building a larger technical “platform” that has aspirations beyond being a very successful DBB exchange. The founders form their startup, get some technical people on board, build a proof of concept, raise funding, and continue building on the vision of providing a better DBB exchange for traders big and small.

But how does the startup know that they should build this product from the ground up?

Product development for this new exchange is focused on continuing the path the proof of concept set – build a secure, fast, trustworthy, and feature rich DBB exchange from the ground up. In such a new market space this seems reasonable. Put together a small, agile/lean development team and continue to build a product that meets the needs of its traders, validating the product as it is built. Lean startup style.

But how does the startup know that they should build this product from the ground up? Are there pieces they should buy? Higher level functional open source components they should adopt? The assumption is made that because DBB trading is a fairly new market it requires building a brand new product from scratch. Besides, many of the most successful DBB startups built their exchange from the ground up. They blazed a trail, this new startup is simply following in the path that’s cleared for them.

Enter Wardley Maps, a way to visualize the evolution of the underlying landscape anchored to the needs of users. When we map out the Digital Beanie Baby trading landscape, including high level components/requirements of a DBB exchange, we start to see that a number of core components of the exchange are available for purchase, leasing, and/or open source. After all, exchanges have been around quite a while in various forms.

Based on the product development approach the Beanie exchange startup is taking, we’d expect to see most of the exchange components and requirements in the “Custom-Built” or “Genesis/Novel” lane, but instead a majority of the core exchange features in development (highlighted in blue) fall into the “Product/Rental” lane or very close to it. What does this tell our startup? It’s telling them that the bulk of what they’re currently developing is something that has (probably) been built before and is available to buy, lease, or simply use (open source).

A common objection I hear at this point is: OK, but what if you’re wrong about the position of various items on the map? That’s quite possible. The potentially incorrect map positioning can drive meaningful discussions as well as further research to either validate or invalidate the position. The beauty with the map is that we’re: A) having the product/business strategy discussion based upon a shared visual aid and context B) able to identify our assumptions. In the case of our startup example, the biggest areas likely up for debate are core components (that they’re creating themselves) like the matching engine, order book, API, web app, etc. Maybe with some further digging the discovery is made that commercial offerings exist, but they’re immature, or expensive, or rigid, or any number of other issues that may make them less viable as options. Maybe we find that certain components are available as products, but are only really suitable for more traditional exchanges, not for those aimed at trading digital beanies. It’s also possible that we discover there are numerous existing components and products that fit our needs and validate the position of those items on the map.

The Wardley Map provides a higher level view that can help drive lower level product development decisions.

Another objection I’ve heard is that what I’m crediting to Wardley Maps is really just another path to market research that any business should already be doing. Possibly, but the map provides a shared context that market research does not commonly provide, as market research tends to end up buried in docs and slide decks. A group of people can look at a Wardley Map together and start to quickly identify areas of alignment, disagreement, opportunity, etc. Those with more industry expertise can be brought in to look at the assumptions on the map and determine if those assumptions are on track or need adjusted.

In our startup’s case, the map identified some potential blindspots in the product development approach. Should the exchange startup be building something from the ground up that is already available for purchase, rent, and/or adoption? Unless the devil is hiding in the details of those components mapped in the product lane, then it’s unlikely the startup should pour further (fairly limited) development resources into those items. 

It makes more sense for the startup to consider focusing its development time and talent on building items in the novel or custom lanes. Or, possibly focus the engineering team on implementing the items in the product lane, become experts on operating those in production (much sooner than the homegrown equivalent would be available), and then discover through real customer feedback what should be introduced on the exchange next. The possibilities the map opens up are much greater than what development teams tend to consider when they’re building a product, such as, should we: Scale back feature X, Y, Z? Reprioritize the backlog? “Pivot” to target only one subset of customer initially? Change our approach to development in order to increase velocity and lower time to market? Reset some or even all of our goals for the MVP? Those are all legitimate options to consider in product development, but they may be too nearsighted and ultimately limiting. A startup is particularly sensitive to this form of myopia, as the business and product the startup is building are so tightly coupled, it can be hard to determine where one ends and the other begins. The Wardley Map provides a higher level view that can help drive lower level product development decisions.

Adding Wardley Maps to a product development team’s toolbox is a valuable asset, even if at a first glance it’s hard to understand how. Mapping is not a silver bullet or even a tool that is immediately easy to grasp, but it’s worth learning. This example only begins to touch on all the nuances of Wardley Maps. There are many other nuggets of strategy gold to be found for those who take the time to learn how to create and collaborate with these maps.