Level Up: Test-Driven Development

Until very recently, I’m used to being that hired gun who parachutes in, kills all the work tickets, asks the important questions about the product, makes an app work as desired on a tight deadline to a reasonable level of quality given the constraints, then is out again, all for a reasonably good sum of money. It’s exhausting because these companies often have no established procedures.  So in addition to being Lone Wolf: Kicker of Asses, I’m training junior developers so they can assist me without slowing me down too much, I’m creating an Adhoc QA Department (what is severity, what is reproducibility, how to write bug reports, what is a end-user test suite so you know how to regression test, and why you should use a ticketing system instead of just popping by my desk to effectively pull the plug on whatever 50 things I had in my head), I’m having to interpret incomplete designs, pull the assets out of the Design tools (Zeplin, Sketch, sometimes Photoshop) because many designers don’t know what exactly you need anyway, poke holes and/or fill in the gaps with the UX, and of course manage upwards. Oh yeah, and also do “Agile Waterfall” development, which is borne out of companies who only really do Waterfall but want to be “hip” to the new trends and demand we do Agile (with no scrum master or really anyone who knows how to lead that effectively). So then your time is further taken up with meetings and pushing work tickets around that actually don’t really encapsulate the work you actually need to do, but managers need you to do that so they can generate reports with some data that is meant to impress other people who really have no idea what’s going on anyway, and actually just increased levels of trust in your hires and “we’re good” would be equally effective/ineffective. (Ah, perhaps they don’t know how to make the right hires or can’t get them if they did.) In all of that, I have to “get ‘er done” because the deadline doesn’t change and surprise! All of your dependencies (Design, Backend API) also have the same deadline.

Yikes. A day in the life.  That above would be the worst day in the life.  It’s rarely all of those things.

So I’m grateful for my current freelance contract. It’s the first contract really in years where I felt I’m working in a proper software development company. The management overhead seems low, but the organization is not impacted. They have a process here that works. (I think it’s just because I hit the jackpot and they just placed a priority on the members of the team; personable yet very competent. Ultimately it’s a team who cares about what they do, and making sure there’s a nice team vibe. It also helps that they have corporate backing and therefore have a generous timeframe and budget it would seem.)

“Take the time you need to do a good job.” This is very much the culture here. For one of the first times in my career, I’ve been really exposed  to an office environment where you’re given time to think, and time to write a lot of tests while you develop. You can ask for specifications and those exist and are fixed. There are 2 other iOS devs here to bounce ideas off of, and of course to do code reviews with. It is so extremely satisfying when you get to refactor your original approach into ever more concise code that is more robust and less error prone. Time where you can write the API docs and the Unit Tests to basically freeze the specification. Normally there just isn’t enough time, given all the other tasks that Lone Wolf has, AND the product design always seems to be a moving target.

In short, it feels like I finally have the time and space to level up. Unit Tests are especially awesome when you work in teams and I’m glad for the opportunity to work in this environment for a while so I can establish some good habits and really reach a new plateau in my journey as a software developer.


No, I didn’t die

Looking at this blog, it’s been over a year since I wrote anything. I’ll just list my excuses:

  • I was overworked on some agency projects and there simply wasn’t enough time to write posts
  • It’s generally a grey area to write about problems solved for clients who make me sign an NDA
  • I could have made the solution to the problem look generic, thereby obfuscating my client’s identity and thus my attachment to the project, but didn’t.
  • And now THE main reason….

I spent 8 months of 2018 taking a sabbatical. I like to call it a sabbatical because this is how you don’t lose respect from people when compared to saying “I’m unemployed and am enjoying watching my beard grow”. But really it was more like a “I’m fed up with insane projects that are under-staffed, with poor management and deadlines that don’t change, so ultimately the bottom-feeding developer who is doing the job of a small team on his own is starting to wonder if it’s time to pack it in and open a bakery, or do some other kind of artisanal work that involves repetitive, meditative movements and a certain degree of craftsmanship. <blows sawdust off his handmade hope chest>”

Sabbatical has a nicer ring to it and doesn’t require a backstory.  “Ah, he must be a well-to-do kind of man.”

