Oops another tech post with a car analogy! Yeah I know. Bear with it...
I've been mulling on a topic for while, that of how useful are the pre-built tools/classes/frameworks/libraries that are available on github, bitbucket et al...
Of course they are often immediately useful, in that they can quickly add functionality to an app. Functionality that leverages technologies that you would need to research, understand and implement yourself, often learning, through painful experience, the gotchas and oddities that lie underneath seemingly simple interfaces.
They can be immense, and practical savers, of time and effort.
They can also be useful in a more long term way. You may know the destination you want to reach in terms of a specific function but not know the route to take.
Reading through and following a well-written class or library can teach you much about the right way to implement both the specifics of a feature and the more general practices of good code.
I'm happy to raise my hand and say that this is often the practical reality of my full-time working life. We have a well-written and robust framework at the heart of of the digital publishing apps we build. Having a view into its code has taught me much good practice and a healthy respect for those that wrote it. I've also started to identify and tag areas that need improvement. Given the depth of complexity of the task the framework achieves it's a wheel I am glad to not have to reinvent.
Well, that sounds definitive, right? The defence rests.
At this point you may imagine a humble yet persuasive prosecutor (I'm thinking Kevin Spacey for the part) standing to offer a counter point...
I accept that the realities of professional software development mean there is not time to treat every project like a research project.
I agree that standing on the shoulders of giants in no way diminishes our own achievements.
However, I question where the line is being drawn and whether we are walking down the path of black-box solutions a bit too far.
Let's posit a scenario: You're working on a splendid new iOS app.
You need it to do thing X. You've never implemented thing X before, and hear it needs some complicated use of UIBadlyDocumentedThing and NSTheMagicOfBindings.
You start to think of ways you might speed up this bit so you can get on with the stuff you enjoy like messing around researching exactly the right shade of EverySocialNetworkEverBlue or the correct amount of bounce to give that settings window.
You might very well find yourself looking at a crossroads with signs pointing to:
- Apple's generally-great-but-occasionally-maddeningly-sparse documentation: 1000km
- Google* > StackOverflow > Cmd-C > Cmd-V: 1km (beware rockslides)
- Online tutorials: 250km
- Rants about things being considered harmful: -1000km
- Github > XYZ_MiracleLibrary: 100km
That documentation route looks looooong!
The StackOverflow road is tempting, but I've been crushed by the rocks before, and the temptation to just 'forget' to read the actual code I'm copying is too great...
Visiting Uncle Ray's gingerbread house sounds good, though it's still a bit far to walk.
I'll be the judge of harmful, or at least I'll wait till I hear a better informed opinion on a podcast first.
Ah, this looks interesting, a library that does just the thing I need with a single method call! Oh, and a few imports like core data. (clone > submodule > ding!).
You can probably see my concern. What exactly have we learnt this way? I'm not convinced that it's any more that just xerox-ing the code from StackOverflow.
Wait, though, isn't this really all we do when we use Cocoa? If I'm really going to be so precious about seeing the Matrix and not the Simulcra then why don't I just implement everything in C, or better yet Assembly or just get right down to it and have a keyboard with just 0 and 1 keys?
Well, it's because there are people, and their collective knowledge, that are smarter than me. These people think a lot about how granular to make the tools we have been given. It's their job to make sure that on one had the process of developing for our platform(s) of choice is smooth enough to keep us going and challenging enough to keep us interested.
I'm not saying you have to go the documentation route, but there's a lot of great tutorials out there that demonstrate how to get to where you want to go and you'll learn a lot on the process of doing it.
This is where the Beetle vs Golf analogy in the title lies, especially in terms of where I, as a programmer sit.
I loved the Beetle. I remember being in a Beetle with my best friend, Paul. We were driving round a roundabout one evening and we heard a very loud pop followed by a rattling sound and a lot more engine noise than we were used to. We stopped to find that one of the spark plugs had worked loose and was bouncing around the engine compartment. We screwed it back in place, reconnected everything that was loose and fired her up. Fine, at least good enough to get us home.
By contrast, buy a new Golf, open the hood and wonder where on earth a spark plug might actually be amidst brightly coloured labels for water, lubricant and window washer fluid.
As a car driver, I'm happy to not have to care about these things anymore, that cars have evolved in terms of reliability and serviceability to the point where ad hoc solutions and roadside emergencies can be avoided by a yearly service.
But as a software developer? An engineer? That's not what I want of my coding tools, they are not a smooth ride to a destination they are a journey.
I will freely admit that I am a better Cocoa and Objective-C developer than I am a general purpose programmer. But knowing that makes me want to look into the tools I do know to learn more about the things I don't.
To choose a specific case: I admire, recommend and am heartily jealous of the achievement that is AFNetworking. I just choose not to use it because I want to know how to do it. Could I implement it myself? Over time, with thought and care, then yeah maybe I could. This in *no way* diminishes the achievement that AFNetworking is. Just for the sub-functions of it that I need I could put something together and learn something myself.
Plus, have I used a tool like that? Yeah of course, iRate as an example.
My rational? I could probably do a better job of implementing an iRate-style tool in reasonable time that I could AFNetworking so I feel less like I have something to lean from the process and therefore feel OK to use the pre-packaged option.
So what are my solutions?
Well one of the other things you find online are example projects.
Are they a better option? Sadly, commonly, no they are not.
BUT could they be? Yes they surely could.
Why and how? Well, IMHO....
- Add appledoc formatted comments to headers so decent documentation can be generated***.
- Write a clear, thorough README, nicely formatted in Markdown that explains the purpose, flow and methodology involved.
- Add good comments to the code to explain decisions in place.
- Avoid Massive View Controllers** for clarity.
I personally find, in the absence of a tutorial, when there's no time to learn it all from scratch then reading a well-formed and decently documented project to be a better option than a context-less library where the expectation is to drop it in and don't ask questions.
*other search engines are available, at least for now, YMMV.
**kudos to Daniel Tull for identifying the phenomenon in his talk at iOSDevUK 2013.
*** I'm painfully aware I need to do this in my own example project, recently posted to Bitbucket. It's in progress. You'll have to trust me.
