Program on purpose

I was at my favorite software developer meetup group a few weeks ago and in one of our many random discussions the topic of “program on purpose” came up. It sounds simple enough but the truth of the matter is that people just want to “get things working” and move on. There would be a lot less bugs if that wasn’t the mentality of a lof of developers out there.

“Q: I’m getting this one error….. A: Did you check Stackoverflow?”

I heart Stackoverflow. It was a game changer for sure. The software developer industry is pretty well documented on the web to begin with, and finding answers is just a few Google searches away but since SO the first 6 or 7 search results could be the same answer to your question. With that said it’s even easier for someone to go into the thread see that green checkbox, spend a few seconds to see if it was what you were looking for, highlight the code, copy, paste then bam. You just “got it working”. The problem is the code you just pasted into your project may not have been written specifically for the the same context of your application with the same architectural structure and design choices in mind. You can say this isn’t true for small things like “how to get a substring” but what about for things like concurrency? Sometimes we have to design workarounds because of a limitation on a specific platform but sometimes you’ll see just plain hacks as answers. I wonder how many times a code snippet was just used without thinking about the ramifications. Even better, did you write a test along with pasting the snippet? ūüėČ Take some time and think about how it could fail before continuing to write more code then forgetting about what you just did. Anyone can get things working, a good programmer will know how to account for failure. Program on purpose.

Github makes our lives easier

Another game changer. What better way to learn then to read more code written by people who are trying to solve the same problem. What’s even better is the author says you can use it in your own project for free! Without warranty. I’ll say it again, without warranty. It’s so easy to clone a repository and put that code into your existing project. Did you even see if the code you grab had tests? If you’re programming on purpose, you’d most likely give that library a very good look through and see how it was crafted. You’d know how it should fit into your architecture, understand the trade-offs and see unneeded code. Understanding what you’re getting yourself into could save a lot of technical debt int he long run.

The new generation of software developers are assemblers

The software world is moving faster then ever. Release early and release often is a common mantra of dev teams. To assist us we have higher level languages and package managers that go with them. Frameworks upon frameworks do a lot of the heavy lifting for us so we can spend time creating features. ¬†It’s very easy to build bad habits and practices because we’re too focused on shipping fast and the higher level languages, packages and frameworks take care of a lot of things for us. Some things like efficiency or proper error handling can get easily overlooked or completely forgotten about. ¬†I’ve seen this a lot in transitioning web developers to Objective-C. Even if we are just “assemblers” we still have to know how all of the parts interact and where things can break. We are craftsmen (or craftswomen) of software and taking a look at other professionals in other industries really magnify how poorly a lot of software projects are crafted out there. You can see some references to this in a fantastic book called Release it! Design and Deploy Production-Ready Software. Being an assembler isn’t bad, just be the BEST assembler you can be.

What’s old is new again

Interesting enough, with the rise of mobile devices it has kind of zapped us back into the 80’s – 90’s and mobile devices have a lot smaller constraints then servers do. Web developers are forced to write mobile compatible websites which introduce smaller constraints and uncover a lot of the bad habits and¬†inefficiencies¬†we have been used to on the server. We now also have to deal with the issue of app fragmentation unlike the¬†privilege of¬† deploying web applications. Having the mindset of programming on purpose is absolutely necessary when developing on mobile and hopefully it becomes obvious to anyone transitioning to this medium. If not, they’ll learn eventually by failing. Hopefully they’ll be failing fast.

If you’re looking to transition from web languages to something like Objective-C, I recommend reading¬†thinking low level, writing high level.



Don't forget about unit tests

With the popularity of Objective-C it has brought over a lot of programmers with experience in other platforms, especially web developers (like me!). ¬†Lately there has been a rise of many testing frameworks written by the same group of folks who test using other methodologies then what was previously available in Objective-C. This is great for the language and community as iOS development is still a little bit of the wild west. It’s also really neat to see an old language get shaken up a bit. I want to point out a few things that easily get overlooked when seeing all of these new testing frameworks.

There is always a learning curve.

A popular excuse for not having tests is its too difficult to setup and get working or you didn’t have the time.¬†Getting tests setup quickly into your project is probably the biggest hump to get over if you’re not used to doing it.¬†Unless you’re using Cocoapods, getting the new testing frameworks to compile could be quite a task.¬†Xcode makes it quick to include unit tests in every new project. It even generates a template for the first test. In addition, you’re learning the new syntax and API of the new testing framework. With unit testing, unless you get to heavy mocking, you have less to wrap your head around because you’re testing the code you’ve already written.

You could be adding risk to your project.

I’ve been burned by 3rd party test frameworks. When iOS4 was released I had 300 functional tests become worthless when upgrading from the iOS3 SDK. Since a lot of testing frameworks use internal libraries and selectors of UIKit, it’s not uncommon for things to break when Apple releases an update. This is a good example of it still happening in iOS6. You’re at the peril of the 3rd party or the community to release the fixes or you’ll have to spend the time and fix it yourself.¬†DIY can be a pretty crappy option when you’re trying to iterate quickly and ship.

You also run the risk of EOL or lack of interest from the community since something “better” came along. Don’t be nieve and believe this could never happen if the framework was open source.

Unit tests still provide the most value.

If you take a look at any of the software testing pyramids, unit testing should be the largest chunk of your tests. They are the first line of defense. I’ve talked with some “new school” Objective-C programmers and they say that OCUnit is kind of “meh” and they’ve just moved on to behavior tests without having any unit tests of any kind. This is also risky because behavior tests may not be able to find the same bugs as unit tests would. Unit tests shouldn’t be ignored like this as it’s the foundation of having bug free software.

So the next time you’re looking a newly released testing framework or you’re looking to add another layer of tests in your Objective-C project – don’t forget about the unit tests.