Protoven

At Protoven, we write code and provide wireframing and design services for companies like ABC / Disney, Nu Skin, Brigham Young University, customers whose source code, digital assets and data are important.  We also work with smaller companies such as MusicPeeps.com, MonitorCongress.com, Docuprep and others.  Is their data any less valuable?  Let me ask the question this way, Is your data less valuable than anyone else’s?

For us, the measure of success is twofold.  The customer is pleased with the final product and the customer pays the balance of their bill.  That’s rarely the end of the story for us though.  We make an investment in the relationship from the get go, and we suggest you expect the same from any contractor you work with.  It pays dividends for us in the form of repeat customer work.

When you’re searching for contractors, add the “data value question” to your list of concerns.

You may not think of it as such, but source code should be included in your list of valued data.  do you know what your contractor does with your source code?  Do you know where they store it?  Do you know where they back it up to?  They do back it up, don’t they?!

Here’s some questions you should ask your contractor about, and can expect someone that knows what they’re doing to be able to answer on the spot.

Q: What version control software do you use?

You’re looking for an answer.  One that doesn’t say, “Well I store it on my machine and sometimes I back things up.”  Great answers will include Git, Bazaar (bzr), Mercurial.  If your contractor is a Microsoft shop then Visual Source Safe is a good answer.  Subversion also a decent answer.  Refer to http://en.wikipedia.org/wiki/Revision_Control for more information than you care to learn about the topic.

This question becomes even more important if you’re having your contractor work on mulitple phases of a project.  How do they maintain one version of your project while working on a new phase?  Great SCM tools will facilitate this type of development workflow.

Q: What bug/feature/issue tracking software do you provide?

Perhaps this is a non-issue for you because you provide your own.  Most of the time Protoven’s clients do not have issue tracking software.  We provide these clients a project on our redmine server.  We stay familiar with all sorts of packages though, so we can quickly integrate with customers that do have their own systems.  We’re very familiar with Jira, Bugzilla, Trac among others.  Those are definitely the most common we’ve seen.

It’s important for us to stay on the same page with our clients.  Issue tracking software helps us to do that by providing a forum where all parties can track requests and close feedback loops.  It’s invaluable to return to this list of issues and refer to project specs, and design decisions that live there.

Q: What is your backup policy?  Do you backup off-site?

A company that isn’t concerned about backing up data is a company that won’t be around very long.  All too often, things go terribly wrong in this technological utopia we live in.  Hardware and software fail and leave you high and dry.   Ensure your contractors are invested in disaster recovery plans for your data.

Q: Can I view the progress of my project before it goes live?

This is extremely crucial for our clients that contract web development with us. Each of the Protoven developers operates in 3 environments they have varying degrees of control over.

The production environment is the goal machine.  It’s where all the website hits are served from.  It’s where the real financial transactions take place.  It’s where all the real security certificates are deployed.  This environment, which could be one server machine, or dozens of servers, is tightly controlled.  Code deployed here is well tested and ready to release.  You and especially all of your customers should have access to this environment 24/7.

The staging environment is similar to the production environment in architecture and installed systems, however source code is deployed here much more often.  The audience for the staging environment is smaller, and the functions of this environment are never mission critical.  It is used for wider testing and integration across multiple systems in the project.  While it can be used for demos of new features in the project, your contractors should generally have the freedom to take this server off-line as needed.  You should expect access to this environment.  There should be an expectation of volatility depending on your project’s development cycles as well.

The development environment is the developer’s machine.  It may include a virtual machine which runs the operating system and software packages that will be running on the final production environment.  Very rarely do our clients see our development environments except in cases where development is happening at such a quick pace, that a local demo is acceptable.  As you might have guessed, this is the most volatile environment as new code is being added, changed, updated, etc. all the time.  You should not expect access to this environment.

It’s reasonable to expect to see progress.  You don’t want to commit thousands if not hundreds of thousands of dollars to a project without being able to provide feedback during the project.

