Author Archives: loufranco

Green, Refactor, Red

I’ve been doing more TDD lately (which is why I’ve been watching TDD debates), and one thing that’s been good is to not do Red, Green, Refactor, but instead do Green, Refactor, Red and end the day on Red.

That way, when I start the day, I can warm up quickly by fixing that test and before I know it, I’m done.

I do end the PR on the Green though.

Confession: I Estimate Using Time

I know, I know. I’m supposed to be estimating using Fibonacci story points, and like Whose Line, the points don’t mean anything, but I have tried it, and I don’t get it.

For one, regular people just translate that to some notion of time anyway, and in that regard, I am very regular. If you are going to take some random number I provide and assign a date to it, I’d much rather I do the translation for you.

Also, I feel like a wrong point estimate is never acknowledged as wrong. It’s just that we didn’t do as many points this sprint as we thought we would. A time estimate is more checkable and less subjective. You can track it using normal means. When I work for two hours on something, that’s two hours. How many points did I just work?

If I say it takes 8 hours and after 4 hours, I say that there’s 6 hours left, I have good feedback on my estimate. If I say something takes 8 points and a the end of the day, I think I’m halfway done, was I right? I don’t think you can make any inferences about the correctness of point estimates without some kind of translation to time, and if you do that, then just use time.

If you love and use story points, that’s great. My only strongly held belief is that people should do what works for them. But, it’s not how I think of how long things take.

Write While True is a Prompt not a Companion

In March, I wrote this about the idea of a “companion” podcast that could be listened to while doing something (or learning something) related to what you were listening to:

This kind of podcast could not just be played in your regular playlists though—you need to be at your computer ready to listen. It could guide you in a vague way, so that you have to think in order to do the tasks, not just listen while you exercise.

At the time I was thinking about a programming podcast, and that somehow you listened while you were doing tasks it described.

But this ultimately turned into Write While True, which is a podcast that ends with a writing-related exercise that you do right after it’s over. So, not exactly what I thought it would be, but more of a prompt. I do believe in hacking your behavior via prompts, so this is good with me.

Tradeoffs in Unit Testing

In this TDD video I linked to, Ian Cooper mentioned that there were a series of videos where Kent Beck, DHH, and Martin Fowler debated TDD and related practices. The first one is here, and there are several more that you can see linked from that one. There are six in total—each about 30 minutes long. The debates were sparked by DHH’s blog that TDD was dead.

One interesting thread throughout is the idea of tradeoffs, and that nothing is necessarily always good or always bad. I had written this before in the context of technical debt and personal savings rate.

In these debates, they discussed whether more testing was always better and whether faster tests were always better. And of course, the answer is: it depends.

With no (or low) tradeoff cost, then yes, more and faster tests are better. If I can make tests faster with just hardware upgrades, then that’s great. Also, when benefits are very high, then even higher costs may seem low. For example, if tests take an hour, then we are willing to bear high costs to make it a few minutes. We would bear some lesser cost to make it a few seconds. But, should we keep going?

I think this all fairly obvious, but in the heat of discussion, it’s often glossed over.

(I should say that I believe for lots of kinds of problems, testing and coding together, whether it’s TDD or or not, makes you go faster and more correctly. I also mostly don’t care about unit isolation if it gets in the way—if you aren’t going faster and more correctly with tests, then I’d start wondering why and whether they might be getting in the way).

Building a Serendipity Machine

In yesterday’s podcast, I talked about spaced-repetition and how I use Anki to help with my memory. Anki is a flash card system that uses algorithms to show you cards just as you might be forgetting them.

If you are just using this casually, like I am, you only need to “study” for a few minutes a day (and skipping days or even weeks will be fine—Anki will catch you up). If you are a student who is using Anki to cram for exams, you would probably do it differently.

I built up my deck over time. I make new cards while reading or watching videos. I made a bunch last week while watching WWDC.

In the podcast, I said to use a single deck with all of your cards mixed together. So, if in a few months, you read books in different subjects, you wouldn’t make separate decks for each book or subject. This makes it a lot easier to just make cards whenever you want without thinking about it too much. It also makes studying a kind of serendipity machine.

A couple of episodes ago, I had spoken about how to generate ideas by combining disparate knowledge. Going through an Anki session of uncategorized cards helps me do that regularly.

So, in my deck today, I was asked about:

  • The kinds of gates you find in QUIL quantum computing (I read Quantum Country this year which is a book with embedded spaced-repetition)
  • The goals of visual design
  • A specific Typescript operator
  • Covey’s 7 Habits
  • The parts of C4

As I think it over, there is perhaps something interesting about the communication principles in C4, the communication goals of visual design generally, and Covey’s 7 Habits—specifically “Seek First to Understand”, which is the core communication habit.

I should write a note about that.

Write While True Episode 14: Spaced Repetition

