In May 2019, I gave a talk at GlueCon, “Can We Trade Derivatives of Technical Debt?” The purpose of the talk wasn’t to answer the question literally. It was a way to rethink the tech debt analogy, where it’s gotten stuck, and where we can re-frame the analogy to have a useful conversation between technical teams and business stakeholders. I’ve published about understanding the risk profile of your technical debt separately. Here, I’ll define the terms of players needed to explore the derivatives side of the analogy.
Before we can extend the “tech debt” analogy to derivatives trading, we need to establish a few things. …
For better or for worse, I’ve become an abstract-writing machine over the years. Whether it’s from writing my own abstracts for conference CFPs, or ghost-writing webinar abstracts for others, I’ve drafted a lot of abstracts. I’ve settled into a bit of a formula.
No one likes to admit they like formulaic writing, but it means that I can quickly churn out an abstract. When I follow that formula, I know that I’ve covered the key parts. Things can still go wrong, but I haven’t missed an important element. It’s also a check against belaboring a single point in an abstract.
In this article, I’m going to share some examples from abstract’s I’ve worked on with teammates. I’m not saying they are perfect. …
Call it confirmation bias (it is), but at SpringOne Platform I couldn’t help but notice new examples of “The Secrets.” This growing list of “secrets” are patterns across companies digitally transforming using PCF. They surface as I listen to Pivotal’s customers describing their journeys, but they transcend vendor. Anyone leading a digital transformation journey can take note.
Here’s my observations from user talks at SpringOne Platform 2018, mapping back to these patterns.
1. Give teams space to change
This initially came to my attention as Pivotal customers highlighting the importance of doing the Pivotal Dojo. But it applies regardless of vendor. It’s really about making any change to a team. …
UPDATE: You can now watch a talk version of this article from Monktoberfest 2018. See link at the end.
There are certain universal human experiences that transcend cultures. The birth of a child. The coupling of two people in marriage. And death. From baptisms to burials, how we handle these moments is a reflection of our culture.
For better or worse, how death is dealt with leaves a lasting legacy that we can study. You can learn a lot about a culture — a mindset — by how people treat their dead. In medieval Europe, bodies were buried intact, facing east, so that they could rise facing Jerusalem upon the Resurrection. In Judaism, the dead are typically buried within a day and are never left unattended until burial. …
Day 2 at SpringOne platform was a whirlwind of keynotes and more user-led breakouts than one can physically attend. I’m always on the look out for patterns in how users are adopting technologies. This time, I looked for the behaviors to avoid: the anti-patterns.
When the rubber meets the road for kicking off a change to your software practices, you need people. This could be for standing up your PCF platform ops team, or just building a DevOps team in general. Assembling that team might feel like you’ve got to assemble The Avengers.
But modeling your DevOps team on The Avengers is an anti-pattern. Why? Three reasons came up during day 2. …
1100 deploys a month. 50% improvement in time to market. Same day bug fixes with no downtime. 1500 production services. MVP prototypes in four weeks. The measured effects of using Cloud Foundry (and associated people and process changes) are compelling.
But how did they get there? After all, change is hard. Picking the platform is the easy part. How did they get started? How did they gain momentum?
At the Cloud Foundry Summit in Santa Clara last week, each company had it’s own story. But after two and a half days of keynotes and presentations, some patterns emerged.
Where to start? For writers, it’s the torture of the blank page. For platform operators? It’s the torture of having selected Cloud Foundry, but not yet having it running.
One word came up again and again from users that had achieved escape velocity: dojo. A “dojo” is literally a martial arts studio, where students train and practice. It’s not the actual place of battle, and the training is as much mental as it is physical. At Pivotal, it’s a 6–8 week engagement that’s more about teaching teams *how* to use the platform than just installing it. …
Every week in our briefing center, we talk to companies about unlocking the potential of their data, and the same question crops up. I often find some version of it in the pre-brief document I get as a regular speaker for these data overview sessions. But it’s usually the same: “How can we monetize our data?”
While I’m excited to talk to companies about the possibilities for their data, I find that trying to answer that question directly misses the real question: What problems can you solve — or solve better — with data?
Looking at data in isolation from the problems it could help solve is a widespread misstep made by organizations. Nick Heudecker, research director at Gartner, recently noted that “the big issue is not so much big data itself, but rather how it is used. While organizations have understood that big data is not just about a specific technology, they need to avoid thinking about big data as a separate effort.” …
The gloves came off this week. At Gartner’s Catalyst conference in San Diego the message in the big data track was loud and clear: go to the cloud *now*. From Carlie Idoine’s session, “From Data to Insight to Action: Building a Modern End-to-End Data Architecture”, to Svetlana Sicular’s “Implementing Data Lakes and the Ocean of Big Data in the Cloud”, to John Hagerty’s “Architecting Business Analytics in the Cloud: SaaS, PaaS and IaaS”, the opinion of many esteemed analysts was distinctly clear and consistent: Cloud is no longer an option in your data architecture; it is a requirement.
As a history major at UCLA, I often faced the question, “so, what are you going to do after college? Teach?” Just as Daniel Schmidt wasn’t thinking about his career when he chose a philosophy major, I wasn’t picking my major as a future job description. I was passionate about history, and I was good at it. That’s a powerful combination for producing good work.
When looking for my first job after graduation, I used “research” as my search term — it was a skill I had developed and enjoyed using. That’s what led me to “equity research”: first, as an assistant, and then, later, as an associate analyst. In total, I spent 6.5 years in equity research, using skills I had developed as a history major every day. …
About