You Down With OPC? (Yeah, you know me!)

January 5th, 2017

Maybe I’m stereotyping, but something tells me the majority of developers who might be reading this are either too young or not cool enough to catch the reference to the 1991 hip-hop anthem from Naughty By Nature.

I’ll spare you my attempt at retooling the lyrics with something witty to match my message.


5 1/2 years ago I wrote about my search for “The Next Platform”. Based on the rumors of the day, I thought there was a pretty good chance that said platform would be a television created by Apple, that would run apps and open the world to whole new genres of interactive experiences.

Well… a year and a half ago Apple released a new version of the Apple TV, a set top box that connects to existing televisions and does support apps. But it wasn’t exactly what I was expecting. It didn’t allow developers to utilize what I’ve come to believe is the only practical path for a small-time developer to strike it big: OPC.




This isn’t a new concept.

What preceded the iPhone? The iPod / iTunes. Did Apple produce any of the music that its device could play, or, later, when there became the iTunes Music Store, did Apple produce any of the music sold there?

What company accounts for a full third of (US) internet traffic? Netflix. Until relatively recently, did Netflix produce any of the content they were sell… renting?

What company is most responsible for the death of many brick and mortar stores in favor of online shopping? Amazon. Have you ever bought a product that was manufactured by Amazon? (Perhaps a few of you have, but not the vast majority of their customers.)

Okay, those are the big guys. What about on a smaller scale?

Are you on Facebook?

Have you seen, or taken, one of the many quizzes like:

“Which Marvel superhero are you?”

“Which Harry Potter character are you?”

“How many of these ‘80s songs can you name from the lyrics?”

“How many of these movies can you identify from one picture?”

It’s not Marvel, or the music companies or movie studios who make those quizzes.

Some much smaller company / developer is utilizing Other People’s Content to create new experiences for millions of people to consume, and for them to make money from.

So, if you’re a small-time developer that doesn’t own the rights to such content, what are you to do?

Well, you can try your hand at developing an original game, for which you will have to develop new content, in the hopes that, amongst the thousands of other games already out there, yours will be a hit. (Some developers utilize Other People’s Content in this arena as well, cloning existing popular games. Personal experience has shown me that this may result in a Cease and Desist order.)

Otherwise, your best bet is to figure out how to use Other People’s Content, legally, in a way that adds value to that existing content.

One friend of mine has done very well writing software to utilize content created by other companies’ personal weather stations.

Another friend did very well many years back with Yahoo chatroom filtering software.

I have my own ideas about what Other People’s Content I can use to create a new(ish) market niche.

Perhaps it’s time you got down with OPC.

(Don’t) Interface Different

October 15th, 2015

Our biggest UI constraints aren’t our tools.

I was just riding with someone whose name shall be withheld to protect the guilty. We were in her new Prius, upgraded from an earlier model. She tried to turn on the air conditioning, (it’s mid-October in Phoenix and A/C is still very much a necessity,) but she couldn’t get it to work the way she wanted it to.

“Is this broken already?!?” And she angrily pushed a bunch of buttons until it did something close to what she wanted.

In truth, the air conditioning is working just fine. More importantly for this discussion, it works AS DESIGNED.

The problem is, the climate controls in her newer model work differently than the ones from her previous model, and she had no patience to figure out those differences.

This interaction is not an anomaly. Not just as a software developer, but as a user, I’ve seen people routinely complain about how a piece of software (doesn’t) works.

This imposes two distinct sets of constraints on us as software designers.

First, we are constrained by user expectations set by their history of use of the platform and other software on it. In an action dialog box or alert on your platform of choice, is “Cancel” the button on the left or on the right? If you don’t know and create such a dialog / alert with it reversed from the norm, or worse yet, you have a personal belief that the usual placement is wrong and intentionally reverse it, you’ve created a situation that’s going to irritate a bunch of your users and cause them to think less of your software. Enough such annoyances and they’ll stop using it entirely.

Second, we are constrained by our own interface decisions. Have you figured out a better way to organize your interface for greater productivity? Do you already have a version of your software out in the wild? You might want to reconsider your “new and improved” interface design. Just like my… driving companion, if your existing users expect things to be set up a certain way, and you change it on them, no matter how superior your new design is, your existing users may see it as broken, or at least bothersome. They may not stick around long enough to adapt to your changes.

