Article Blog Image

Don't Throw it Away Just Yet


As techies, we all desire the latest and greatest hardware, the most recent and powerful MacBook Pro, the best of the best gaming laptop/desktop, but as developers, we should be mindful of the target audience and aware that not everyone is going to have, or want, such cutting edge equipment.

Clearly it’s more fun to develop on a high powered MacBook or Windows equivalent, things go faster, compile times are shorter, turnaround is instantaneous, etc. Fitting your machine with a high speed solid state drive can make you a “more efficient developer”, that’s the promise, right? You can always excuse the massive expense of shiny new hardware by quoting the efficiency benefits, right?

Well, yes, in a way, being efficient as a developer is a good thing, as long as you don’t lose sight of your target audience. Now, if your target audience is high tech, front-runners, always on the latest hardware, knock yourself out. But for the rest of us, it’s invaluable at to get a reality check occasionally, for many reasons.

Firstly, running your application on older hardware makes sense if your target audience is likely to be running on older, less powerful equipment, that much is obvious. But, I hear you say, you can do that as part of the QA process, testing on representative hardware should be part of the QA process. Sure, that’s one way of looking at it, but you’re missing one really important aspect, nothing encourages efficiency than the direct pain of inefficiency. That is, if you feel the pain of a slow development cycle, or worse, the embarrassment of seeing your application running like a dog, you will be “encouraged” to do something about it. This not only benefits your application, and therefore your users, but your own development practices will be improved. You’ll find yourself naturally gravitating towards more optimal development approaches, better code reuse, better separation of concerns, more efficient caching, whatever the optimisations might be in your area, you’ll instinctively use them. And this is a win not only for the end user who has less powerful hardware, the power user will see the benefit too, it’s just all relative.

For this reason, I always force myself to split my development time between my more powerful main machine, and my, tired bit still ultra-reliable, old 2010 white MacBook (not Pro). I know for a fact, if my games/applications run well on that, they’ll run pretty much anywhere. Some evenings, after a day of hacking on the main machine, I sit down to some tinkering on the MacBook and find that all my work has caused it to run poorly there. That’s good, it’s caught early, I get to optimise live, on a machine that forces me to address the performance issues, if only to overcome my own frustrations. In the morning, the committed changes show an improvement over “good enough” on the main machine, and chances are, I’ve experimented and learned some new optimisation techniques along the way, win-win-win!