Break From Burndown: The Memorial Day Spring Bank Holiday Break

Tech Debt Burndown Podcast

Player FM - Internet Radio Done Right

four 年前前追加した

コンテンツは Chris Swan and Nick Selby によって提供されます。エピソード、グラフィック、ポッドキャストの説明を含むすべてのポッドキャストコンテンツは、Chris Swan and Nick Selby またはそのポッドキャストプラットフォームパートナーによって直接アップロードされ、提供されます。誰かがあなたの著作物をあなたの許可なく使用していると思われる場合は、ここで概説されているプロセスに従うことができますhttps://ja.player.fm/legal。

This Is Woman's Work with Nicole Kalil

1
QUALIFIED: How Competency Checking and Race Collide at Work with Shari Dunn | 284 33:58

約 8 日前33:58

「あとで再生する」

リスト

気に入り

気に入った

33:58

In this episode, we delve into the concept of being "qualified" in the workplace, examining who gets labeled as such, who doesn't, and the underlying reasons. We explore "competency checking"—the practice of scrutinizing individuals' abilities—and how it disproportionately affects underrepresented groups, often going unnoticed or unchallenged. Our discussion aims to redefine qualifications in a fair, equitable, and actionable manner. Our guest, Shari Dunn , is an accomplished journalist, former attorney, news anchor, CEO, university professor, and sought-after speaker. She has been recognized as Executive of the Year and a Woman of Influence, with her work appearing in Fortune Magazine, The Wall Street Journal, Ad Age, and more. Her new book, Qualified: How Competency Checking and Race Collide at Work , unpacks what it truly means to be deserving and capable—and why systemic barriers, not personal deficits, are often the real problem. Her insights challenge the narratives that hold so many of us back and offer practical solutions for building a more equitable future. Together, we can build workplaces and communities that don’t just reflect the world we live in, but the one we want to create. A world where being qualified is about recognizing the talent and potential that’s been overlooked for far too long. It’s not just about getting a seat at the table—it’s about building an entirely new table, one designed with space for all of us. Connect with Our Guest Shari Dunn Website& Book - Qualified: https://thesharidunn.com LI: https://www.linkedin.com/today/author/sharidunn TikTok: https://www.tiktok.com/@thesharidunn Related Podcast Episodes: How To Build Emotionally Mature Leaders with Dr. Christie Smith | 272 Holding It Together: Women As America's Safety Net with Jessica Calarco | 215 How To Defy Expectations with Dr. Sunita Sah | 271 Share the Love: If you found this episode insightful, please share it with a friend, tag us on social media, and leave a review on your favorite podcast platform! 🔗 Subscribe & Review: Apple Podcasts | Spotify | Amazon Music…

約 4 年前

MP3•エピソードのホーム

Recording date: May 29, 2021

Download at Apple Podcasts, Google Podcasts, Spotify, iHeartRadio, Spreaker or wherever you get your podcasts.

“They were told observability would solve their problems, but it didn’t, so what the @$^#?” - Charity Majors

It’s Memorial Day weekend in the US and Spring Bank Holiday in the UK, so Chris and I have decided to fire up the grills and get away from it all and enjoy the weekend. So we took a break this week. Coming up in the next few weeks we have conversations about ops, toil, build times and observability with Charity Majors, and we’ll take a look at both the academic side of things and strategies for tech debt reduction with Eoin Woods

Then a look with Yosef Lehrman at the Biden Executive Order and what it means for government and private sector organizations, we’ll talk SBOMs with Allan Friedman, and much, much more!

We hope you’ll join us on these upcoming episodes of Tech Debt Burndown Podcast - have a great weekend.

17 つのエピソード

#Tech #Tech News #Chris Swan #Nick Selby

Break From Burndown: The Memorial Day Spring Bank Holiday Break

Tech Debt Burndown Podcast

published 約 4 年前

MP3•エピソードのホーム

Recording date: May 29, 2021

Download at Apple Podcasts, Google Podcasts, Spotify, iHeartRadio, Spreaker or wherever you get your podcasts.

“They were told observability would solve their problems, but it didn’t, so what the @$^#?” - Charity Majors

Then a look with Yosef Lehrman at the Biden Executive Order and what it means for government and private sector organizations, we’ll talk SBOMs with Allan Friedman, and much, much more!

We hope you’ll join us on these upcoming episodes of Tech Debt Burndown Podcast - have a great weekend.

17 つのエピソード

#Tech #Tech News #Chris Swan #Nick Selby

すべてのエピソード

1
Tech Debt Burndown Podcast Series 2 E4: Gene Spafford

1 year前

—

Recording date: Apr 17, 2023 Download at Apple Podcasts , Google Podcasts , Spotify , iHeartRadio , Spreaker or wherever you get your podcasts. “They’re statistical models based on language corpuses and the output of these things can be shown in some cases to be stunningly incorrect.” - Gene Spafford Gene opens with a comment about the “tendency of the industry to jump on hot trends”, and that sets the scene for much of the discussion, which goes on to touch blockchain, and of course ‘AI’. We touch upon topics where Gene and his co-authors go into more detail in Cybersecurity Myths and Misconceptions such as where liability should be placed to better incetivise the creation of spftware that’s safe, secure and reliable. Though Gene acknowledges that we don’t (yet) even have good metrics for those terms. That leads into some discussion on whether organisations like the Open Source Security Foundation ( OpenSSF ) can fill some of the gaps. Before closing we get to some discussion of the European Union Cyber Resiliance Act (CRA) and some of the consequences that might have for open source software.…

1
Tech Debt Burndown Podcast Series 2 E3: Jamie Dobson

2 years前

—

