Category: 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.

Thanks, Radio Shack!

Published on by Nick Bradbury1 Comment

When I was 15 my Dad bought a TRS-80 Color Computer from the local Radio Shack. I was an extreme underachiever at the time, and I think his hope was this new toy would spark my interest.

It worked.

I fell in love with that little 4K box. By the end of the year I was writing BASIC games for it, and soon afterwards I was publishing articles in Hot CoCo and Rainbow Magazine. Next I taught myself assembler and began selling games like “Moon Runner,” a knock-off of the arcade hit “Moon Patrol.”

Moon Runner (1985)

Now that Radio Shack is on its last legs, I just want to say “thanks, Radio Shack!” Thirty years later I enjoy writing software more than ever, and that underpowered TRS-80 is where it all started for me.

The Programmer’s Dream (A Ramble)

Published on by Nick Bradbury

Programmers dream of new code.

We spend a good deal of our time working on code we didn’t write for software we didn’t create, much of which we believe is horribly written (or, at least, could be done much better). We dream of a chance to start fresh, working from scratch on a brand new piece of software that will eventually become something someone else has to work on and believes is horribly written.

If we’re lucky our software will look pretty solid from the outside. It may do weird things from time to time or very occasionally crash, but on the whole end users will think it’s stable and well thought out. Those of us who can look at it from the inside are amazed by this because we see a house of cards just waiting to come tumbling down. I think one of the benefits of open source is that we can see more clearly that everyone else’s code is just as frightening as our own is.

This situation reminds me of how I used to look at our culture when I was much younger (it’s a tenuous connection, but as I said, this a ramble).

I used to assume there were people in charge who knew what they were doing, who planned how things in society should work. As I got a little older I got more cynical, believing these people were trying to keep the rest of us dumb with shoddy schooling and mind-numbing entertainment, in the hopes they could get away with whatever it is powerful people are always trying to get away with.

Then as I got even older I realized that the people in charge are as clueless as the rest of us. Like our software, our society just kind of happened over the years and it’s always on the verge of coming tumbling down. Nobody really knows what they’re doing or what they’re talking about.

If you can get over the sheer terror of that thought, it’s actually quite liberating.

Mobile Apps Are Scary

Published on by Nick Bradbury3 Comments

In 2006 I wrote about how the fear of installing desktop software accelerated the move to the web. Security warnings, firewall alerts and antivirus popups made installing software feel like an incredibly risky thing to do.

We’re seeing a similar situation with mobile apps now. The seemingly simple act of installing an app requires you to first approve a scary list of permissions, and while some may approve them the same way they dismiss a EULA, others find them daunting. Add to that the spammy notifications and addiction-feeding of popular games plus the privacy violations of popular social apps, and it feels like I’m watching a rerun from eight years ago.

If this trend continues, the whole debate about mobile apps vs. web apps will be pointless: users will feel safer with web apps so that’s what they’ll choose, and developers will follow.

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.

Why I Left Indie Development

Published on by Nick Bradbury

indiana-jones

In what feels like a different life now, I used to be a fairly well-known indie developer. I spoke at events like SXSW, and my blog had a large audience of people who liked hearing about my work on HomeSite, TopStyle and FeedDemon.

I parted ways with that life several years ago, in part because it’s extremely difficult to be a one-man show and still have time to be a husband and father. I was also burned out from years of doing my own support. I had lovely customers, of course, but I spent so much time supporting them that I wasn’t able to spend as much time feeding my code addiction. Almost everything I do professionally is so I can enjoy the bliss of getting lost in writing software.

But I also gave up pursuing the indie life because I wanted to make the switch to mobile development, and I didn’t see much future for indie mobile developers. The economics of the various app stores coupled with the plethora of free software didn’t paint a rosy picture for one-person companies building consumer apps. In fact, I didn’t make the leap to mobile until I was offered a full-time job as an Android dev.

So it’s been interesting reading the latest round of blog posts about the state of indie mobile development. While there are success stories, there certainly aren’t many of them. Making a decent living as an indie developer writing mobile apps is ridiculously hard – and I don’t see it getting better anytime soon.

A lot of mobile developers have left the indie ship and done as I have and joined a larger company, many of which look at mobile apps as a free (or nearly free) complement to their other offerings.1 There’s plenty of opportunity here for mobile developers, and I think that opportunity will continue to grow for a while.

  1. As an aside, I’m not convinced the “mobile as a complement” strategy is the right one long term. Mobile is becoming the primary way people access their information, to the point that web and desktop software are turning into the complement.

Broken by Design

Published on by Nick Bradbury4 Comments

When I was a kid, my parents had a table you couldn’t cut things on.

You also couldn’t set glasses on it without a coaster, and anything hot needed a pad under it. It was a beautiful table, but guests didn’t know this because it was covered with a table cloth for protection.

I was an annoying child, so I constantly pointed out how ridiculous this was. The purpose of a table was to eat and drink on, I would proclaim, yet this thing would be harmed by those actions. It was designed to look great without concern for how it would be used.

I’m reminded of that table by a lot of apps I see these days. They look stunning in videos, and the first time you use them you’re blown away by the beautiful animations. You almost feel like you’re using works of art.

But the more you use them the more annoyed you get because they’re designed to look great without thought for how they’d be used. Those mesmerizing transitions you used to love are now slowing you down. The layouts which used to seem so clean are now awkward because things are placed where they’d look the best instead of where they’d make the most sense.

They’re broken by design.

A few years ago a lot of software suffered from lack of design. Now it suffers from too much design. Surely there’s a happy middle ground where software can look and behave in delightful ways without undermining its purpose?

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.