Tools for a Distributed Software Agency

One of the things that I am most proud of is that Silverpine is a 100% distributed company. Often when people find out that we are fully remote, they will ask curiously about what tools we use to work together. This is completely understandable because the importance of having the right tool set is magnified for remote companies. We understand this innately and as such we are constantly evaluating our software stack. The following list represents the software that powers our business. (I have intentionally omitted some of the lower level development tools like Xcode and Android Studio.) The list is broken into four primary classifications: communication, development, project execution, and finance.

Communication

Slack 

Before Slack, we used a hodge lodge of messaging tools like AIM, Google Chat and even old school SMS. It was horrible. Slack is the single most important tool that we use to communicate with each other and with our clients. All of our employees and contractors use it extensively every day, and even though I think that there should be some middle ground in their pricing between the paid and the pro plans, I can’t imagine trying to work remotely without it.

Webex

Let me just preface this by clarifying that I think that every single conference calling platform is terrible. I have used them all. From Zoom.io to Google Hangouts to AT&T Connect, they are just barely workable. Besides the all too common call drops they also all seem to suffer from ridiculous installation processes and byzantine user interfaces (Does this yellow button state mean my microphone is on mute or can they hear me?)

That being said, we have been using Webex for a very long time; not because it is good, but because it is better than the alternatives. And for our enterprise clients, it is somewhat of a known entity so we seem to spend less time per call doing the “can you hear me” dance. I wouldn’t say that I recommend Webex. It’s just what we use.

Dropbox Pro

We have been using Dropbox on personal plans for quite a while, but we recently decided to standardize on Dropbox Pro for file sharing. All of our projects have quite a bit of documentation, graphical assets and other large files that aren’t well suited for source control tools. Dropbox allows us to create per project file drops that we can easily access as well as share with other people when appropriate. We almost switched to Box.com because their pro plans have unlimited storage but ultimately decided it would be less transitional headache to just upgrade our existing Dropbox plans.

G Suite

We have been using Google for our email and calendar services for so long that our silverpinesoftware.com domain is still functioning under the original beta operating agreement. If G Suite disappeared I honestly wouldn’t even know where to start looking for a replacement. File this one under “it just works.”

Development

InVision

One of Silverpine’s guiding design principles is that every user interface needs to have a beautiful “feel” to it, and that you simply can’t judge the feel of an app until you can hold it in your hand and interact with it. Because of this philosophy,  we have refined our development process over time to rely heavily on InVision to prototype the UI and UX of our apps before we ever even start writing code. The amount of time and pain it saves both us and our clients cannot be overstated. If you design for mobile, you really should be using InVision or something like it.

GitHub

If you write software, you should be using a source control platform. If you need a source control platform you should be using GitHub. If you’re using something else, I’m sure you have a reason for it, but it’s probably not a very good reason. (All of our projects use GitHub repositories so when they changed their pricing model to be per user rather than per repository, it made our lives a lot easer.)

Azure DevOps

This one might surprise some people, but a couple years ago we transitioned to what is now known as Microsoft Azure DevOps for our automated build system and have been using it ever since. Prior to Azure DevOps we had used a variety of tools including TestFlight (bought by Apple), Fabric (bought by Twitter, then bought by Google), and BuddyBuild (ran out of money). Due to intense consolidation in that particular sector, we were frequently having to retroactively change our toolset which was both time consuming and costly. A friend of mine who works on the Microsoft tools team encouraged us to give Azure DevOps a try, and we have been extremely happy with that decision. Azure DevOps supports both iOS and Android, is massively configurable, has 24/7 support and most importantly, is backed by one of the largest companies in the world so it won’t be disappearing any time soon. If you need an automated build system and haven’t taken a look at Azure, I highly recommend at least kicking its tires.

Project Execution

Basecamp

For many years, we wandered in the desert of project management, largely piggybacking on whatever project management tools our clients happened to be using at the time. As such, we have used everything from Jira to Asana to Microsoft Excel to track projects and tasks. However, in the past year we have implemented Basecamp as our standard internal project tracking tool. One of the things I like best about Basecamp is that it has clearly been thoughtfully designed. Not only is it powerful, but its design somehow works to ensure that it doesn’t become overly burdensome in the same way that other similarly complex tools do.

Lighthouse

If there was one piece of web software that I would invest internal Silverpine resources on, it would be a lightweight bug tracking tool. There just aren’t many platforms out there that can strike a balance of utility and ease of use that errs on the side of ease of use. For now, Lighthouse foots the bill for us in that regard, however, I’m not sure how much longer it will be around. There hasn’t been any significant development done on it in the 6+ years that we’ve been using it, so I’m not sure I would necessarily recommend it. That being said, it does what we need bug tracking software to do, and it does it well, and I haven’t found a replacement. If you have any personal favorites, please let me know.

Finance

Blinksale