Again, these are tools and processes Protoven offers to its customers as part of the way we do business.  In some cases we’ve even set them up for customers and they’ve paid for them, even when we don’t charge people for them explicitly.  It gives our clients peace of mind.

It gives us peace of mind.

Note: If you’re a contractor and would like to offer these services to your customers, contact us at info@protoven.com for more information on our hosted solutions.

You can find our Facebook page (and become a fan?!) at http://bit.ly/ptvnfb

4 of us will be making the pilgrimage to San Francisco’s Moscone Center for Apple’s World Wide Developers Conference this year.  I was able to attend last year, and I’m excited to officially attend as a Protoven Dev this year.

One of the popular things to do is hit the bar scene in the evenings.  Being from Salt Lake City, you can probably guess reasons why that won’t be a popular outing for us. (Except, I have promised a beer to Daniel Jalkut, so I’ll have to make good on that.)  Rather than join the communal sloshing, we’d rather find a place to write code.  I’ll be making the rounds in the dev forums asking as well, but if you have any suggestions on a good place for 4 guys to code, I’d appreciate a Twitter DM to @protoven or @tbye.

We’d love to meet you, so please don’t hesitate to say hi.

Hope to see you there!

When Apple unveiled its new license agreement last week, everyone “knew” this was nothing but a shot across the bow of Adobe, and the timing was hilariously cruel. But then Apple Insider reported that the restriction might be somewhat legitimate as it might be needed for multitasking support in iPhone OS 4.0.

I can sort of buy into this because the Objective-C runtime is somewhat mystical in my eyes - every time I poke around it seems to be much more dynamic and similar to higher level dynamic languages like Python or Ruby than its name would imply.

I could sort of buy into that reasoning right up until I remembered that the new agreement still allows C and C++:

Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs

Given that C is more or less the new assembly language, it makes me pretty skeptical that their multitasking would rely on some characteristics common to C, C++, and Objective-C that aren’t or can’t be present in other languages.

Not only is it unlikely that Apple would really rely on some weird characteristic of C, it’s also really unlikely that they’ll be able to enforce this requirement in a general way. Sure, for any given toolkit the apps will have a signature or “fingerprint” that Apple could detect via automation, but they’d have to write checks specifically targeting each one.

In general it seems that if C is an approved language, there isn’t going to be any way to actually detect if internally the app embeds an interpretation engine for some other language or if the code was originally written in some other language and then auto-translated into a sanctioned language, unless Apple stops accepting binary app submissions and instead requires source code submissions. Hopefully that’s so laughably bizarre that nobody would go along with it. (Ugh, as long as there is a market, people will go along with it)

A part of me is holding out hope that Apple is just testing the waters to see what they can get away with, and that there will be enough of an outcry that they’ll back off a little. If not, then I believe that the real outcome of this move is to kill off the commercial iPhone OS framework industry but not the actual use of such frameworks.

As in, if you make an app that internally uses your own Python framework, Apple won’t come knocking because (1) it’s really hard for them to even know you’re doing it (2) you’re just you - and not really a threat to their platform dominance, and (3) they can knock you off at any time and you don’t really have the clout to do anything about it.

But if you are the next Unity or Monotouch or Appcelerator and start becoming well known, you’ll make Apple uneasy enough to justify the time to write the automation to detect apps based on your platform, and that will put a chill on your customer base and ultimately run you into the ground.

The upshot is that, if Apple sticks to their guns, the “compatibility layers” and other tools that let us write apps in something less archaic than Objective C will go underground or flourish as open source projects and not as commercial offerings. They will exist and will give individual developers or companies a competitive edge but won’t be products you can easily buy because without a market for selling them, there won’t be much incentive to create them for others.

And maybe Apple is more or less ok with the use of tools that accelerate development of apps for their platform. From Apple’s perspective, the big problem with most of these existing frameworks is probably that they put so much emphasis on write-once-run-anywhere. To a company where the platform is the real value, any tool that diminishes the importance of the platform must look pretty threatening.