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.  🙂