About Little Green Viper Software Development LLC

Little Green Viper Software Development LLC was established as a New York corporation in May of 2012. Initially, only free, open-source software went through Little Green Viper, but it has since transitioned to a contract software development shop.

Chris Marshall


I love developing mobile software.

No, let me put it a bit more succinctly:


In 1986, I purchased my first Mac (A Mac Plus, maxed out with 4MB of RAM, and a 20MB external SCSI hard drive). It was love at first sight. I immediately started programming it with MPW in Pascal and 68000 assembly language. In fact, one of my first projects was a MIDI driver (which was quite a challenge, as you had to provide an external 1MHz clock from the MIDI interface, and do some intense ASM programming of the whacky serial chip). That stuff is quaint, compared to what we have at hand, these days, but I was really chuffed to see that DX-7 getting controlled from my Mac. A little while after I finished it, Apple released their own MIDI driver, which pretty much put a sock in my project.

Nowadays, I have moved to writing iOS (iPhone/iPad) software, using Swift, Objective-C and Cocoa Touch.

I also write server-side software (like WordPress or Drupal plugins); usually as part of a “full-stack” system, ultimately expressed as an iOS app.

Here is my LinkedIn profile.


Quite simply, I’m very, very good at what I do, I’m easy to work with, I’m honest, circumspect, delivery-focused, and I do very high-quality work. I will help you to understand the project, give you a high degree of visibility, engage you as much (or as little) as you want, and I won’t stop until the project meets and exceeds all expectations.


In most of my projects, I prefer to use a loosely-specified “rapid prototyping,” iterative development methodology. I do this, because in my experience, you can never address every issue in the specification phase. When I started programming, the general process was “measure twice, cut once.” You had extensive requirements and specification phases, short development phases, and long (often way too long) testing phases. Those were the days when “big iron” still ruled the roost, and dictated the process for all programmers. Modern development tools have progressed to such a state that it’s very easy and practical to quickly develop high-quality working prototypes of algorithm engines and user interface elements. Doing this allows us to try stuff out, and find the issues that we’d otherwise miss in specification. Also, we may sometimes need to make massive course corrections if we encounter an unexpected issue. Having a flexible working methodology is a life saver in these instances.

That said, it takes a lot of experience and discipline to successfully apply that kind of methodology. I am intensely focused on quality and usability, and apply absolutely rigorous discipline in my work. I sincerely believe that my considerable experience and skills make it entirely possible to work this way. I’ve been doing this for quite some time, with demonstrable success.

The alternative is to spend a great deal of time (and money) developing software that meets specification, has a low issue count, and is despised by users. I’ve done that, and it’s heartbreaking. My way results in exceptionally good software, very quickly.


This is an important question. I specialize in server-side coding (things like plugins for content-management systems, or content-management systems), and iOS NATIVE apps. Native apps means that they are written specifically for the iOS platform, using Apple’s native development languages. This is not a “cross-platform” (iOS and Android) development effort.

Why Go Native?

Native software takes full advantage of the system toolset. It runs as fast as you can get, and doesn’t have to worry about avoiding interface elements that aren’t available on the other platform (I call this “the lowest common denominator” effect). A native app will also generally be easier and faster to upgrade than one written using cross-platform utilities (often referred to as “hybrid”). Another issue is that most hybrid solutions are server-based, and require an Internet connection. A native app needs only the phone (usually). If your services also require an Internet connection, then the advantage of a “phone-only” solution is reduced.

In many cases, we are designing a system, customized for a particular audience or workflow, with prescribed devices (like a point-of-sale or restaurant ordering system). If those devices are iPhones and/or iPads, then a native app is the way to go. If you want to support Android instead, you may then want to consider creating a native app for Android (which I personally don’t handle).

And one last thing: Apple loves native. They will ALWAYS go out of their way to make sure that native gets “first cold press” when they come out with new tech and beta-testing. If you have a native app, you can be assured that Apple really does like you best. Having a native app shows that you are completely committed to Apple, and Apple has always rewarded developers that commit to them (I have been an Apple developer since 1986. It has been a sometimes frustrating -but always rewarding- experience).

That said, the choice is yours. There are solutions for creating apps that target multiple platforms. In some cases, these may be the way to go. When we discuss the project, I’ll be happy to advise you to explore these avenues. The very last thing that I want is for you to regret working with me. I’d rather not have your business than have you be unsatisfied with our relationship.


“UX” is an acronym for “User eXperience.” This term tends to be used instead of “UI” (User Interface) or “HI” (Human Interface). The idea is that users don’t “use” your product. They “experience” your product. Also, your product isn’t really a “product.” It’s an “experience.” This may sound a bit silly and pretentious, but it’s a dead-on accurate metaphor. I think that it’s important to think of the work we do as a narrative. A “story” that has many parts and characters, and doesn’t end. It just moves forward.

