Chris Hannah


Technical Debt Sounds Dumb #

Kam Lasater, wrote a great piece on technical debt. Primarily explaining how stupid you sound when most people try to explain technical debt to businesses-minded people.

When we use the term technical debt with non-technical business colleagues, they assume, that technical debt is analogous to financial debt. After a few minutes of discussion they are usually relieved to find that there is no actual money problem. Then after not seeing any tangible sign of a fire in the movie theater, they will then conclude that that we either don’t know what we are talking about or we are using the wrong terms or both. Think about their context, how quickly would the CFO get fired if they claimed “we have a lot of debt” but couldn’t produce a balance sheet with lenders, amounts, interest rates and terms?

The article goes into a lot more detail on what the problem is, and also the ways you can explain it better. But essentially, the trick is to explain it in ways that people can understand:

Companies and business leaders don’t care if jobs are hard or annoying or take longer than they “should”. The difference between a user story taking a day or 3 days is negligible compared to its business value. Companies and their leaders care about revenue and costs. They care about customers and growth. They care about time to market. If we want to have our non-technical colleagues listen and act, we need to either improve our use of the financial terms they understand or we need to translate our message into business outcomes that they do care about.

I’ve seen this myself where I work. Every so often it’s regarding technical debt, but typically, I think it’s when people aren’t aware of the context in which they’re explaining something. It’s something I definitely had to get to grips with as well, learning how to talk to various people, what they understand, what they’re interested in, and overall, what matters to them.

This may sound rude, but I think sometimes us developers get a bit stuck in our own world. We tend to use a bit too much jargon, arguing over the stupidest of problems, and not really focussing on the wider business perspective. For example, the value of the product doesn’t get better if you use a different code style.

One thing that helped me at work was to spend time with people like product managers, business leaders, or anyone else non-technical that I had to explain things to. That way I learned their perspective, and adapted my wording to fit. It’s only going to be better for both parties if you can get things across clearly. It avoids unnecessary confusion and it saves time.

Developers Share Experiences With Early iOS SDK #

With all the nostalgia of the early App Store and iOS SDK days, Frederik Riedel tweeted about his experience developing iRedstone:

After he tweeted that, other developers started quoting it, and sharing their experiences. Frederik has compiled a great collection of them over on his blog.

A Backend Engineers Experience on Switching to an iPad Pro #

Jannis Hermanns took on a rather interesting challenge recently, and it was all about working from an iPad Pro.

But unlike most people that make the switch, he’s not a writer, manager, or a designer. Jannis is a backend engineer, that uses some terminal in some hardcore ways!

In the summer of 2017, I wanted to know what it would be like to use an iPad Pro as my main computer. I found out that it can actually work, thanks to an iOS app called Blink, an SSH replacement called Mosh, iOS 11 and running stuff on a server.

His perspective/experience I find, is different than most other macOS to iOS switching articles, as there was a lot more technical issues that had to be solved.

But nonetheless, he managed it in the end.

Sadly for myself though, this switch isn’t something that I could do myself any time soon, as I develop 99% of the time using Xcode. Sure, I could probably run that on a Mac, and use a iPad to operate it. But what’s the point in that.

Read the full post.

I’d Like to Request a Review Prompt, Please→ #

Joe Cieplinski, on the way iOS handles review prompts, and the way developers have to implement them:

While working on my latest update of Fin, I spent a bit of time playing with Apple’s new SKStoreReviewController API.

For those unfamiliar, this new API was announced with the early betas of iOS 10.3, and it went live with the 10.3 release last month. Though it isn’t the only approved way to prompt a customer to rate your app on the App Store yet, that is Apple’s ultimate intention. Like it or not, you’ll have to learn to work with this thing eventually, in other words. Unless you never prompt for reviews.

If you’re interested in the way apps now ask for reviews on iOS, or maybe just want to find out a developers perspective, Joe explains the pros and cons very nicely.