This leads to one important conclusion.

I’ve seen others recommend to developers that the most important thing is to get a first, functional version of your app out into the world, and then to refine it later.

I’m going to have to vehemently disagree.

Have you seen the stats on the percentage of users who abandon a mobile app after three sessions or less? They’re staggering. You really don’t get a second chance to make a (good) first impression. In the world of software, you may not get a second chance to make ANY impression.

So make sure you get the interface right the first time through. Follow conventions. Adhere to standards. Make workflows function in as few clicks / taps as possible. Reign in your desire to “Interface Different”.

Are you a Software Architect?

July 15th, 2014

Four years ago I wrote a piece entitled, “What makes a Software Engineer ‘Senior’?” After 15 years in the business, it was still a point of curiosity for me, for a number of reasons. I achieved the official title of “Senior Software Engineer” for the first time at age 24, 1 year into my first official programming job, having no formal training or education in the field, a totally self-taught hobbyist programmer. It was certainly a title I hadn’t earned and didn’t really deserve. It was more a matter of protocol.

Nowadays my nagging question is aimed at a higher target.

What defines a “Software Architect”?

For many of us, this is the Holy Grail of titles. Most companies don’t have long career paths for software engineers that don’t involve getting sucked into management. So “Software Architect” is often the highest title that can be obtained short of something that fits under the management umbrella. And not just a title, the role itself generally affords the holder a higher level of respect, both within the development organization and from other non-technical segments of the larger organization. It affords the holder the prized ability to only partake in the fun, most enjoyable parts of development, designing systems and coding the most interesting components, leaving the mundane aspects of the application, including the dreaded last 10 percent, to engineers of lesser standing. And finally, and perhaps most importantly, it places the holder in the highest salary range available to technical staff.

Because of the supposed significance of this title, and the relatively few such positions available across the industry, very few software engineers ever attain it. At the most formal company I ever worked for, the highest technical title required traveling cross-country to corporate headquarters to present in front of an esteemed group of reviewers, including the company founders, in hopes of being bestowed with the title and the commensurate benefits that accompanied it.

But unlike my question about the definition of a “Senior Software Engineer”, for this question I think I have a much more definitive answer:


We’re all software architects.


“Senior” is something of an abstract term. It has no concrete meaning. In a startup full of fresh college graduates, the 5 year veteran is most certainly “senior”. But in a 100 year old company with a 20 year old development organization, with engineers averaging 12 years of seniority and over 40 years of age, the 5 year “veteran”, 7 years removed from college and 29 years old, is likely not considered “senior” by anyone else in the organization.

But “architect” is much more of a concrete term. A software architect designs and builds software architectures.

Anyone who has built an application from scratch that does much more than “Hello World”, especially an application that requires user input, and especially an application written without the benefit of an application framework, has designed and implemented a software architecture.

Anyone who has written a game without the use of a canned game-building framework has designed and built a software architecture.

Anyone who has developed an event-driven application has designed and built a software architecture.

It is impossible to build a complete application that deals with data, input by a user or retrieved from a remote source, without instituting an architecture to deal with the acquisition and processing of that data.

Of course, not all architectures are equal. And thus, not all architects are equal. To put it in terms of the more traditional type of “architect”, one might be able to design and build a dog house or a shed, but that doesn’t mean you can design and build a mansion.

So we’re all architects. The real question is, how good of an architect are you? THAT, is a subjective assessment much more open to individual interpretation.

So don’t ever be shy about considering yourself, and referring to yourself, as a software architect. You ARE one, most assuredly. If you find yourself feeling uneasy about the label, it is likely because you know you’re not as good of a software architect as you could, or should be.


A Different Type of Optimization

December 31st, 2013

For years I’ve heard the mantra from Apple engineers of not optimizing prematurely, because you never know where your bottlenecks actually are until you profile the running code.

But that’s only one type of optimization.

I, for instance, always optimize for project size.

