Tag: software

The Code That No One Touches

Published on by Nick Bradbury

Every app that’s been around for a while has code that no one touches.

The rest of the code may be great, but there’s that one area written a long time ago that everyone is scared to work on. It’s so fragile that if you touch it you’re likely to break something, forcing you to descend into its unfathomable depths in order to repair it.

If you do have to work on it, the rest of team turns somber and treats you like a soldier headed to battle. They know they won’t hear from you for a while, and there’s a chance you won’t return.

Perhaps one day you announce you’re finally going to refactor that code. “It’s ridiculous to have this awful code in our app, and I’m going to correct it,” you foolishly say. A few days later, after discovering new swear words as you try to figure it out, you decide now isn’t the best time to fix it. “Maybe I’ll tackle that after the next version ships,” you proclaim, secretly hoping nobody remembers you saying that.

When a new developer is hired, the rest of the team wants their first task to be repairing that old code. They’re new, excited to be on board, and eager to prove themselves – so let’s welcome them by throwing them into the dark pit that hides beneath our software.

But that never happens, because the people in charge don’t know about the problem. Nobody mentions it to management for fear of being assigned to take care of it.

And so the old code lingers, like a basement closet nobody wants to clean out. The code that no one touches never goes away.

Code is Temporary

Published on by Nick Bradbury

Developers sweat blood writing code but in the end our code will vanish. That language you’re learning or framework you’re devoted to will disappear in short time. At some point what you create will only be able to run in some nostalgic emulator.

Your code isn’t important: what matters are the ideas your code brings to life. Shitty code that makes a point is better than perfect code that proves nothing.

Don’t waste your short life getting lost in the geeky details of the toolkit du jour. Spend it using your skills to create something that matters to you, that may even last longer than you.

Most developers have far more power than we realize but too many of us squander it building things we don’t care about. Now is your time to make a difference. If you don’t do it now it may never happen.

I Hate the Command Line

Published on by Nick Bradbury12 Comments

mac-terminal

Back when I was a Windows developer, I learned all sorts of arcane things about the platform. I felt I had to in order to be a good developer, and much of it was necessary to support customers running into problems.

Four years ago I bought a Mac, and three years ago I ditched Windows entirely and started learning Android development on my Mac.

I decided I really didn’t want to learn all the innards of the Mac. I never liked dealing with all that on Windows, and since I wasn’t a Mac developer I figured I could skip it.

Which means, of course, that I’m totally useless with the command line. Terminal? No thanks. Bash? Forget it. Git? I’ll use SourceTree instead. If it doesn’t have a GUI, I don’t want to touch it.

Sure, there are probably a ton of cool things I could do from the command line. But I’m happier not feeling I need to know all that stuff.

Unread Counts

Published on by Nick Bradbury4 Comments

NetNewsWire creator Brent Simmons on unread counts:

Nick Bradbury, FeedDemon author, and I have talked many times over the years about how we’d design an RSS reader were we starting over. The first thing we always say: No unread counts!

It’s true: showing an unread count was something I regretted. It was one of many things I did to make FeedDemon work like an email client so it would seem familiar to new users. I’m sure it did make it seem familiar, but in the long run it was a mistake I never overcame.

Treating RSS like email makes it a chore to read, but customers were so used to FeedDemon working like an email client that any attempt to make it less email-like was met with resistance. So instead I came up with things like the Panic Button which were just band-aids that didn’t address the underlying problem.

Looking back, I wonder how RSS readers would’ve fared if their developers hadn’t followed the email client design. It’s partly because we did that the RSS reader (but not RSS itself) is now considered dead.

Code Dependent

Published on by Nick Bradbury

Justin Williams writes about third-party dependencies:

As I’ve matured as a professional developer, I’ve learned to understand that a dependency and liability are many times interchangeable

He jokingly mentions how his stance will get him an invitation to the “old guy coders club,” of which I must be a long-time member (here’s proof). As current and former co-workers can attest, I’m notoriously cranky when it comes to third-party dependencies.

I wasn’t always this way, though. In my ill-spent youth I’d add third-party libraries to my projects without concern. It was a no-brainer at the time – they added so much power and snazziness with so little effort on my part.

It wasn’t until I created long-lived software like FeedDemon that I realized their downside. Components I relied upon would stop being upgraded, no longer be reliable, or simply disappear. They’d break when a new version of my OS (or even my development tool) was released. Their UI would change, affecting the UI of my software.

In some cases the pain was worth it, but more often than not it wasn’t. I spent far too much time rewriting, replacing, and rethinking third-party libraries I chose to rely on. In the long run, my software and my customers would’ve been better off if I’d been more conservative with those choices.

Don’t get me wrong – I certainly rely on third-party dependencies in the software I work on now, but I’m a lot more cautious about adding them than I used to be. I like to think of this as hard-earned wisdom rather than a sign of senility :)

 

 

Optimistic Connectivity and Sleight of Hand

Published on by Nick Bradbury

A huge pet peeve of mine is mobile apps which make you to wait after you do something that requires a server API call. For example, you tap a “Like” button and are forced to look at a modal “Liking…” dialog that doesn’t go away until the app knows the like has been received by the backend.

Apps which do this are unnecessarily pessimistic about connectivity. Why make the user wait when the most likely outcome will be that the API call succeeds? I think it’s better for the app to show the new “Like” state immediately, and then deal with the rare failure in the background.

This optimistic approach is one that the folks at Instagram have touted, and I’ve followed it in all of my mobile apps.

Sometimes, though, you really do want to make the user wait, at least a little bit. In these cases, it’s often better to resort to sleight of hand which distracts the user instead of blocks them the way a modal dialog does.

I’ve found animation to be the most effective form of this trickery.

Suppose it really is important to make the user wait a couple of seconds after clicking a “Like” button to give the API call a little time. In this situation, animate the “like” button for a second or two – have it bounce, or spin, or zoom in and out.

Users will wait for the animation to end before doing something else in the app, and by the time the animation is done there’s a good chance the API call has completed. The user still waited, but because they waited by choice it doesn’t feel the same as being so obviously blocked by an annoying modal dialog.

PS: I should add that I only recommend this approach when making very lightweight requests. For heavier requests (especially ones that upload large amounts of data), a background service is a far better choice.