There are two books I’ve read that have had life-changing impact on me:

  • The Design of Everyday Things, by Don Norman

    This book completely changed the way I look at design. Don Norman explains the concept of creating usable and effective things; not just attractive and stylish things. It’s great that it looks good, but it needs to work. He introduces the concept of affordances, and teaches us to “play the tape through.” Make sure we look at the way things can be confused or misused, as much as how they can be properly applied.

  • The Simplicity Shift (PDF Download of the free book), by Scott Jenson

    This is a very short (almost a long pamphlet) book that talks about designing things with a minimalist UX, and the challenges and priorities we face when doing this. In the days when this book was written, the iPhone had not yet been created, so mobile interfaces were very basic. This book taught me how to prioritize my UX with a brutal efficiency.

My major open-source project, the BMLT, is used by tens of thousands of people every day, worldwide, and it’s not hyperbole to say that it’s a life saver. It has taught me that good UX is not a luxury. It’s a necessity. Making the web server software responsive, writing mobile client apps, designing the API, writing the documentation and helping people to implement and use the system has been a humbling and HIGHLY educational experience.

The BMLT has also showed me the importance of the mobile user experience. A majority of the folks that use the BMLT do so via their phones. Not their computers or tablets.

Their phones.

This means that serving mobile users is even more important than serving desktop/laptop users. I need to make sure that the software works well on mobiles first. This article was written in 2012. Think things have improved for computers since then? Think again. We need to take mobile devices very, VERY seriously. Gone are the days when writing a “mobile version of your site” was a luxury. Thankfully, we no longer need to write WML versions of our sites. In most cases a responsive Web site (like this one) is all you need.


One of my favorite quotes is:

“We are what we repeatedly do. Excellence, then, is not an act, but a habit.”

In my experience, this is true. “Quality” needs to be wrapped into our DNA. It isn’t a coat of paint that we apply to the finished product. It’s something that needs to be mixed in, as a principal ingredient, from Day One.

Quality is a Relationship

“Quality” needs to be defined as more than just “meets specifications and doesn’t have any high-priority bugs.” It needs to have an emotional component. Do your users enjoy using the software? Do they choose to use it when there are other alternatives? Do they like to show off their expertise with your software? In some cases, an enjoyable, seamless UX is MORE important than even major axes, like functionality and flexibility.

Your software should never crash, and it should have a friendly, robust error handling system that doesn’t intimidate the user. It should also deliver its primary functionality. However, I’d say that having a rich UX is more important than implementing some minor feature that only a few users will ever exercise. Quality is a continuum; not a single number. It isn’t just a low bug count. It’s an indefinable “I just like it,” that can’t easily be measured. This goes double for mobile UX.

Writing quality software is more than just using techniques like TDD. It involves having an emotional relationship with your product, and also, even more importantly, with your product’s users. Over the years, I’ve learned a lot about writing quality software (and also about writing bad software). One of my goals, moving forward, is to deliver a rich, robust and engaging user experience in my software. I want to write software that I want to use. Software that I want to keep for myself. I want the act of delivering software to be a bittersweet moment.

Which is actually going to be YOUR software. It will have your imprimatur on it, and you want that to be as high-quality as possible.


I write ALL my software to be localized. That means it’s designed to be translated and modified for multiple locales. I speak English, and the native development environment is US English. However, it’s a big ol’ world out there, and there’s lots of different languages and cultures. If you want to support them, then you need to start from the beginning. You need to develop your software using the methodologies that Apple recommends. This is something that you need to plan from Day One.

The BMLT is used all over the world, and is localized in several languages (more on the way). I worked for Nikon for almost 27 years, and “cut my teeth” in a truly global environment. I’ve been handling localized software for a long, long time. I also grew up overseas. I’ve been embedded in the wider world for my entire life, and localization is basically second nature to me.


This Web site is a sincere effort, on my part, to give you as much information as possible about me, what I can do, what I have done, what I think, how I work, and who I am. If this were a job interview, it’s my goal to give you 75% of the information you need before we even talk. Feel free to wander around this site, and examine some of my writings. For example, my explorations of the Swift Programming Language are very useful. I also have tens of thousands of lines of code, with YEARS of checkin history in various repositories and source code management depots. That’s a very revealing look at any developer’s record. You can see my work, compile it yourself, run it, view the comments I made as I checked in edits, and develop a narrative of my methodology.

Go ahead. I really am an open book. I’m confident that you’ll like what you see.

Open Book


If all that sounds good, let’s talk about what I can do for you.