Expand one of my projects and you’re unlikely to find more than 30 or so class files (counting header and implementation files as one.) Yes, it makes for bigger individual files, but it also makes for a much more easily digestible project tree, and, more importantly, it makes for MUCH less jumping around between files when debugging some complex process.

Over the years I’ve dealt with many applications that send http requests and receive responses. The first thing I do when I inherit one of these projects is to expand the entire project tree to see just what I’m dealing with. Often I find a project consisting of literally hundreds of files, many only a few lines long. One or more class files for every single business object, specialized classes for abstract concepts, multiple classes for implementing a single process, etc…


It has not been unusual for me to see a process flow something like this:


User does something that requires calling a web service.

Method 1 in Class A creates a new request object and passes it to Method 2 in Class B.

Method 2 in Class B calls Method 3 in Class B to get info with which to populate the message header.

Method 2 in Class B calls Method 4 in Class C to get the body info for the request.

Method 2 in Class B passes the request to Method 3 in Class D to format the request.

Method 3 in Class D calls Method 5 in Class E to Sign the request.

Method 3 in Class D calls Method 6 in Class E to encode the request.

Method 3 in Class D passes the request to Method 6 in Class F for sending.


So we have 6 methods in 6 classes just to send out an http request.

Then there’s the response…


Method 1 in Class A gets the response object.

Method 1 in Class A passes the response to Method 2 in Class B to parse.

Method 2 in Class B calls Method 3 in Class C to parse the header.

Method 2 in Class B calls Method 4 in Class C to parse the body.

Method 2 in Class B creates an instance of (business object) Class D, initializing it with the body of the response.

Method 2 in Class B passes the instance of Class D to Method 5 in Class E, which is the final recipient of the result.


So we have 5 methods in 5 classes to handle the result of the http request.

All total, that’s 11 methods in 11 Classes to handle an http request/response. Well… up to 11 Classes, as there could be overlap in classes between the send and receive processes.

And this is just the norm. I’ve seen some projects which easily double the number of methods and classes touched in implementing this request/response.

Now, let’s say you need to trace a request/response from start to finish. You’re jumping around to 11 methods in 11 files. If there’s a problem somewhere you’re trying to debug, and you’re in an IDE that keeps a tab open for every file you hit, you now have 11 tabs open for the 11 files you touched while tracing through this process. If bad data is occurring somewhere, you have 11 breakpoints in 11 files to try to find it.

When I have to debug the above, I roll my eyes and breath a sigh of aggravation at the developer who designed it.

Let me compare that to the actual process I use in Snap That! for implementing http request/response:


User does something that requires calling a web service.

Method 1 in Class A creates a new instance of Class B .

Method 1 in Class A calls Method 2 in Class B with the data needed for the request.

Method 2 in Class B creates the http request, formats it and sends it.

Framework Method 1 in Class B receives data and builds response.

Framework Method 2 in Class B sends response back to Method 3 in Class A.

Method 3 in Class A parses the response and uses the results.


So we have 3 methods (not counting the framework methods required to receive and package data) in 2 classes.

Debugging this process? Simple. Simple. Simple.

The usual objection to doing things the way I just outlined is that it results in unmanageably large source files.

Checking the file for the class I use to process http requests, it has 997 lines (and I put brackets on their own lines and use blank lines liberally for visual clarity) to handle 23 distinct web service calls. I don’t find that to be unmanageably large.

Yes, the two processes aren’t exactly equivalent, but basically there are three things I do that limit the amount of jumping between methods and classes in this process:


1) Using one DataManager class that handles all outgoing and incoming data requests and responses.

2) Inlining the code in one method that creates the request, formats the header, formats the body and sends the request.

3) Parsing the response into a framework-native dictionary class instance instead of creating instances of custom business object classes for every response.


The moral: separation of concerns, encapsulation and modularity are all fine OO concepts, just don’t overdo it.


Gold Runner for iOS now an Open Source Project!

January 14th, 2013

In the past I have been accused of having a career based entirely on one game: Gold Runner. It might actually be true.

Gold Runner was a game written for the TRS-80 Color Computer in 1984. It bears a striking resemblance to a game called Lode Runner for the Apple 2 and other 8 bit computers of the time.