This sabbatical was not about going to some coding retreat so to level up my skills as a developer. It was more like a sanity check. The reason I like coding and software engineering is that I find it to be a highly creative medium. For me, being creative is what gives life some meaning and makes it fun. The process of having an idea, developing it in your mind, putting it down on paper, refining and iterating on that, solving the unknowns, then finally doing the implementation / building. Then it’s done, you pat yourself on the back, revel in your accomplishments, then say “next!!” I love it. So the sanity check was a) to get a little distance from a profession that was starting to become not fun for me anymore, and b) do something completely different but also creative.

So I did that. In 2018, I decided I wanted to build a camper out of some kind of vehicle, then drive around North America until I experienced some sort of epiphany. I gave myself a year. I used 8 months. I built a camper. I had an adventure. I drove 24,000km in 4.5 months and saw so many beautiful places and met tons of very lovely people. I had some profound realizations about my life that were restorative and empowering for me going forward.

In short it was the most useful year I’ve had in over a decade. If you have the opportunity to take a long period of time off and leave your normal surroundings behind, I highly recommend it.  You’ll return knowing what changes you need to make in life.

True, I have fallen a bit behind with the latest and greatest in iOS / Swift dev, but since I’ve been back working (since November 2018), I’ve been fortunate to work with great developers and I’ve actually leveled up in this short time. I can say I’ve become way more of a test-driven developer, and I’ve also got a few new tricks up my sleeve that you generally get to learn when you work with other developers that work on your platform; not something I’m all that used to as I tend to be either the only iOS dev on a project, or they quickly say “oh but you know the most”.

At any rate, I’m back and I’m still happy to be a developer, and now that my approaches have changed somewhat, I have new areas to grow. So I’m not stagnating like I felt I was, and I’ve been fortunate to get a few freelance contracts that have not turned about to be a complete and total clusterf*ck, which has often been the case in Berlin, Germany. I oftentimes have the feeling that when it comes to Software Development practices, Berlin is the wild west; there are no rules, OR Berlin is teenage love; just fumble around in the dark for a while and hope something good happens.

On the Separation of QA from Development

I don’t know maybe it’s just me, but it’s very important for me to be able to be “in the zone” when I’m programming.  If I’m in the zone, I feel superhuman and am able to accomplish the work of 2 or more people at once.  Being in the zone, in computer techie parlance, is like having a large store of volatile RAM completely loaded with all the information you’re working on trying to solve the problem.  Any time someone turns up to distract you, it’s like they’ve just pulled the plug on your computer.  Now you have to boot back up, load all the data, re-orient yourself with the task, then continue working.  Until the next distraction.

I notice I get extremely hostile when this continues to happen on any given day.  I request home office time a lot, not because I don’t like my co-workers or my work environment, quite the opposite actually, it’s just that I love being in the zone and know that it’s also good for me to be there from a business perspective.

We’re now going through a small QA cycle and so of course there will be bug reports.  What I’ve come to realise is that it’s important to keep testers away from developers.  Because testers will find a bug and feel that they need to tell you about it right away.  But, as mentioned before, they pull the plug each time they do so, then of course probably don’t understand why I slowly want to rip their head off.  “Dude, what’s your problem?”….

Well, here is my problem.  I just explained it.  Use Trello.  Put it on a card list.  Let me get to it asynchronously.  It’s better for everyone that way.  If I need clarification, I will come find you.  Not in any elitist sense, but purely business – my time is worth more than yours.   It’s best to prioritise my efficiency over yours.

Writing Structured Code

As you have perhaps read in my last blog post, I once worked on a project where when I started its very old codebase was more or less one giant mess.  It got me thinking heavily about structured code and how I’d love to just refactor all of that but sadly can’t.  What I can do however is offer up some advice based on my own experiences as to how one might go about doing their job in an organized manner, so that the things you deliver will also be.

First, every project needs an Architect.  Imagine what would happen if your immigrant paid-under-the-table construction workers were tasked with the job of designing the house as they build it.  Not the best plan.  Everything you want to do, software design-wise, deserves a discussion with the project’s architect, as this person is most likely the most experienced person with conceptual design, and through discussing it you can show him how you think and approach problems (good for future work, as he will remember this bright young mind!), and most importantly, you will be keeping him in the loop.

That said, YOU might be the architect, and forget experience, you’ve got a job to get done.  Let’s go then.