Silverpine is a services business and sending invoices to our customers is literally how we are able to make money. Blinksale is the tool we use to send those invoices and look like we are professionals in the process. While it isn’t a complex tool, it expertly does what we need it to do: send and track professional looking invoices. If you send invoices to clients, you really should be using a tool like Blinksale because people can tell when you don’t.

Quickbooks

Nobody really loves Intuit. They have created not one, but two near monopolies with TurboTax and Quickbooks. However, if you run a business, you need to track your finances in a way that your CPA can help you with your taxes at the end of the year, and if you tell your CPA that you use anything other than Quickbooks, they will not be happy with you and they will very likely take longer to do your taxes which means you will end up with a higher bill from them. That is the reality of Quickbooks and that is why we use it.

Gusto

If you have employees or sub-contractors that you need to pay, you really should be using Gusto. The folks at Gusto are wizards when it comes to dealing with payroll taxes and W-9’s and a great deal more things that I simply don’t have to worry about because we use their service. Not only is the Gusto platform super easy to use, but their customer service team is actually pro-active in notifying us of upcoming tax law changes that might affect us. I am continually in awe of how great Gusto is and cannot say enough good things about them.

 

Thanks for the Memory

How much memory can an app allocate on an iPad 1? It seems like a trivial question. The original iPad has been in circulation for over 3 years now and developers have written thousands of apps, many of which are memory intensive. Given this, one would expect that this limit has been well documented and should show up easily in search results. As I found out recently, this is not the case.

A few weeks ago, I needed to revisit memory consumption on an app running on an iPad 1, and I became very curious about the answer to this question. After searching various sites I was mostly coming up empty. To my surprise, it was quite difficult to find this documented anywhere. Apple’s own documentation is of course great reading for any developer but remains mum on memory budgets. Perhaps the best documentation I could find was this Stack Overflow post, but it didn’t seem to be definitive and as with all Stack Overflow posts, caveat emptor.

One thing that I did find sprinkled around the various posts on the topic was a link to Jan Ilavsky’s tool that he wrote to measure on a device the various points when an app receives memory warnings and then ultimately crashes due to insufficient memory. Here’s a shot of it in action. Using Jan’s tool, I decided that perhaps I should help contribute to the collective information of the Internet by running some tests and documenting them.

So as not to boil the ocean, I decided to analyze only the iPad family of devices. My test devices included: a first generation iPad, a second generation iPad, a third generation iPad and an iPad Mini. All of the devices were upgraded to the latest version of iOS that supported them*. My procedure was to force quit all apps on the device before running the test app and then to run the test a minimum of 10 times on each device. I would then throw out the low and the high and graph the results. I found to be both interesting and somewhat predictable:

First Generation iPad
First Generation iPad (iOS 5.1.1) 
Second Generation iPad (iOS 6.1.3)
Second Generation iPad (iOS 6.1.3)
iPad 3
iPad 3 (iOS 6.1.3) 
iPad Mini (iOS 6.1.3)
iPad Mini (iOS 6.1.3)

One of the more interesting things that jumped out at me is the fact that Apple seems to take memory optimization seriously, and that their approach appears to not be a one size fits all method for the different devices. Notice how on the second generation iPad and the iPad Mini the OS continues to optimize in order to allow the app more room in which to operate.  Contrast that with the first and third generation iPads which appears to have a flat, non optimizing algorithm.  If indeed memory optimization does have a certain amount of device specificity to it, it would appear that Apple put less time into optimizing these iPads.

This of course makes sense as the first iPad was a previously non-existant category, and the third generation was the first iPad with retina display. You have to imagine that it was a pretty massive undertaking to introduce the retina concept on an OS, toolchain and device level. I don’t think any engineer alive would be surprised if the schedule became tight on these projects. The point here however, is that Apple does indeed pay attention to the details and that permeates all the way down to device specific memory optimizations. Developers should of course never become reliant on the presence of these optimizing algorithms but the fact that Apple puts that much attention into it is impressive.

So, back to my original question of how much memory you can allocate on an iPad 1.  Drumroll please. Based on my results, I would say that for the iPad family of devices the following are the maximum allocations that can be performed by an app:

First Generation iPad: 160 MB

Second Generation iPad: 250 MB**

Third Generation iPad: 515 MB

iPad Mini: 275 MB***


Now, I wouldn’t be doing my civic duty if I didn’t point out that these numbers include things that are entirely out of your control such as core graphics objects.  The test application is the most plain vanilla of apps so the minute you start making anything interesting this number will begin to be impacted. In the end, there is simply no replacement for good old fashioned testing and optimizing so keep that in mind as you’re setting out to make the next Angry Birds. I do find this helpful however because it is useful to know and be aware of what my overall ceiling is so that I can spend time optimizing the things that need optimizing and spend the rest of the time building features.

* iOS 5.1.1 on the iPad 1 and iOS 6.3.1 on the other devices
** The 2nd gen iPad appears to be able to go as high as 295MB
*** The iPad Mini appears to be able to go as high as 315 MB