The component business is relatively unexplored territory in the iOS world. It is a well-established entity in other development eco-systems, like .NET or Java development but is still finding its feet in iOS in particular, and to some degree the wider mobile development space.
Given ShinobiControls is a component provider and we intend to help define this market in the iOS space in the foreseeable future, I thought it would be worth talking a little bit about why component vendors exist, what the logic is and why it could make sense for you.
Money, money, money, makes the world go round …
The obvious starting point in my argument is that purchasing stuff off the shelf saves you money. Here’s the argument: Let’s discount for a moment that iOS and Objective-C are still specialist technologies and so attract a premium and just consider that the average salary for a mid-level software engineer (hereafter called Average Developers) in the US is $73,740 according to salary.com. That, assuming 250 productive days per year, is a day rate of almost $250 per day. That’s a conservative estimate too, if you factor pensions, healthcare, bonuses and so on the number is much more like $100K or $110K per year. I think you can probably already see where I’m going with this.
I’m sure your Average Developers are in fact above average and they could churn out objective-c code faster than you can say “Alan Turing!” but it’s still going to take you multiple man-months to get anything close to what one might call a piece of production software. I wouldn’t like to make an estimate as to exactly how much time it would take because it will depend on the types of controls you need and how complex your needs are, but we’re talking tens of thousands of dollars here – not pocket change. As an example, say it takes your team 3 man-months to rustle up a control that meets your needs, that’s 70-odd man-days which is of the order of $20,000 – just to get you started!
Hold on though, we’re not done yet. Now you have many, many thousands of lines of code to maintain, so you’re going to have to devote some of your developer time to fixing bugs and expanding functionality. Now I should say that there are lots of different ways of estimating the Total Cost of Ownership (TCO) of a software development project but they all tend to agree that the initial development phase is the cheap part.
Maybe you’re willing to take that hit. After all, it’s not just about money, I hear you say.
You’re absolutely correct – it’s not all about money. If you build your own components you are sure to get exactly what you want – or at least so the argument goes. Take it from me, though, building highly interactive components is not easy. Maintaining the quality of your controls throughout their inevitable evolution is not simple either. It takes some expertise to write reusable, maintainable and user friendly controls – not to mention the visual look which as we know is generally not the developer’s forte.
Think twice before you decide that it’s just a matter of throwing some developer resource at the problem and it’ll all work out okay in the end. Also bear in mind that if you short change the quality and power of your controls, it’s not just that you’ll have more bugs (which you probably will), but it’s your users who ultimately pay the price in terms of a lesser user experience when using your software.
The other side to consider is that developers will happily write new controls. That’s exciting stuff! It’s getting right under the hood, doing green field development … what more could an engineer want? No doubt, this is someone’s idea of a great project. However, as soon as the development is done, and the project moves into the maintenance phase, things get rapidly much less exciting. Now no-one really wants to touch it with a barge pole. Ugh, support can be seen as boring and tedious and monotonous a lot of the time, so now you’re faced with either taking that (above average) Average Developer who wrote the thing and lumbering them with supporting it or rotating them out and starting from scratch again with training someone else up on it, or even having a whole team of people on the project in the first place and sharing the load.
It’s a problem and often turns into a staff retention headache.
The key to success is to focus on your core business
All that being said, I think the most compelling argument, is not a financial, HR or quality one. It’s a business one. Successful businesses are ones that spend their energy on their core business. Unless you’re a software component development house, writing software components is not your core business, so it’s probably not where you want to be spending your time, energy and money. Much better to have your developers spend time improving your core business proposition and gaining the skills and experience in that area where it will have more lasting value to your business. Well, that has always been my approach in the past anyway and I have seen the effects of not following this wisdom.
I know this has ended up sounding an awful lot like a sales pitch and to some extent it was one – I won’t even deny it. That doesn’t make it less true though and we honestly do believe our business model makes sense and is in everyone’s best interest. Of course, there are cases where writing your own components makes sense, either because you want the security of it being in house or because your requirements are so esoteric they can’t possibly be satisfied by a prebuilt component and that’s fine! We’re here for the other 99.9% of the cases.
By the way, if you’re worried about licensing conditions or longevity of our support or flexibility of our controls, just get in touch! We’re happy to discuss further.
Images provided under the Creative Commons licence by: