Category Archives: Presentations

Workshop: Eight Questions to Ask About Your Tech Debt

In Part 3 of my book, Swimming in Tech Debt, I write about how teams should plan projects to address larger technical debt issues. The bulk of the chapters in the section explain how to manage a tech debt backlog.

Drawing on the practices of product managers and how they manage feature backlogs, I propose a scoring system to drive the discussion.

The scoring system breaks down the costs and benefits of paying debt (or not paying it) and gives you a way to compare items to each other. It starts with this diagram:

Diagram showing Pay and Stay Forces

The benefits of paying debt and the costs of not paying (staying) drive the Pay Force. Inversely, there are benefits to staying and costs to paying that indicate you should leave the debt alone. These eight dimensions are scored by answering a related question:

  1. Visibility: If this debt were paid, how visible would it be outside of engineering? 
  2. Misalignment: If this debt were paid, how much more would our code match our engineering values?
  3. Size: If we knew exactly what to do and there were no coding unknowns at all, how long would the tech debt fix take?
  4. Difficulty: What is the risk that work on the debt takes longer than represented in the Size score because we won’t know how to do it?
  5. Volatility: How likely is the code to need changes in the near future because of new planned features or high-priority bugs?
  6. Resistance: How hard is it to change this code if we don’t pay the debt?
  7. Regression: How bad would it be if we introduced new bugs in this code when we try to fix its tech debt?
  8. Uncertainty: How sure are we that our tech debt fix will deliver the developer productivity benefits we expect?

If you have bought my book and would like me to talk to your team about this process, get in touch. It would be a 45-minute presentation with 15 minutes for Q&A.

In the presentation, I score 3 backlog items from my career and then show how the scoring drives the decision making of what to do. I encourage you to record it and then go through the presentation with a couple of examples from your backlog.

This workshop is free. Write me on LinkedIn or through my contact page.

After taking the workshop, reach out if you would like me to facilitate your technical debt backlog planning sessions. The book has agendas, scoring guides, and a catalog of score-driven debt remediation ideas, but I’m happy to tailor them to your needs.

Accessibility First in Podcasts

I released a podcast a few days ago. I am doing this podcast partly to improve my writing and my ability to do Professional Performances, so it is scripted.

A side benefit is that it doesn’t take much to produce a transcript. In fact, I have a pretty good one before the podcast is even recorded.

Aside from accessibility, transcripts have many other benefits. SEO is a big one, but also, it makes it a lot easier for listeners to refer back to. And if they feel inclined to quote you on social media, it makes it a lot easier.

In any case, I’m glad that my process produces the accessible artifact first.

Professional Performances

I’m not a huge fan of technical interviews because I think they are closer to auditions than programming work simulation. I wrote:

A typical tech job is not a performance. For one, there is no audience. And, unlike a performance, we make tons of small mistakes and corrections along the way. Imagine a band performing a song like we usually program—it’d be a mess and not very entertaining (or very entertaining if you think of it as avant-garde).

But, there are times where the work is a performance. For example, presentations or talks. For that, I recommend treating them exactly how performers do—with lots of practice: solo and in front of audiences.

When I recommend this, the push-back I get is that the person doesn’t want to sound like they memorized their presentation.

I agree.

Actors and musicians completely memorize what they are going to perform, but then give a natural performance. Stand-up comedians practice being flustered and reaching for words. The more you practice, the more natural the performance will look. When you do it, you will be in a flow-state.

If you want to see this in action, look at any TED talk—they are highly polished performances. Steve Jobs was also famous for practicing intensively.

But, practice has a much more important effect—it drives self-esteem. If you put the work in, you will see it. You will see that you are doing rehearsals and you will judge that you are likely to succeed. You will feel pride and you will want to do it more.

That sense of pride may turn us from dreading speaking in public to actually looking forward to it. After your successful performance, you will have the confidence that comes from success, which will drive you to practice more and start a virtuous cycle.

Incidentally, this works for interviews too.

SwiftFest

I will be speaking about my experience with RxSwift at SwiftFest 2019 in Boston on July 29-30. Last year, I spoke there about how to sketch iOS UIs in Playgrounds — unfortunately the talks are not available online, but I’ll be putting together a video shortly that covers the material I spoke about.

I highly recommend this conference — it’s two-track and has about 300 attendees. I went to talks every chance I got and learned a ton. It will also be a good time to discuss the ramifications of WWDC as we’ll all have add a couple of months to absorb iOS 13.

If you are going to be there, contact me here or on twitter.

NerdSummit 2017 Talk: Introduction to iOS Development through Apps

On March 18th, I’ll be giving a presentation to teach iOS development by looking at completed apps and customizing them.

If you are planning to attend and want help after the talk to set up your machine and get started on the exercises, here’s what you’ll need:

  1. To do the exercises, you need a Mac with Xcode 8.2+ installed. If you don’t have access to a Mac, I think we’ll have enough people with one and can pair you with someone.
  2. We’re going to be forking apps on GitHub, so having a GitHub account already would be good.
  3. You don’t need a device — we’ll be able to use the simulator for all of the examples, but if you want help getting apps on devices, sign up for a free Apple Developer account.

It’s a beginner talk, so anybody with an interest in programming will get something out of it. It will help if you have some programming experience (in any language).

Here’s the plan

  1. Basic Swift (enough to be able to read the apps)
  2. The MVC pattern as implemented in UIKit
  3. Interface Builder (connecting outlets and actions)
  4. Then, we’ll fork an app and make some customizations
  5. Based on the group’s questions, we’ll cover as much iOS Development and Swift as we need.

The idea is that the apps we’ll fork are generally useful apps that people might want a custom version of. All of the code is open-source, and you’ll be able to continue to develop them after the workshop if you wish and release them to the App Store.

I’ll introduce the apps in subsequent blog posts here (I have to make them).

There will be handouts so you can work on your own after the talk.