I am assuming it’s an iOS project, which is very much going to be for the mostpart a Model-View-Controller paradigm. Here’s generally how to ensure you can adhere to this pattern:

Make a Click-Dummy

You should be able to navigate the interface without requiring any data initially (or at least you can use mock data), so that you are properly ensuring that View objects remain dumb (that is, the Controller tells them how they should appear, and the View tells the controller what has just happened to it, say when the user interacts with it.)  A view should rarely, if ever, retain a pointer to a data model.  If so, this ‘smells bad’ and you should probably be doing something differently.

Ensure View-to-Model Separation

If you couple a view to a model, this view can never be reused in any other project, ever again.  This is why you should keep your views as dumb as possible.  They should inform someone (a controller) about anything that happens to it, if they need to populate themselves with content (like a table view, for example), it should be delegating this job away to someone else (like a controller!  who asks the model!)  A view is vapid and vain; it only cares about itself and how it looks, and if anything happens to it that might disrupt his appearance, he goes and cries to someone else about it and gets them to figure out what to do.

Encapsulation, Encapsulation, Encapsulation!

It can’t be stressed enough how important it is to encapsulate the functionality of your objects as much as possible.  Always write code considering that someone else may use your code later.  The public header is your way of saying “these are all the things you should need to know about, the rest is not required knowledge for you to make this thing do it’s job”  Matt Gemmell put it best in his famous article (which you should read as well!):

APIs are UX for developers… your API is part of the first impression that a developer will have with your code, and will have a huge impact on whether they use it or throw it away.

Of course, with any craft, practice makes perfect, and one doesn’t simply learn this stuff overnight.  The important thing is that you strive for excellence, don’t just be happy with “It works! On to the next feature…”

// Comment.Your.Code.

Time after time I’ve heard the lazy excuse of “well, I shouldn’t need comments because the code speaks for itself”.  Well then, young padawan, your code is saying “help me, I’m retarded”  or at a very minimum “I’m culturally very different than you.”  Which in any case leads to misunderstanding and confusion.  Especially when you haven’t adhered to design patterns, comments are most essential for another programmer to make sense of the mess that’s been made.  It never hurts to give a person some indication of what was going through your head at the time.  That person could also be you, reading your own code months later once your skills have progressed and you find yourself wondering “What idiot would write such a thing…. written by… oh.  Erm, carry on, nothing to see here…”

I hope this might be of some help to you, which of course will then be of some help to whatever person you end up working with in the future.  I had another article I like to call “Stephen’s Manifesto” on writing clean code, but it’s a bit long, lots of images, and a bit outdated.  It’s meant for relative rookies.  I’ll summarize as follows:

  • Avoid “Cowboy Programming”: Don’t “code first, ask questions later”.
  • Write headers first.  It gives you an overview of what you want to accomplish
  • Write method stubs, filled in with comments that explain in plain english what your algorithm is.
  • Organize your implementation files with pragma marks

Happy Coding!

To Nib Or Not To Nib

(UPDATE) There are some good arguments on the Internet about this, whether using NIB files is good, or whether you should just skip it and do it all in code.  Ultimately there are times where either would be appropriate, but personally I am a fan of Interface Builder.  If it were really a cumbrance, why would it exist?  Why would they have taken it further to create Storyboards?  That said, there are times where maybe it’s not the tool for the job.  (I will add my rebuttal to one of these posts in a future post).

The key reason I would say in an article called “Writing Structured Code’ is that Interface Builder (IB) is actually an excellent way of ensuring a coder works to the Model-View-Controller paradigm.  Because when you are coding up your view controller’s view in IB, the NIB file has an owner; in most cases the View Controller.  So, right there you are forcing your views to inform the controller of anything happening to them, and the controller (via IBOutlets) is able to set properties on the views.  Without that, you see coders writing controller code in their views, views are referring to objects, and all sorts of other wacky behaviour that just wouldn’t be easily possible if the person had to set up a view in IB and then set all sorts of other pointers in viewDidLoad.

Having ‘grown up’ with Interface Builder, I think it inherently trained me to adhere to a MVC pattern and I feel I’m better off having done so.  Whether I need IB now, no, not really, but as it’s been mentioned in one of the above 2 posts, one writes less (boring) code.

The Importance of Design Patterns

I suppose this post is aimed at the recent graduate of computer science, or to the programmer who is at a stage of his career where “Look!  It works!” is a validator for whether they know how to program or not.  (And further down in the article towards a CTO who has to give business arguments for why certain things need to be done)

I’m a freelancer and have been for almost 2 years.  What this means is that, for a fee, I am parachuted into unknown territory and am asked to complete task X in amount of time Y.   This is straightforward and enjoyable for prototypes or new tasks, but now that I have some time to reflect on the past, like pulling teeth when you are dropped into a project with a pretty old codebase written by mostly recent graduates and students.

Basically what happens when programmers do not adhere to the paradigms of design patterns (I’m an iOS developer, so I am mostly in this case employing the Model-View-Controller pattern), basically any object ends up with a pointer to any other object, and when you hope to implement a feature by extending the functionality of one specific component, it slowly dawns on you as you are stepping through code to try to understand how it works that basically the app is one big component called AppDelegate and everything else is a member variable.   In programmer parlance, it’s Spaghetti code.  And not just the ‘i just pulled this out of the strainer’ spaghetti, no, this is the ‘i just went back into the kitchen 3 hours later to see if there’s any spaghetti left’ spaghetti, and when you pull on one noodle, the entire blob which has now taken on the form of the pot it was in, is lifted out with it.

This post is about the importance of design patterns.  Yes, we all hear of these things.  But then we are implementing, and don’t know how to get this object talking to that object whilst following the pattern, so we hot-wire a solution where objects A and B, who should otherwise not have any knowledge of each other to do their job, now contain pointers to one another.  This is called coupling.  Now repeat this idea for almost every object in your code, and you not only have the most tightly coupled mess, you now have code that:

* has a very very steep learning curve for new programmers on the project

* is very difficult to extend and add new features because it’s impossible to work on one component in isolation

* is NO fun to work on (affecting quality of life and thus how much they will charge in the future)

* next to impossible to test / debug in any timely manner

What does this all mean?  Cost.  At the end of the day, we are all being paid to produce something, and all of these things result in longer amount of times required to get anything done.  So, you hire a freelancer to implement a simple feature?  First you have to pay him handsomely to learn and understand a codebase that doesn’t follow any pattern, so on his side, no assumptions can be made about how it works.  He has to discover everything new.  You’ve just spent 2-3 weeks on one person who still hasn’t accomplished much.  Now that freelancer understands how it works, but wants to extend a component.  Now the implementation could also end up being messy because it’s trying to consider all of the existing mess and tries to prevent that from getting worse, if possible.  This also takes longer.  The entire time it actually kind of sucks for such a programmer because it’s just painful at every turn.  This programmer will no doubt demand more money next time because the job was not fun.  You just want to implement something simple, but it’s a constant 2 steps forward, one step back, maybe even two steps back.  Actually it’s more like “maybe I can take a step here?  No.  Try somewhere else”  And testing…. ?  Well, that’s just something we won’t get into here.  We just assume that if the code is as it has been, unit tests were never in place to begin with.

Good, structured code, that adheres to principles of software design is ESSENTIAL to any project that is more than a prototype.  What business leaders need to understand is that development takes TIME.  “Yes, it takes one week for that little spinny wheel to do its thing so that later an image is displayed.  But NEXT time we need to do that, our costs are like 1/5 of what they would be because we built something GOOD.”  You get the drift.

Stay tuned for a post about how to approach writing structured code that’s easy to work with.

Chipmunk Physics Library

Of course this post isn’t for everyone, but if you ever are in need of a physics engine in your game (or app for that matter), I can’t be more thrilled with the Chipmunk Physics Library, written by Scott Lembcke, over at Howling Moon Software.

It’s a 2D Physics Simulator, which I originally used years ago on BocceBeers, and with this latest upgrade, am using again.  The most important thing I find with 3rd party libraries (beyond doing what they say they can do), is documentation, examples (there are PLENTY), and support.

I have no idea how the author of this lib has the time to develop, market, and support his library, but whenever I post anything to the forums, he’s got it answered within 24 hours.  Every time.  It’s so amazing to not have to get stuck on a problem and wait for the developer to get back to you.   (Ever had a problem with Twitter on iOS… man…)

Anyway, go check it out for yourself.  There are some pretty videos.  🙂