For companies who want to get something solid up and running on the iPhone quickly, there's really no better choice than to hire a couple of people with solid Cocoa development experience. They will hit the ground running, whereas other developers with no exposure to Xcode or Cocoa are going to have a solid learning curve facing them. People will tell you that Cocoa is easy to learn - and it is - but, like anything, it takes people a while to really wrap their heads around it fully.
But here's the rub: Mac developers, by and large, are a different breed than the developers you're probably used to working with in your large corporate environment. The majority of them are self-employed, part-owners of a small software company, or work in small, fairly autonomous groups within a larger organization. They are used to working in an environment that is the polar opposite of what most corporations and other large organizations foster. They are not accustomed to (and many actively avoid) bureaucracy and committee-based decision making, and they are accustomed to a lot of freedom in choosing how and when they work as long as they meet deadlines and deliver a quality product.
One of the first things you need to understand about Cocoa development (and it seems almost certain that this will apply to Cocoa Touch just as much), is that the entire language and the development tools are setup to afford maximum productivity to individuals or small groups, not to facilitate large groups of developers, analysts, architects, and other pseudo-developers. Cocoa groks the ideas found in The Mythical Man Month and rarely do you find Cocoa projects using more than a handful of developers. Do you know how many developers wrote iMovie '08? One… and he wrote it while on vacation. There are, in fact, many examples of great software on the Mac developed in Cocoa by just one developer, and a great many more that were developed by small teams.
So, the first rule for your iPhone team: less is more. You'll do much better getting a couple of really good, experienced Cocoa developers than a dozen coders of mixed experience levels and background. If you can't find any, invest in a good people and send them to the Big Nerd Ranch to get trained up, put them in front of a nice powerful Mac, and let them at it.
Second rule: don't ride herd on them. Get people in whom you have a high level of confidence, and then let them do their job. This is probably good advice for all employees and all development teams, but I've worked inside large organizations enough to know it's not standard practice. Resist your impulse to micromanage. It's a bad idea in general, but it could be devastating to your iPhone development team, especially if you followed the advice of my first rule and hired good, experienced Cocoa developers.
Third rule: insulate your team from corporate silliness to the fullest extent of your power. Nothing will make these people leave your employ faster than making them sit in unproductive, boring meetings that don't directly further the project. The kind of person you want, wants to be sitting in front of a Mac furiously coding away. Anything you make them do that's not that, is counterproductive and damaging to your project.
Fourth rule: forget your existing processes, project plans, and other schemes for world domination. They don't work to begin with, but they are blatantly fatal to this kind of software development. Too much process with kill your iPhone development projects faster than anything; every existing packaged process scheme is a case of the cure being worse than the disease. The iPhone tools and design patterns are not built to accommodate the kind of oppressive over-processing mechanisms that are all the vogue in enterprise software development these days. You'd probably get more done if you abandoned it for all your software development, but in this case, it's mandatory. If you use these tools, you will fail. If your corporate policies say you have to use them, get an exception, or else outsource your development to someone who's not fettered by silly corporate rules. If you try to force CMM, RUP, SCRUM, Six Sigma or any other form of expensive snake oil that your management thinks is the silver bullet onto your iPhone development team, you will smother it until it dies a painful death.
That's about it. I'm not a management expert, but I know Mac developers, and I know enterprise IT, and I foresee trouble brewing if those in the latter insist on trying to force those in the former into a mold they are not intended for.
No comments:
Post a Comment