It also happens to be my favorite computer game of all time. I’ve always had an obsession with the game and it’s never been far from my mind when contemplating game development of my own.

So in 1994 I finished Gold Runner 2000, a version written for the MM/1 personal computer.

The MM/1 would most accurately be described as a hobbyist computer bought by a number of members of the Color Computer (CoCo) community after the Color Computer 3 had become dated, the rest of the computing world had moved on from 8 bit to 16 bit systems, and Tandy had failed to provide such an upgrade path for the CoCo.

Gold Runner 2000 maintained all of the play mechanics from the original, but increased the size of the graphics images such that a whole level took up the size of 9 screens. This means that Gold Runner 2000 was a 2D side-scrolling game.

Color Computer (and MM/1) enthusiasts used to gather periodically for conventions, or “Fests”. And I took Gold Runner 2000 to just such a Fest in Atlanta soon after it was done.

From that exposure, I met a number of people. A couple of them worked at a company called Microware. Microware developed the operating system (OS-9) that ran on the MM/1 and Color Computer 3. When Microware needed some new developers with OS-9 experience, one of my new friends, Boisy Pitre – Microware employee, thought of me from having known my work on Gold Runner 2000. He contacted me, and it just so happened that I had just graduated from Arizona State University with a degree in Psychology. I worked for the credit card division of Chase Manhattan Bank, and prospects for a career with a basic liberal arts degree were pretty slim. So I took the job with Microware, in Des Moines, Iowa.

Almost two years later, I left Microware, moved back to Phoenix, and through a series of lucky occurrences and knowing the right people, continued working as a programmer despite not having the appropriate degree.

So yes, Gold Runner is responsible for me having a career in this field today.

Now, in 1997 I was moving on from the CoCo, fully entrenched in MM/1 development, and I missed my favorite game. So I decided to write a clone of the original CoCo Gold Runner for the MM/1. I played through every level of the original game, mapped each level out by hand on graph paper, digitized all of the sounds from the original, and re-created the (very simple) graphics from the original.

And, I must say, I did a damn good job. I recreated every aspect of the CoCo original. I copied the high score screen exactly, with the graphical effect of the line for the current high score alternating between white-on-black and black-on-white. I copied a graphical glitch from the original that, when a character was on the far-left edge of the screen, displayed the leftmost pixel of that character on the right side of the screen, one pixel lower than it would have been had it displayed properly on the left side. And finally, I recreated the oval-shaped fade-in feature of each level as it started.

High Score Screen

Game Screen with Oval fade-in

I decided that I didn’t just want to create a Gold Runner game, I wanted to create a Gold Runner “engine” – a codebase that could be moved to a different platform and easily modified to get the game running on that platform. Or, the code could be easily enhanced to make a new version of the game for the MM/1.

Eventually, this “Gold Runner Engine” was shelved without ever having powered another fully completed game.

Fast forward to 2008. I had recently started working as an iPhone developer, and had written a couple of simple indie iPhone apps, and I decided that I wanted to do an iPhone game. And then it hit me. I could resurrect the Gold Runner Engine, port it to the iPhone, and not only have my first iPhone game, but at the same time resurrect my favorite computer game of all time on the newest gaming platform in existence.

And I did just that. Impressively, for code that I wrote fairly early in my career, the Gold Runner Engine ported fairly easily to the iPhone and in pretty short order I had a perfectly functioning clone of Gold Runner for the TRS-80 Color Computer on the iPhone.

I polished it up, tested it, released it, and sat back to see what would come of it.

It sold a number of copies, I really don’t remember even a vague estimate of how many.

But, within a year of my releasing it, a company had bought the rights to the original Lode Runner game and began seeking out games on various platforms which they considered to be infringing on their newly acquired intellectual property. A number of games, including Gold Runner for iOS, were targeted and removed from sale.

Back in the late 90s when I was still working on the Gold Runner Engine, I had made some modifications to it for a new game I was intending to call “Gold Runner Plus”. I added in floating (roaming) gold bricks, teleporters and moving platforms. But I never quite finished those additions to make the new game.

