Archive for June, 2011

Apple Just Killed My Best Feature

Sunday, June 26th, 2011

I don’t expect anyone to shed a tear for me. It happens all the time. Apple comes out with a new version of Max OS X or iOS, and they add something that copies (and often improves) a feature previously only available through 3rd party software.

In my case, Apple isn’t copying anything, and they’re not adding anything that hurts me. Nor are they making a change to either of their OSes that impacts me.

No, Apple is discontinuing iDisk. And with that, ends Giftory’s ability to let users post a Wish List to their iDisk Public Folder and let other Giftory and GiftoryWLR (iOS) users read it from anywhere else in the world.

Hopefully something in iCloud will turn out to be a useful replacement. My fingers are crossed.

Maybe this will be the impetus for me to come up with a shared Wish List solution that will be compatible across the Mac AND Windows versions of Giftory, the iOS Giftory Wish List Reader, AND the upcoming iPad version of Giftory. Guess I’ll have to look at this as an “opportunity”. :)

If an Application is a painting, do you, as a programmer, want to paint a picture on a blank canvas, or assemble a picture from a jigsaw puzzle?

Thursday, June 2nd, 2011

As the years go by in this profession, more and more I see an expectation that professional software developers will utilize any and every framework or library available to accomplish various programming tasks.

The truth is, there isn’t very much code to write that hasn’t already been written a hundred times over. Every general programming “problem” has been solved, and there’s often a generally accepted “best” method to solve any such problem.

However, if you’re in this business because you enjoy the “art” of developing software, then you probably enjoy developing your own solutions to programming problems, even if canned solutions to those problems already exist, and even if the solutions you come up with aren’t necessarily as elegant or optimized as the solutions that already exist.

In other words, lots of us like reinventing the wheel. It’s part of what we enjoy about what we do.

When we’re working on our own independent projects, this isn’t an issue. We’re free to do as we please.

But when we’re taking a paycheck from an employer or charging a client for our time, their ultimate goal is to get the desired finished product, as quickly and cheaply as possible. Our desire to spend extra time developing our own solutions to problems is usually incompatible with their goal.

But there has to be a balance.

Yes, it may be unreasonable to decide you want to write your own xml parser on your employer’s/client’s dime when so many other canned solutions already exist.

However, keeping you engaged, challenged and interested in the project and your work is also a very important factor, for both parties.

So if someone suggests that you use Framework X to make web service calls, library C to process the returned results and open source project N to display the results in a nice, pre-fabricated UI, if that’s the majority of the application’s functionality, then they’re asking you to become a puzzle assembler, a code monkey, a paint-by-numbers “resource” who likely won’t take any joy out of the work you’re doing.

Find the balance. Determine which wheels would be unreasonable for you to reinvent, which wheels you will learn the most from reinventing and which wheels you can bring something new to the table for.

Then have at it!

But most of all, don’t get trapped assembling coding jigsaw puzzles for the rest of your career, which likely won’t be very long if that’s all you’re stuck doing.