Recording date: Apr 1, 2022 Download at Apple Podcasts , Google Podcasts , Spotify , iHeartRadio , Spreaker or wherever you get your podcasts. “When you frame technical debt through the lens of strategy, it actually starts to make a lot more sense” - Jamie Dobson With intros over we ask Jamie about his experience with cloud native transformation. He sees many companies who have made a mess of their cloud migration. They have created a lot of technical debt, which can make it difficult to innovate and can lead to security problems. Jamie says that the best time to do a do over is when you realize that your cloud migration is not working. However, he acknowledges that this is a difficult decision to make. People often feel like they have invested too much time and money in their current system to change it. However, it is often better to start over than to continue down a path that is not working. Jamie then talks about how to approach cloud native transformation from a strategic point of view. He says that it is important to understand the company’s goals and objectives before making any decisions about cloud migration. Once you understand the company’s goals, you can then start to think about how cloud native computing can help you achieve those goals. Jamie concludes by saying that cloud native computing is a powerful tool that can help companies to innovate and grow. However, it is important to approach cloud native transformation in a strategic way in order to get the most out of it.…

1
Tech Debt Burndown Podcast Series 2 E2: Andy Ellis

2 years前

—

Recording date: Feb 14, 2022 Download at Apple Podcasts , Google Podcasts , Spotify , iHeartRadio , Spreaker or wherever you get your podcasts. “Stop calling it technical debt” - Andy Ellis With intros over, Nick asks Andy about metrics, and Andy immediately responds by saying “stop calling it technical debt”. Executives have an understanding of ‘debt’, and it’s not a bad word for them, it’s what fuels everything around them. This leads into discussion of when’s the right time to ship software. Something unfinished might feel too early, but how else do you get feedback from users? “Risk is the net present value of bad things happening in the future” We then get into Andy’s model of deferred risk, and how that can drive a conversation about what to do now, and what to put off until later. This eventually takes us to talking about Dungeons and Dragons alignment charts, and how it’s good to have a diverse team who bring a variety of viewpoints. Andy then gets into how people want to quantify risk, but often that’s impossible. But there are ways to position risks in a visualisation, which can help people reason about the range of risks they’re dealing with. When it comes to assigning resources to the work on risk mitigation Andy runs through some approaches that have worked for him, which include ‘borrowing’ people to get things started then ‘giving them back’ to ensure that the effort is sustained. That brings us to our close, with Nick complaining about the knives in his house being dull, even though his son makes and sharpens knives……

1
Tech Debt Burndown Podcast Series 2 E1: Krysztof (Chris) Daniel on Strategy and Wardley Maps

2 years前

—

Recording date: Jan 24, 2022 Download at Apple Podcasts , Google Podcasts , Spotify , iHeartRadio , Spreaker or wherever you get your podcasts. “When they have figured out what this game was really about, they figured out what should be the response” - Krysztof (Chris) Daniel After intros we start by asking Chris why he got the @wardleymaps Twitter handle, and he explains that he was doing an entrepreneurship course that got him interested in Wardley mapping; and from that he went on to develop an online tool to help people make maps. We then chat a little about Chris’s work at the Leading Edge Forum (LEF), where he works alongside Simon Wardley. Nick speculates that mapping hasn’t really made it to the US yet, but Chris points out that there are already vibrant communities in the US before giving an overview of the Wardley mapping technique. He then illustrates the approach using a customer case study. This gets into the customer not really knowing what they had (in terms of assets) until they went through the mapping process. The conversation then turns to situational awareness, and whether that’s a predominantly military concept. Given that there are plenty of veterans about (particularly in infosec), why is it that situation awareness isn’t used more in companies? We then get into how maps can be used to understand tech debt in organisations. In particular how assets in the value chain that have become debt can be examined for change. That leads into a discussion of the elements of (awkwardly named) doctrine, and where they fit into the overall strategic picture. Before closing, discussion moves on to corporate structure, which relates to Wardley’s pioneers, settlers and town planners (PST) model.…

1
Tech Debt Burndown Podcast Series 1 E12: Yosef Lehrman on the Executive Order

4 years前

—

Recording date: Jun 14, 2021 Download at Apple Podcasts , Google Podcasts , Spotify , iHeartRadio , Spreaker or wherever you get your podcasts. “The executive order puts on paper for the very first time, a mechanism for the federal government at least to outline how they plan on shoring up their cybersecurity and more importantly, a framework that others whether it’s commercial entities or state, local, tribal, territorial governments could follow and build upon.” - Yosef Lehrman Yosef first introduces himself, and his role as Deputy Commissioner of Information Security and Chief Information Security Officer at New York City’s Department of Information Technology and Telecommunications . We describe Yosef as one of the best people to talk to about the 12 May Executive Order on Improving the Nation’s Cybersecurity . After disclaimers about not speaking on behalf of the department etc. Yosef outlines the purpose and importance of the Executive Order as “a roadmap for improving National Cybersecurity and also for protecting federal government networks”. The two key points are outlined as: Information sharing A plan to move towards a more secure architecture (using multi factor authentication, zero trust architecture etc.) We then touch upon the software bill of materials (SBOM) content of the order, and the fact that secure software development and supply chain security are different things. Yosef draws parallels with the work of the National Transportation Safety Board (NTSB) and its work in investigating accidents. This leads to further discussion of the value and challenges in accreditation, and how it can be a double-edged sword. Nick then asks how the changes are going to be funded, given that many agencies have struggled for IT budget, which is often seen as the cause of tech debt. Yosef points out that there’s no clear link to funding. For that reason it’s going to take time to implement, and will need strong leadership to be successful. This runs into some discussion of the challenges with cutting over services that can’t be taken down, but how that does get achieved with things like 911 call centres. Yosef also sees the order as an opportunity to drive incrmental improvements that might fit into regular upgrade and refresh cycles. He also sees an opportunity with the shift from products to services, which leads to some discussion of public sector cloud adoption. We wrap up with some discussion on how information sharing between agenecies has improved, with more happening in the open and available to all comers. Season One finale.…

1
Tech Debt Burndown Podcast Series 1 E11: Allan Friedman and SBOMs

4 years前

—

