Posts Tagged ‘Design’

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

Thursday, 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.

Are you a Software Architect?

Tuesday, 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

Tuesday, 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.