When Gold runner for iOS was removed from sale, I decided the best thing to do would be to resurrect that almost-completed “new” code, port it over to iOS, and release a new game, one that would have play dynamics not found in Lode Runner, and thus would be immune (I thought) to claims of copyright infringement. But finding that codebase on old 3 1/2 floppies for a long-dead computer proved difficult. Indeed I still haven’t located it.

So now I have decided that the best thing to do is just release the iOS version of Gold Runner as open source.

The project can found on Github here.

I could end this entry here, but I want to use this opportunity to get something off my chest.

While Gold Runner for iOS was still on sale, there was one common criticism found in the reviews that it got. Every reviewer said the control scheme was terrible.

Now, we’re talking about a game with a main character sprite that was as small as 8 pixels by 9 pixels, moving around a tiny screen, and having to climb ladders that were 9 pixels by 9 pixels in size, and that used a touch screen for input.

There was no ideal control scheme for such a game.

Nevertheless, I offered three control methods: 1) on-screen buttons where the character only moves as you’re touching the button 2) on-screen buttons where touching a button starts the character in motion in the given direction until a different button is pushed 3) flicking the screen in a direction starts the character moving in that direction until another flick is performed or the screen is tapped.

Game screen with button controls

Horizontal game screen using "flick" control

It took some getting used to, but after playing several times, the controls – especially the flick method, were quite usable. But computer users have a tendency to give a program, be it a game or a productivity app, one chance, and if they don’t like the UI or the control scheme, they rant about it. I think it’s ridiculous, but it’s just the way things are. Nevertheless, bad wishes to those who ripped the control scheme on the App Store.

I would love to see someone come up with a better control scheme.

Ah. I feel better now.

One final thing. The original codebase was written in ‘C’ on a system that didn’t have what would be considered frameworks or even a reasonable set of APIs, by modern standards. It was shoehorned into classes to fit iOS design patterns. As such, it isn’t exactly the most sparkling set of code I’ve ever written, not to mention the fact that I wrote the original code just two years into my professional programming career, some 15 years ago. Nevertheless, it works, and shouldn’t be too difficult to understand.

All things considered, I’m pretty proud of the work I did on it, though I would never show the code off as an example of my best work.

So that’s it. I hope someone out there gets some use out of this code, and perhaps uses it to do something cool.

If you do, I’d love to hear about it.


Building Better iPad Tables

September 2nd, 2011

When Cocoa Touch first debuted, it only applied to tiny little handheld devices without much screen real estate to work with. As such, it made sense that the multi-column tableviews present in Mac OS X’s flavor of Cocoa were replaced in Cocoa Touch with a single column version.

But then came the iPad.

The iPad uses Cocoa Touch, but it has much more screen real estate to work with than an iPhone or iPod Touch. The iPad is fully capable of supporting a table UI that has multiple columns. And indeed the view-based architecture supports the ability to customize table cells to your heart’s content, even on an iPhone.

Nevertheless, it doesn’t seem particularly easy to approximate the UI of a data-driven desktop app on the iPad, as there doesn’t seem to be any method for more complex table layouts on the iPad.

But that’s exactly what I need in writing Giftory for iPad.

So I wrote it.

And now I’ve released it for anybody else to use.

The primary UI for Giftory on the desktop is a display of gifts, including, for each listed gift, its name, the store it was bought from, its price, the names of its giver and receiver, its hiding place, and a couple of other relevant bits of info:

Mac OS X Giftory Table View

Table View for desktop version of Giftory

This UI utilizes text fields, popup boxes, combo boxes and check boxes to achieve its functionality.

Cocoa Touch table view cells are generally only fit to embed labels to customize the cell to display several pieces of information. Some table cells have been implemented with a label to provide the name of a data field, and an editable area where the user can enter a value for the field. But editing multiple data element values always requires utilizing another screen.

None of this is suitable for editing multiple data elements for a given data object displayed on a single table row.

I created “Reusable Dynamic Table Cell Classes” to solve this problem.

These classes provide a subclass of UITableViewCell that utilizes objects built to simulate the functionality of pop up boxes, combo boxes and check boxes, as well as standard text fields and buttons. Using these classes developers can programmatically define a row UI for their tables, associate the row with a data object, such as a dictionary or managed object, and manage the data through the generated interface:

iPad table view

Customized iPad table row using Reusable Dynamic Table Cell Classes

The classes aren’t currently suitable for situations in which the row itself needs to be selected, but they are ideal for situations in which the table rows simply display various elements of a data object, and those elements are editable.

In the next post I will go into detail about the design of the data cell classes and how to use them in code.

The open source project can be found at:

In Search Of: The Next Platform

August 5th, 2011

For many years I’ve thought that the surest route to fame and fortune in the modern world of indie software development was to get ahead of the curve and exploit a new, emerging market before it really caught fire enough to get the attention of the big boys with multi-million dollar R&D budgets. That meant predicting what the next big unheralded  platform would be.

At one time I thought that platform was going to be In-Flight Entertainment Systems, those little screens in the backs of some airplane seats that allowed you to do everything from watch movies to play games to search for restaurants in your destination city. Unfortunately, that endeavor failed to take off, no pun intended, to any significant extent.

Next I thought that games, especially casual games, would be the big thing on Linux, which was supposed to take off as a mainstream desktop OS. But then Linux never managed to get that desktop foothold. And regardless, others had started placing bets on that market much sooner than I ever thought they would anyway.

I’m ashamed to admit that the two new platforms that really DID take off, and which I was perfectly positioned to take early advantage of as a long-time Mac developer, I completely missed the early adopter boat on. When the iPhone was opened up to third party development, I thought, “so what?” I never imagined that it would become the Next Big Thing and that simple apps that you could write in a week could make a million dollars. So you would think that I would have learned my lesson in betting against Appl… Steve Jobs. Yet, when the iPad was announced, my response was, “niche product that will never amount to much.” Oops.

So now I know never to bet against Apple/Steve again. And this means that I’m now preparing for the possibility that the next big platform is on the horizon.

Rumors are again circulating that Apple is preparing to release its own line of HDTVsIF this happens and IF such a device can run third party apps like the iPod/iPhone and iPad can, then maybe this is the Next Big Thing that I’ve been waiting years for.

Guess it’s time to start figuring out what kind of television apps I can write.


Apple Just Killed My Best Feature

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?

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.


Fending off Attacks on Average Joe Software Developers

April 14th, 2011

It was a year ago this week that I started this little venture.

Coincidentally, just yesterday I took part in a debate that typified the whole reason I decided to start this blog in the first place.

Be it specific to Cocoa development or more generally applied to the profession of software development, there’s a segment of our profession that only respects those with the utmost of programming skill, or at least those who strive to attain such.

In no field is EVERYONE “elite”. By definition that would be impossible. There will always be those who are “average”. In fact, by definition, the MAJORITY of people in any field will be “average”. But average doesn’t mean “mediocre”, (I just looked it up to be sure.)

A lot, if not most, of the software out there in the wild was developed and is maintained and extended by “average” programmers. These programmers are perfectly capable and competent. And they should be respected, even if they aren’t always striving to be elite, to learn all of the ins and outs of the SDK/platform/language that they’re using; even if they do things in non-standard ways; even if they buck platform conventions by trying to develop software on one platform using conventions and design patterns that they brought over from another platform.

The goal, for most programmers, is to produce a finished, working application.

Users of that application couldn’t care less how it was developed, if it “just works”.

There are programmers out there, hmmm… what did I refer to them as a year ago? Oh, yeah, “Hotshot Superstar Software Engineers“… who desire to have the most pristine, optimized, streamlined code that always uses the most appropriate aspect/feature of the language/SDK in its implementation.

Good for them. More power to them. I don’t begrudge them anything.

But personally, I would MUCH rather release a program that does something unique and is adored by users, but was implemented with code that was ugly, unoptimized and inefficient, than to write the most beautiful, optimized, streamlined, efficient routine to implement a feature 20% faster than anyone else ever has, and have users go, “meh, there’s a dozen other apps out there that do the same thing.”

So while Hotshot Superstar Software Engineers continue to degrade and belittle “average” programmers, I’ll continue to stand up for them, and proudly declare myself as a member of that group.