Recording date: Jun 8, 2021 Download at Apple Podcasts , Google Podcasts , Spotify , iHeartRadio , Spreaker or wherever you get your podcasts. “Having a list of ingredients doesn’t mean that you’ll eat healthy, but it’s very difficult to eat healthy if you don’t have that” - Allan Friedman After introducing himself, and his role at the National Telecommunications and Information Administration ( NTIA ), Allan gives an overview of Software Bill of Materials ( SBOM ) using a ‘list of ingredients’ analogy. The efforts around SBOM have been underway since 2018, and there was initially pushback from the software industry, in part because organisations didn’t have their open source licensing in order. As the NTIA has gone through the process of creating a consensus vision around SBOM, many of the original detractors have found that it provides a reason to clear up stuff that needed doing anyway. Allan goes on to provide an example of how an SBOM gets used as a proxy for understanding total cost of ownership for software, and how that can be used as a negotiating lever. Vulnerability management, and understanding how most modern software is composed (largely from open source) rather than created from scratch is a central part of the utility of SBOM, so that software users can understand where weaknesses originate from. We then go on to discuss the positioning for proprietary software, touching on the ‘black box’ problems that arise, particularly in environments that demand high levels of accreditation like healthcare. Allan talks about the list of ingredients not meaning that anybody can replicate something, which reminds Chris of the UK TV show Snackmasters where celebrity chefs struggle to reproduce popular snacks. This leads Allan into some description of the challenges dealing with a lack of a global namespace for software. We then move to some discussion of the 12 May Executive Order on Improving the Nation’s Cybersecurity , which sets the ball rolling for SBOM implementation in Federal Government: (f) Within 60 days of the date of this order, the Secretary of Commerce, in coordination with the Assistant Secretary for Communications and Information and the Administrator of the National Telecommunications and Information Administration, shall publish minimum elements for an SBOM. After talking about the difference between ingredients labels and nutritional information labels the conversation turns to how difficult it is to understand what compilers will produce from source code. This is a familiar problem for Chris, who’s previously examined how compilers can produce startlingly different output for seemingly trivial and functionally identical source code The compiler will not save you . Before we wrap up, Allan notes that there was a chicken and egg problem with SBOM and the tools to produce an SBOM, but that’s largely addressed now by new companies and products emerging to fill the need; along with existing products growing additional capabilities.…

1
Tech Debt Burndown Podcast Series 1 E10: Eoin Woods 25:58

4 years前25:58

25:58

Recording date: May 25, 2021 Download at Apple Podcasts , Google Podcasts , Spotify , iHeartRadio , Spreaker or wherever you get your podcasts. “There’s sometimes an assumption that people in the business of building systems all the time implicitly understand tech debt. I think they definitely don’t.” - Eoin Woods After intros we ask Eoin about the International Conference on Technical Debt, which recently had its 4th annual event . Eoin was a keynote speaker at the first conference , and has stayed involved since. Eoin goes on to explain that the academic community have found ways to collect data on tech debt that have evaded many practitioners, which has brought fresh insights onto the problems and how they might be addressed. Nick asks about the Preventing Technical Debt by Technical Debt Aware Project Management paper from Hamburg and whether “can it be this easy?"; and Eoin replies that in the SEI book on Managing Technical Debt , “it’s one of the key practices”. After a spot of collective JIRA bashing, Nick asks Eoin about the Security Debt: Characteristics, Product Life-Cycle Integrations and Items paper, describing it as “fully buzzword compliant, talking about shift left and everything like that”. Eoin observes that security related tech debt gets special treatment, “it’s rather more urgent to fix, because you may not understand all the possible implications of it”. He goes on to say that security has become more popular as a topic at conferences over the last 10 years or so. Chris asks Eoin for one of his favourite examples of tech debt from the past, which leads to a description of an old Unix transaction processing monitor, and a giant C/C++ code base that grew around it. He talks about a colleague making good progress, but the sense that they weren’t actually winning. Eoin then talks a little about lessons from his book Continuous Architecture in Practice , and goes on to describe how people often get stuck on a data model that’s not quite working. Chris then asks Eoin about practices he’s currently using to handle tech debt, which leads to “It very much depends on the environment, I think the key thing that we try and encourage everyone to do is to make sure that you’re running enough analysis on your code regularly, that you can spot trends and changes.” We conclude with a promise to link to Eoin’s book on Software Systems Architecture that he co-authored with Nick Rozanski, so there it is.…

1
Tech Debt Burndown Podcast Series 1 E9: Charity Majors

4 years前

—

Recording date: May 19, 2021 Download at Apple Podcasts , Google Podcasts , Spotify , iHeartRadio , Spreaker or wherever you get your podcasts. “If you want to do something better it’s best you name it, and try to understand it, not sweep it under the rug and pretend it doesn’t exist.” - Charity “Where is the time going? Are your people spending 80 percent of their time on crap that doesn’t move the business forward? Crap that is toil, that is miserable, that should be automated away? Or are they spending 80 percent of their time on stuff where they’re creatively solving problems, that moves the business forward?” With her work at Honeycomb , Charity is now known as a leader - Chris said, “the queen” - in Observability. “I have learned that if you can’t see what’s going on, you’re fscked,” Charity tells us, “So much of what we are doing in tech is the hard way. It can be so much easier.” Chris begins with Charity’s definition of “Ops”, which he says is the best he’s heard. We then ask Charity about technical debt, which Charity feels are the investments you make to get to the next step in your business. One thing Nick finds interesting is that Charity’s idea is that there can be good debt in life (like going to college and learning life lessons) and bad debt in life (like using a high-interest credit card to buy a big flat screen TV) and in the same way there are tech debts that are good and bad. It’s about doing tech debt deliberately. “We should all be so lucky,” Charity says, “as to survive so long as to have to deal with our choices.” It’s about making the correct investments. So much of the complexity of the application is now bound up in the operations. That means we need to have full ability to see within each aspect of the operations to see what is happening. Charity discussed her work at Facebook using a tool called Scuba , and how its capabilities made a huge impression on her. After Facebook, Charity realized that she couldn’t engineer without this kind of visibility, and established Honeycomb. Charity said the term came from mechanical engineering, and politely says they are rather chuffed that so many people have begun to use the term for essentially all visibility. In the beginning Honeycomb thought it would be a niche thing, but it seems that most people in all kinds of ops are finding this useful, and the company is doing very well. Nick mentioned that industry marketers have co-opted the term in the same manner that Big Ag has co-opted the term “Organic” - “Observability” now is applied to any kind of visibility/telemetry tool. Chris asks how customers are using observability to understand their tech debt, and like a good CEO, Charity replies that it isn’t that It helps with tech debt, it’s that it helps with everything - but especially around understanding how your code feels to users, and shines a light on tech debt by helping the humans understand how they are spending their time - on toil, or on creatively solving probelms to move the business forward. Nick asks about metrics of tech debt, and how you separate toil and misery form good work. In addition to echoing us on Dora metrics, Charity suggests that the best metric of performance as a generic signal is how often you get pulled in after business hours to solve problems. But more broadly, if you can’t ship your software using CI/CD in 15 minutes - you have an idea and a few minutes later you are looking at it live - if you can’t do that very quickly, within the golden interval, that is the most important thing any technical leader can do, setting it up so that the pathologies don’t have the time to creep up and overwhelm your team. And that is often not an engineering problem, it is one of political will.…