Last week I encouraged you to collect general knowledge. Viking trade routes, anime, Rothko paintings, architecture, typography, bluegrass standards — where ever your interests lead you.

For these kinds of things, it may be hard to write a note though. You could certainly write down something, but it’s unlikely that you’ll develop a few paragraphs of a coherent thought about lots of random things.

James Webb Young said to use index cards for that. That would certainly work, but I recommend using spaced-repetition card software instead.

Transcript

WWDC 2021: Summer Plans

So far I’ve only had time to watch the various Swift updates. I wrote about async/await the other day, and I will spend some time later this summer thinking about Sprint-o-Mat’s asynchronous code.

Pretty much the entire app is reactive to asynchronous events, the workout progression, the passage of time, the changing location, and health metrics all come in via delegates and callbacks. I publish those to the UI via Combine. That might still be the best way as we’re dealing with a sequence of asynchronous values, but filling them up may be simpler with the new APIs. I’m not sure yet if this is a use-case for the new AsyncSequence.

I will certainly support the always-on screen—mostly I need to make sure to slow updates to one per second when dimmed. I might also alter the UI in this state to simplify it.

I also saw that there’s a MusicKit now and I’ve been wanting to bring music into Sprint-o-Mat for a while. I already support an in-app media player, but I’ve been wanting automatic music changes during sprints and rests.

One thing I’ve been interested in exploring is communication to an iPhone app. I want Sprint-o-Mat to stay an independent watch app. I am looking for ways for it to communicate to an iPhone app that is perhaps in the same group, but not necessarily in the same bundle. I don’t think there’s anything new here, but there are some watch connectivity sessions, so I have to check those out.

Ad Attribution comes to iOS apps and the App Store

I have not heard a lot of hoopla about this, but I think this is a big deal. Back in 2019, WebKit announced a way to do ad attribution without per-user tracking. I put support for this in the AppStore on my WWDC 2019 wishlist.

The WebKit team just announced a privacy preserving ad attribution system for websites. I want the same thing to work for an ad for an app that appears on the web, App Store, or in another App. No need to attribute to a user — just the ad source is sufficient.

I explained in a followup:

The last few years have been a cat-and-mouse game between Ad Tech firms finding loopholes in iOS (e.g. shared Pasteboards) and Apple closing them. It would be much better if Apple provided a privacy preserving mechanism and then explicitly forbade anything else in the developer agreement.

I put this on my 2021 wishlist as well.

I just noticed this video on the WWDC Site: Meet privacy-preserving ad attribution, which appears to have done just that.

I don’t personally need this feature, but we need to do something to help out app developers who are under pressure to get some kind of ad effectiveness data. With IDFA basically gone, Ad Tech firms are going to resort to fabricating their own ID from whatever identifying information they can grab.

One thing to remember is that none of these firms have any kind of relationship with Apple. They are not parties to the developer agreement, so they have no obligation to follow it. It’s the developers that integrate their SDKs that take the risk and are the ones violating the agreement.

Another risk is that these SDKs inherit all of the permissions their host app has obtained. So, you could ask for location for a very good reason (e.g. you show the weather) and they could see that they have the permission and use it for something else (e.g. enriching their ad targeting database). Again, your app probably didn’t disclose this, but those SDKs don’t need to follow the rules—only you do.

So, I’m looking forward to this ad attribution method being adopted widely and for app integration to be done by the app developer just making HTTPS calls, not integrating an SDK. It may be too much to hope for, but it did require Apple to take the first step and offer a mechanism, which they now have.

Thoughts on async / await in Swift

This is the latest in a series of major language changes that Apple has introduced, going back to ARC in Objective-C. It feels like this one has been a long time coming, but the implementation is thorough and satisfying.

One thing I appreciate is that they revisit framework APIs to offer up modern versions simultaneous with the new language feature. They did the same for blocks and exceptions when they were introduced. One reason they are able to do this is because the APIs are very consistent, and it’s possible to do a mechanical translation.

And even though Objective-C won’t get async/await, the compiler will recognize common asynchronous function signature patterns and offer up async versions in the generated Swift interface.

Another thing that struck me is the deep compiler integration to flag common concurrency bugs. For example, you can’t capture mutable variables by default, so you need to do something to make them safe to use. The common answer will be the new actor concept.

I was somewhat surprised that the various task constructs (async and asyncDetached) and groups were a little more complex that I thought would be coming (I’m not following Swift Evolution very closely). But, the presentations offer good motivation for when you might use them. It also seems like you can start simple and use the more manual mechanisms if you need them.

I’ll see how it goes as I adopt these in Sprint-o-Mat.

TDD Video

This video from Ian Cooper on what happened to TDD has reinvigorated my usage of TDD

Ian completely explains what happens to long projects with a lot of tests and describes how to avoid the ossification that comes from tests coupled to the implementation of the code it tests.