Good development practice

I’ve just finished reading Hunt and Thomas’ excellent Pragmatic Programmer for the second time. It’s been a while since I last had time to get my head inside development books, but it’s been kinda refreshing. Added to the fact that, for all the creating I do, it seems I’ve had to spend chunks of time recently working through other people’s code and doing my best to propagate best-practice principles.

I suppose it is a natural progression, particularly in such a young market. iOS development has only been around for a few years, and there’s still that buzz of excitement when anyone speaks about app development. It’s still in its cool phase, and it draws a many and varied talent base, a considerable number of whom this is one of their first main development in-roads. It has taken me the better part of 15 years to get where I am (wherever that may be), so it comes as no surprise that many of them can count the number of successfully completed projects on one hand.

There’s ability out there, there’s no denying that. But the problem lies not in the skill set, but in the timing. Apps are big business right now, and many big brands are pushing hard on the app wheel. The trouble is they simply can’t get enough apps developed quickly enough, there simply isn’t the talent to cover the work load, not by a long stretch. In fact, I’d go so far as to say that much of the world’s senior development experience is still doing what it has done for years, manning development teams, creating quality, best-practice code and locking it up in big business. After all, if they’re happy, and they’re getting paid, why should they alter the status quo? So the iOS app development market has no choice but to take on less experienced developers simply to keep up with the workload, some of which can work out very well for all concerned, but some of which can leave a legacy of pain for years to come.

Pragmatic Programmer has given me a chance to remind myself just how difficult this job is, how easy it is to make mistakes, head in wrong directions, and generally cause headaches for all involved. It is a fantastically educational tome, and I think if I were to employ any new recruits right now, I’d be looking for them to have read it, and be conversant with its key principles; orthogonality, Don’t Repeat Yourself, coding defensively, all seem second nature to those who have coded through the last decade, but the amount of iOS code I’m coming across that flies in the face of even these most basic of principles is simply staggering. The worst thing about this situation is that clients need to get experienced developers on such code just to keep it working. It’s crazy to think that some of the best talent in the industry are spending huge chunks of their time fixing this bad code instead of creating new apps.

Reminding myself of the contents of this books means I can at least do my part to pass on some of what it means to write good maintainable code for clients. And I guess we should always try to take the opportunity to pass on what we’ve learnt. Sure some of us might lose some work as the bad code that would otherwise need maintaining slowly disappears, but just thinking of all the great apps we could all be writing instead would seem like a trade worth making.

Leave a Reply