1
Break From Burndown: The Memorial Day Spring Bank Holiday Break

4 years前

—

Recording date: May 29, 2021 Download at Apple Podcasts , Google Podcasts , Spotify , iHeartRadio , Spreaker or wherever you get your podcasts. “They were told observability would solve their problems, but it didn’t, so what the @$^#?” - Charity Majors It’s Memorial Day weekend in the US and Spring Bank Holiday in the UK, so Chris and I have decided to fire up the grills and get away from it all and enjoy the weekend. So we took a break this week. Coming up in the next few weeks we have conversations about ops, toil, build times and observability with Charity Majors , and we’ll take a look at both the academic side of things and strategies for tech debt reduction with Eoin Woods Then a look with Yosef Lehrman at the Biden Executive Order and what it means for government and private sector organizations, we’ll talk SBOMs with Allan Friedman, and much, much more! We hope you’ll join us on these upcoming episodes of Tech Debt Burndown Podcast - have a great weekend.…

1
Tech Debt Burndown Podcast Series 1 E8: The Six Ways

4 years前

—

Recording date: May 17, 2021 Download at Apple Podcasts , Google Podcasts , Spotify , iHeartRadio , Spreaker or wherever you get your podcasts. “Everybody wants to reduce tech debt, but nobody wants to pay for it.” - Olivier Nick and Chris are joined by Olivier Jacques, a Distinguished Technologist at DXC and CTO in DXC’s application services department in France. Recently, Jacques wrote 6 Strategies to Set Time Aside to Improve , an article that spells out six ways to approach technical debt reduction. Olivier thinks that policy debt, technical debt, security, debt, infrastructure, debt, and other debt types are something that must be paid attention to, but he was wondering why we don’t seem to have the time to address them - we are either too busy, or we don’t have the management support, or sometimes we don’t even know where to start and what do we improve. So he set out to write up some strategies he feels will help. Following recent conversations, I wrote an article on "6 ways to set time aside to improve". https://t.co/zJz5CgxQH5 — 🌤️livier Jacques (@ojacques2) May 5, 2021 We don’t easily know where to start, but he thinks where he saw the biggest struggle was perhaps in explaining to management and leadership what it meant to reduce tech debt, and how to organize a team to make sure that ted debt is not something put on the back burner and forgotten. First, Olivier came up with The Six Ways, but he wants to be clear that after hearing from many readers, he isn’t saying there are only six ways - we can definitely add many more. In setting them down, Olivier created two buckets of activity: Work (W) and Improvement (I). He models his Six Ways on the example of the agile scrum team, running in a two-week sprint cadence. And within those two weeks’ worth of sprint, the question is, within this cadence, how can we build in time for I while conducting W. He makes the assumption is that there is a commitment somehow somewhere, maybe by idea, the product owner or the leadership to explicitly say that they want to improve, and they they are willing to spend 25% of their capacity to do just that. Again, this is a rule of thumb; some teams may not need to spend that amount of time to reduce technical debt. And some teams may be in a state where they actually need to spend way more time in reducing tech debt. The First Way A twenty-five percent improvement on top of everything else. This is not a place where you want to be, because you end up having a very extensive days, obviously, but, but at the same time, it’s very often the expectation from management. There’s often a sort of base-case assumption as the team is just taking care of managing tech debt on the, on their own. Some of the engineers I’ve been speaking to in the past few weeks feel strongly feel that it’s their responsibility to manage tech debt – that this management shouldn’t be actively visible to product owners or other forms of management. The Second Way This may be an anti-pattern, but the Second Way is spending 100 percent of your time improving. Olivier calls it Panic Mode. The Third Way Say you’ve got a natural slump in the business cycle at your company, or just a period where it is natural to slow down; you might consider spending 100% of a sprint on burndown. The Fourth Way The fourth approach is the Rolling Improvement model. In this strategy, we, we spread evenly who is going to work on improving technical debt. Olivier made a simple algorithm that basically has all engineers spending 25% of their time within a given sprint on tech debt, staggered so that most of the engineers are on their 75% of normal work while a small portion dips into and out of the 25% burndown role. Nick likes this one, because it lets us not feel like we are throwing our hands up in despair and saying that nothing works, which executives don’t like to hear and, frankly, they’re right in saying that, but it also allows engineers to tend to the garden of things that need to be tended while folding in normal work; he thinks it’s a little bit less disruptive than some of the others Ways. The Fifth Way The fifth way is that everyone spends 25% of their capacity each day – two hours of every eight - on improving. All three like the idea, but Nick points out that it assumes that engineers have eight hours a day to code, which is fantasy. He mentions the large and increasing burden of meetings (citing specifically Steve Glaveski’s terrific article, The Five Levels of Remote Work — and why you’re probably at Level 2 ) means that you never really have anything near eight hours. Chris mentions the current joke about “ this meeting could have been an email ”, and Olivier says that too much work in progress is really terrible for flow. He cites Joel Spolsky’s classic 2001 essay on the subject, Human Task Switches Considered Harmful . Which brings us to The Sixth Way One sprint of four focuses on tech debt burndown. This is Olivier and Chris’ favorite, and Olivier says he can really rally the team around this vision. They started really looking forward to this one sprint every four that is totally focused on improving and reducing technical debt. No interruption, unless a catastrophe arises, and we get management back up to, to really say, yes, this sprint, we understand you are working on the reducing technical debt.…

1
Tech Debt Burndown Podcast Series 1 E7: Enabling and Regulating

4 years前

—

What Do Enabling-Teams Look Like, and Can We Avoid Tech Debt in the Medical Device Industry? Recording date: May 3 and 8, 2021 Download at Apple Podcasts , Google Podcasts , Spotify , iHeartRadio , Spreaker or wherever you get your podcasts. ‘There were monkeys that were nesting in the satellite dish.’ - Kenn In a private Twitter chat, Nick and Kenn White, who leads applied encryption engineering in MongoDB , were discussing tech debt burndown, and Kenn mentioned that Mongo maintains an entire team to remove distractions and handle barriers to engineer happiness. So this episode, Kenn joins Chris and Nick to talk about that, because Chris had been mentioning enabling teams in the past couple of episodes. Mongo recognized that when something takes one person two or three or four hours of frustration, that’s real money when you’re talking about three or four or 500 engineers. The Developer Productivity Team at Mongo set out to assure that everyone has on day one a fully functioning and configured Linux laptop, with all the tools, libraries, permissions, etc., that they will need on day one. This includes wikis and internal resources. That “get out of the engineers' way” approach is what Chris has been describing, and this is a real life example. Kenn mentioned 10,000 to 20,000 hours of testing on every build, so it’s expensive if a build fails. The way Mongo has approached this supports that kind of environment. This extends down to “I can’t make Ruby 3.6 work on this particular Linux flavor” and the enabling team will tackle those kinds of problems. But when we sought answers on metrics, they seem to elude Mongo as much as anyone else, saying that metrics are divorced from real productivity; Kenn boils doing what works down to what makes engineers happy. That’s not a bad metric. He says that the trick for his teams has been post mortems on every major project to find the tar pits and management pains in the butt, the lack of approvals (he puts a lot of emphasis on getting expense reports reimbursed quickly, which is another one we like), etc., and those lessons are iteratively applied. The group began to follow a thread that had begun pre-show, about Kenn’s early jobs re-factoring cardiac monitoring software, but went off on a tangent that, while interesting (to us), was off topic. Which is where the quote about monkeys nesting in the satellite dishes, above, came out (it was a story about on-the-ground realities in an African networking project). But Chris and Nick were very interested in medical device manufacturing issues: if you’re in an industry that is heavily regulated to the extent that you can’t make changes to anything once launched, and at the same time, the industry makes machines that can spend decades in the doctors' offices. How do you avoid tech debt if it is almost mandated by the law? To answer this, we brought in Bill Pelletier, who has tons of experience in exactly this area. Bill sets out a recent history of medical device manufacturing from custom hardware and waterfall processes through Software as a Medical Device and today’s builds. Once you peel back the fancy, shiny cover from a computerized tomography (CT) scanner, you are going to find commercial off the shelf, hardware, nothing special about it, and in many cases it is running off-the-shelf software operating systems, which is fine right up to the moment you put a network jack on it. That gets us into the meat of the problem: testing systems for these devices are designed for these big monolithic, all-encompassing, “test everything” processes which just doesn’t make economic sense in the new paradigm. Enter, over the past five or six years, the Software as a Medical Device. No longer constrained to this older hardware model, we were one step closer to more readily available software updates, using agile methodologies - but the testing regimes are still a huge barrier. This has led to the rise in recent years for calls for better software bills of materials, and pushes to require manufacturers to identify every software component with a standard taxonomy so that users can know immediately what’s inside. THe discussion turns to the realities of this struggle to balance security and software concerns with those of patient safety that, ironically, is often better maintained sticking with the known state - as in many critical environments, the bias is toward saying with the known good because the cost of being wrong is so high.…

1
Tech Debt Burndown Podcast Series 1 E6: The Flow

4 years前

—

What Does Your Pipeline Look Like? Recording date: May 1, 2021 Download at Apple Podcasts , Google Podcasts , Spotify , iHeartRadio , Spreaker or wherever you get your podcasts. ‘People often escape from a role before decisions they have made have a chance to catch up to them.’ - Chris Let’s talk about pipeline. Lots of things get improved by building continuous delivery pipelines and then going back to them and iteratively making improvements. But Chris thinks that pipelines themselves can be a place where we accrue tech debt, even at the entry point to those pipelines. So, Chris has been looking at branching strategies. If you look at open source development, people agree that trunk based strategies are the way to go, so we’re taking short terms branches or forks off a trunk, but coming back to it quickly. But engineers from an enterprise background have a range of versions across different customers. This quickly runs to vast differences between versions, and lots of tech debt. What suffers? Updates like security patches, and the engineers, who have to work across a multitude of branches as opposed to being on a constant edge of the trunk version, is pure tech debt. Nick mentioned that this seems to point back to engineer flow - if your engineers can’t get into the groove because they’ve got no institutional memory and they have to constantly figure out where they are in order to fix things, they’re actually creating tech debt while thy are addressing old tech debt! It’s interesting to think how we got here, but it’s true that, because people move around the industry, people, Chris notes, often leave a role before decisions they have made have a chance to catch up to them. So, decision logging becomes super important. But outside the code itself, the log and commit log that people add are critical pieces of context for the next people. All too often, though, they say things like, “Merge to master” or the dreaded, “Fixes”. After that, the readme and changelogs that go with things should tell a story, but there’s a more macro scale look at decisions people make: what were the tradeoffs that people had in mind when they made their decisions? This is absolutely critical to know. Because when we make decisions, thinking we can back out of them< we sometimes find ourselves in architectural cul de sacs. The conversation turns to Type 1-Type 2 decisions which Jeff Bezos began to discuss back in 1997. Nick gives as an example of what’s intended to be a reversible decision the log pipeline that his teams are working on. Chris Mentioned that pipeline engineering may seem to be less worthy work done, but Chris and Nick both feel that pipeline enabling work is among the most important in an organization. In carrying on the new tradition of references related to what we’re discussing, Chris comes up with two important areas of research: James Governor ’s work on RedMonk about Progressive Delivery , and Netflix’s work on Chaos Engineering . Nick mentioned also the SLSA: Supply-chain Levels for Software Artifacts proposal, which is an amazing project available now on GitHub. The SLSA (pronounced ‘Salsa") project is “inspired” by how Google does things (and has been at least updated by at least some people who work at Google), and ultimately will have a full set of standards, a catalog of technical controls , and a process for accreditation - but for now it’s a diabolically useful set of principles and definitions that are really worth a lot of time. One major point of the project is to be able to know and be certain about the provenance of code at every stage of the pipeline - at the very least to be able to attest to the sanctity of code, but also to, say, stop unauthorized people from being able to insert code into codebases (Heloooooo, Codecov Hackers !). Nick and his colleagues have begun to use SLSA as a great way - at a very minimum - to agree on a taxonomy and lexicon, and as milestones on their journey. Chris and Nick agreed that SLSA should be an episode in its own right, hopefully with a guest involved in its management to discuss it (hint, nudge, wink). The episode concludes with a pivot to a blog post by Signal’s Moxie Marlinspike who took on the mobile device forensics company Cellebrite. Cellebrite had earlier claimed it had “broken” Signal encryption, which was utter balderdash. In the information security community, the document quickly was called the Moxie Manifesto but it should be read as nothing short of a declaration of war against Cellebrite. Cellebrite customers (like law enforcement) are casualties of the war. Moxie shot back with what may be mistaken for a lighthearted report but which is both ruthless and credible based on his demonstrated exploitation of a Cellebrite box: Cellebrite uses very old software components as it assembles its tools, and has been lax about security patches for years; This is very plausible because the threat model faced by a Cellebrite box is one of someone with physical access to the box Cellebrite uses unlicensed components, with specific example of Apple Dynamic Link Library files; and Moxie claims that “Industry-standard exploit mitigation defenses are missing, and many opportunities for exploitation are present” Chris and Nick were both very interested by the manifesto and think it will be have a long tail.…

1
Tech Debt Burndown Podcast Series 1 E5: The Metrics

4 years前

—

How Do You Measure Tech Debt? What Are The Metrics That Work? Recording date: March, 2021 Download at Apple Podcasts , Google Podcasts , Spotify , iHeartRadio , Spreaker or wherever you get your podcasts. ‘I think it’s really less about wasted time, and more about getting into flow state: is your tech debt preventing flow from happening?’ - Chris How do you measure technical debt? What are the metrics you use? Chris hasn’t found the magic formula. Over the past few years Chris has been acutely aware of the quote from Accelerate about not trying to inflict metrics on people before the culture change happens, they’ll game the metrics. Nick agrees, and also says he has the basic problem that coming up with the right metrics is hard. They agree that time is a really bad one: trying to quantify tech debt around the time you spend on it actualy doesn’t work (though it’s not worthless). Some organizations build a bit of burndown into every sprint, but Chris isn’t seeing that widespread - but Nick says that after about a year, his shop is finding ways to do just that. It took a year of seeing the results of concerted bursts of burndown, and a company-wide Objective and Key Result (OKR) on Trustworthiness. One challenge he has is that it’s hard to tie in the minds of senior executives information security (which is what Nick does) to availability and scalability as opposed to firewalls. But his colleagues are making great progress. Nick thinks the most useful thing he’s done in the past year is to embed engineers, developers, SREs and security people into standups as often as possible to try and find the overlapping interests. And that has led to some success around thing together tech debt they need to code around and the performance of engineering squads. Chris spent a bunch of time recently looking at Chaos engineering and how to introduce it into what they do, but he’s finding that if you’ve not already got to the stage where you can do good quality progressive engineering you’re just not ready to do Chaos engineering. Similarly, Nick thinks that applies to Eng teams that find themselves working harder but not having a commensurate increase in productivity. What Chris sees in the bottom 50% of companies is related to a Charity Majors comment that they have the engine underwater and they have to work ever harder to see that they need to do something to drain the water that is flooding you. (i feel like that explains the lower 50% of the dora report 💔 they are bailing water out of the boat with all their might but not as fast as the water is coming in through the holes, so they never get the engine out of where it is submerged and cannot start up) pic.twitter.com/X2Izh53tex — Charity Majors (@mipsytipsy) June 10, 2020 When technical people have to talk to non-technical people about this, people who are smart but don’t see the tradeoffs in feature development, the non-tech people don’t understand the tradeoffs. Not that they don’t want to understand, but that they don’t see it. so the quest for metrics is really about finding Indicators Of Tech Debt. Chris points out that time is bad as a measure because for engineers, it’s really less about time and more about getting into flow state: is your tech debt preventing flow from happening? He mentions this is related to cognitive load, and that he’s been following the work of Team Topologies , whose principles Matthew Skelton and Manuel Pais have been spending years with organizations starting the DevOps topologies, finding patterns and anti-patterns and how work flows betwen those teams. They feel teams need to be organized to minimize cognitive load. It seems to be about putting boundaries around the members of teams so that they can actually apply their brain power to the problem at hand in the context of their work, and Chris thinks we can start to reason is that tech debt is adding a constant cognitive load that everyone has to deal with. This is a self-inflicted wound: rather than just doing a task, they have to remember oral histories of “when you’re trying to make something in this environment, here are the 24 undocumented things you have to look out for or they will bite you.” Nick and Chris raise the idea that tech debt is not necessarily just “old stuff” because mainframes are just often not tech debt, because they still work. Tech debt is more tied to the fragility of environments.…

1
Tech Debt Burndown Series 1 E4: Wendy Nather on What Works in Security

4 years前

—

What Works in Security? The Cisco Security Outcomes Study Recording date: December, 2020 Download at Apple Podcasts , Google Podcasts , Spotify , iHeartRadio , Spreaker or wherever you get your podcasts. Chris and Nick welcome their old friend Wendy Nather , Head of Advisory CISOs at Duo Security (now Cisco), to the podcast to discuss her work on the Cisco Security Outcomes Study . Now, technical debt isn’t only about security, but they’re related - and one of this report’s most solid conclusions addresses it specifically. When Wendy began her work at The 451 Group (now 451 Research ), she started asking her CISO friends questions: ‘If you’ve just taken a CISO job at a company that had no security, what would you buy?’ The answers fascinated her. Now at Duo (Cisco), she set out to formalize research that was released as Cisco Secure’s Security Outcomes Study. Security professionals are great at doing benchmarks, but it turns out that our peers may just be bad at security. So for this report, Wendy and her team sought a correlation between things we struggle with in security practices, and the outcomes of the programs they run to address those. The research was completely technology and vendor free. They queried security professionals (using YouGov to run the surveys) from around the world about their security practices across 25 areas, then brought in Wade Baker ’s team from Cyentia to analyze the data. The methodology is actually one of the best things about the report, because it is decidedly, simply put, not bullshit . The study was double-blind, with 4800 respondents not knowing who was asking, and Cisco not knowing who was answering. The question was, “What appears to correlate between security practices and outcomes?” As a great study will do, it raises more questions than it answers, but it also is a report that, by applying analytic rigor at the problem, it is just a great report. Nick points out that there are several issues that security pros take as gospel are just not true. We won’t spoil it but tropes about people who own compliance, people who own apps, security awareness, identification of the top cyber risks … All of these have very interesting real-world correlations to results. Meeting Compliance Regulations As it turned out, for example, having someone own compliance turned out to not be correlated with better compliance results, but just buying new IT gear raised the likelihood of success in meeting compliance goals by more than eight percent. Other activities correlated with better compliance outcomes included well-integrated tech, timely incident response, having a sound security strategy, and setting deadlines for remediating vulnerabilities… There’s lots more. Chris points out that this makes sense: those programs mentioned in having a positive correlative outcome are all about reaching across the organization and speaking with people. The Two Practices That Most Strongly Correlate Wendy is quite sensitive to the idea that the two practices identified as most likely to correlate to better outcomes, Proactive Tech Refresh and Well Integrated Technology, are of course seen by the more skeptical of us to have been directly driven by the fact that Cisco is a vendor of that stuff. Wendy insists (and Wade has insisted) that the double-blind nature of the survey administration and the analysis means that it actually was independently learned, not sponsored. We believe it. Wade tweeted about it recently: 2/2 My answer is always the same: A third party survey firm fielded the study, respondents didn’t know Cisco sponsored it, and @cyentiainst did the analysis to obtain that funding. I’m sure they like the outcome but they didn’t influence it. Get the study: https://t.co/ffYkfyhrf1 — Wade Baker (@wadebaker) April 24, 2021 Also, the survey didn’t ask, ‘Do you think buying new stuff makes stuff better?’ they asked separate questions. The correlations were stronger than they thought. What Works? But Chris happens to think that a lot of this is hogwash. Chris thinks that, as an example, tech refresh is already built in to the market (because virtualization and cloud), but Nick points out that Chris has lived five years in the future as long as Nick has known Chris, which is 16 years. He said that Chris, Wendy, and Nick have been very lucky, but that most people don’t have the ability to have contemporary kit and work in environments where spinning disks are still the norm. Nick also pointed out that “IT Refresh” is unclear - do we mean servers and firewalls, or laptops and printers? And Wendy pointed out that the questions were in fact vague: we don’t know whether the question means any or all of those things. Which supports the idea that a tech vendor didn’t put its thumb on the scale for this question. Sentiment Chris speculates that people who feel good about their company will say more positive things here. And there is a real discussion about whether shinier MacBooks help with talent retention and compliance success. Wendy says that some of this seems obvious, but some isn’t. How getting sufficient budget helps with executive buy in may well be a circular argument. Or take Identify Top Cyber Risks. That feels outlandish to Chris, who would have thought it would seem that identifying the top risks you face would be top of the list, and it turns out to be worthless. We think that the podcast is a good listen (well, we would ) and that the report is absolutely worth a read. We especially like that the report is available to read with no registration required .…

1
Tech Debt Burndown Series 1 E3: Supply Chain Vulnerability & Tech Debt

4 years前

—

Where do you start looking for tech debt? Recording date: April 17, 2021 Download at Apple Podcasts , Google Podcasts , Spotify , iHeartRadio , Spreaker or wherever you get your podcasts. This is a common question, and Chris and Nick discovered that they do it differently. Chris describes how he views tech debt from the perspective of his continuous integration and continuous delivery pipeline: “How quickly can I release, and what’s getting in my way?” He discussed that recently, Charity Majors has been discussing the importance of a quick feedback cycle for developers: people really do leave their jobs over build times. i am not making this up. the impact your deploy pipeline has on developer productivity and happiness is HARDCORE. https://t.co/z49xUxXWsk — Charity Majors (@mipsytipsy) April 15, 2021 Basically, this comes down to, ‘you’ve got 15 minutes to build’ in order to be good at this, and this brings us to the Theory of Constraints thing: what things are blocking me from getting to that 15-minute build time, and how do I get rid of them? Nick says he comes at this from a more traditional infosec approach, basically, how do I get in, how do I move around? Chris points out that this reveals two prevalent schools of thought in the industry when it comes to building software: “How do I make this work?” and, “How do I break this?” How do we make it work leads to “How do I make this resilient” Both of these approaches seem to meet up at resilience, which brings us to the broader conversion about software dependencies and dependencies management, which itself is based on the fact that today, “software is mostly assembled as opposed to being constructed fresh from a clean sheet of paper.” –Chris As we go about that process, we need to get open source, and buy tools, and many are pretty janky - and the janky tool is the one that gets you. Chris thinks there is better tooling coming, and Nick is far more skeptical of that. This gets into the fact that libraries get poorly maintained or abandoned and can in fact be taken over by malevolent actors, and now a trusted source is pushing malware. Everyone understands that but to what extent do you have proper insight to what you’re assembling? Supply chain breaches are top of the pops. But what are supply chain breaches? What’s going on? Supply chain attacks happen when people get into these dependencies, which are then incorporated, or they get into the build chain to insert software that shouldn’t be there. They can also be broader than just development operations, attacking necessary business tools that the company uses as a whole. Probably the earliest great example of this that we remember is the RSA SecureID breach of 2011 . Chris remembers that the term Advanced Persistent Threat was particularly bogus, because it isn’t the threat, it’s the attacker that is sophisticated and advanced (Nick throws in a plug for an article he and Scott Crawford wrote in January, 2010 called, ‘ It’s The Adversaries That Are Advanced and Persistent ') But there’s been a change in dynamics in the past few years - where it felt like the entire SecureID breach targeted Lockheed Martin, now it feels like “stage the attack first and then choose your targets" rather than choose your target and then stage your attack. If we are a contemporary software company or even a business, and we’ve done the right thing by outsourcing the stuff that isn’t our core competency, we find that there’s lots of stuff that isn’t everyone’s core competency - email servers, ticketing systems, remote helpdesk. So even though we all use a much more diverse set of universal tools, each tool in its category is just as much a single point-of-failure as was SecureID - we all use the same instant messenger, the same ticketing system, the same what-have-you, so targeting can be conducted on an industry vertical-level by attacking a tool that horizontally attacks the whole industry. How do we protect ourselves against these third party risks? Spreadsheets. Chris talks about the Hyperscalers like cloud and the starting point of the Shared Responsibility Model in which security and compliance are the shared responsibility between the hyperscaler and the customer. We’re now at a point where we rely on the Hyperscalers like AWS for security. Nick points out, though, that AWS has a different idea about what “secure” means from its customers - them being secure is just not the same as us being secure, and Chris rightly points out that this is the other side of the shares security model. But the point of handover is sometimes unclear to the customer. Many things that should be done are best practices are not enabled by Amazon by default, and this is a huge issue, which Chris points out is completely right and behind the idea that we read the dunderheaded thing of the week every week in Corey Quinn ’s Last Week In AWS newsletter. But if you want the audit trail, you need to flip the bit that starts the taxi meter to fill your other S3 bucket with logs. Adversaries Have OKR’s, Too In looking at attacks, it’s important to realize that attackers will always seek the path of least resistance as they target you - and often these days the path of least resistance is the tool. Chris mentions another Economics of Information Security Paper, Where Do All The Attacks Go? in which the question is asked, ‘If security is so awful, why isn’t everyone attacked every day?’ and the answer of course is that even attacker groups have bosses to please and budgets to live up to. Targeting is hard. Threat Model Your Supply Chain Tools So the idea to use supply chain attacks being in the news is to use them to justify the time it takes to consider something: given a supply chain attack against our CI/CD tool, what permissions would it have, and how can you follow those permissions throughout your CI/CD pipeline. All too often we bring in these external tools to cover up what we’re not good at, which would be fine if they were better than they actually are. Threat modeling through a theoretical supply chain breach can help you identify new forms of tech debt.…

プレーヤーFMへようこそ！

Player FMは今からすぐに楽しめるために高品質のポッドキャストをウェブでスキャンしています。これは最高のポッドキャストアプリで、Android、iPhone、そしてWebで動作します。全ての端末で購読を同期するためにサインアップしてください。

500+以上のトピックを聴こう

Apple AirTag 4 Pack

Ailun 3 Pack Screen Protector for iPhone 16 Pro Max [6.9 inch] + 3 Pack Camera Lens Protector with Installation Frame,Sensor Protection,Dynamic Island Compatible,Case Friendly Tempered Glass Film

Mighty Patch™ Original patch from Hero Cosmetics - Hydrocolloid Acne Pimple Patch for Covering Zits and Blemishes in Face and Skin, Vegan-friendly and Not Tested on Animals (36 Count)

聞く価値のあるポッドキャスト

Tech Debt Burndown Podcast « » Break From Burndown: The Memorial Day Spring Bank Holiday Break

“They were told observability would solve their problems, but it didn’t, so what the @$^#?” - Charity Majors

Break From Burndown: The Memorial Day Spring Bank Holiday Break

“They were told observability would solve their problems, but it didn’t, so what the @$^#?” - Charity Majors

聞く価値のあるポッドキャスト

プレーヤーFMへようこそ！

Skeletá

2024 Panini Donruss Holiday Football Trading Cards Blaster Box

everydrop by Whirlpool Ice and Water Refrigerator Filter 1, EDR1RXD1, Single-Pack , Purple

The Let Them Theory: A Life-Changing Tool That Millions of People Can't Stop Talking About

The Let Them Theory: A Life-Changing Tool That Millions of People Can't Stop Talking About

クイックリファレンスガイド

Tech Debt Burndown Podcast « »
Break From Burndown: The Memorial Day Spring Bank Holiday Break