Friday, September 19, 2014

Writing a Software Development Agreement

Now that the word has gotten out that I am contracting, I have had interest from friends and associates in doing "small" apps (iOS and web) for them. That's cool but I know very little about running a business and writing software for others is a business.

Currently I am contracting through a large contracting firm and so I have not had to deal with writing contracts or the business side of contracting. With the number of enquires I have fielded, I figured it was time I drafted a Software Development Agreement template that I can use for projects I consider taking on myself.

Being a developer for many years, I know that Software Development is hard. What do I mean? I mean that turning an idea into a finished product is hard. Delivering something that matches the original concept is hard, but we can make it easier. We make it easier by capturing requirements, agreeing on a process for change requests, and iterating on the design with frequent check-ins with the client to verify we are on track with the vision (the Agile way).

That said, business is business and I need something in writing that a client and I can use as our guide for how to deal with delivery, changes, intellectual property rights, compensation, and the other details we as developers seldom think of.

So, I did a few searches and here are some links I used as a guide.
I took what I liked from each and dropped some stuff I was not in favour of. I am not truly happy with this format yet, I would like to write something a little more free flowing but this is a good start.

Take a look at my Software Development Agreement and see what you think. Also, remember, if you have been reading along here, I am not a lawyer, nor do I play one in real life or on TV. So, talk to a real lawyer if you want real contract advice.

Anything I should drop?

Anything you think is missing?

-- Mark

Wednesday, August 27, 2014

I Have to Hire an SDET (Software Development Engineer Test) for iOS, What Should I Ask?

One, of many, of our beach rock finds.
This was the question I got a few weeks back when an acquaintance from Xcoders messaged me to say he had to interview an SDET, for their iOS product, later that day. He did not know what to ask and what areas he should ask them to dive into. Did I have any suggestions?

So, over Twitter I gave a couple quick ideas on what to ask.  Here is that list, expanded a little.
  • What frameworks have they used to test iOS?
    • Compare the differences between those frameworks.
    • Go review this answer on stack overflow about iOS Testing. This will give you a rundown of the testing frameworks and tools for iOS.
    • What are the pros of those frameworks? What are the cons? And the next question...
  • Have they done UI Automation testing? How? What were the results of that testing?
  • How do they manage their tests? It should be better than I don't. Tools used to track the tests to know what coverage you have is essential.
  • How do they report on them? Not much good doing tests without being able to report on the results.
  • What are the different granularities of tests and how have they used them in past positions? Which do they find the most useful for iOS?
    • Unit Tests
    • Functional Tests
    • End To End Tests
    • UI Automation Tests
    • Manual/Adhoc Testing
  • What difficulties have they had testing iOS?
    • Or maybe the more blunt; What have they found to be unsuccessful or not of value when testing iOS?
    • Ask this since it might highlight the one area you want to concentrate on they might hate.
  • I have seen testers write great and sometimes not so great bug reports. 
    • How do they log a bug? 
    • What information is important? 
    • They should have an opinion on what to include.
  • Most iOS apps use a web service back end of some kind. How do they test the results of web service calls?
    • They should be saying Charles (or alternative packet sniffer like WireShark) here and using a proxy to sniff the HTTP packet flow.
  • Whiteboard time
    • Give them a simple method (Objective-C based please), just the definition and what the method is supposed to return.
      • For example, something that takes a string and returns a sorted array that includes each unique word found in the string. I just has to be complex enough to cause them to write several examples.
    • Ask them to write testcases for this method.
    • Do they know the syntax of Test::Unit style or RSpec style?
  • Can they program? If not, then you don't want them as an SDET. The whiteboard coding question should be a breeze for them.
  • Do they know scripting languages? Ruby? Python? Javascript? 
    • They should since the tools built on top of Apple's iOS testing frameworks are normally written in a scripting language.
    • They will also need to integrate tests with build systems which means command line knowledge and the ability to script command line jobs.
That was the short list I came up with with some additions once I expanded on the brief Twitter exchange.

Anything else you'd look for or ask?

Monday, August 25, 2014

Is Contracting For You?

I have not answered that myself and as such I am asking myself that question. I certainly like the fact I am working on new things and getting to branch out into areas I might not normally get a chance to work with. That said, there are some downsides as well.

At first you are going to see that hourly rate and say, wow that is a lot per hour. Hold on there though. Most likely that rate does not include paid holidays or vacation time. So you need to take your salary/year based on 40 hour work week (if your contract is 40hr/week) and then minus the vacation time you'd like to have and the holidays you won't get paid for. Check up front to find out if you can work holidays. If you can't, each of those days off is 8 hours of pay you are missing.

That adds up to make your hourly rate start to not look so good.

The other thing to consider about your rate and contracting is are you going to go with a firm (I have) which makes finding contracts easy but eats into your rate. Meaning, that the contracting company is taking a cut of the rate per hour you are being paid. Now, you don't see that taken out of your pay cheque, but needless to say, if you want to do the harder path and run the business side of things then you can make more contracting on your own.

Also, do you want to gain ownership of something and make decisions about the design and direction of the product? Then contracting, unless it is an architectural position, may not be your thing. So far I have seen that contractors in general are paid to get stuff built. That is great if you don't want to have ownership and just like doing new things each day. Not so cool if you like to have a say in the product and help design what you ship.

I am still out on this one. There is certainly an advantage to just being a grunt, getting stuff done. It is amazing to see the amount of code/progress you can make each week just implementing and not planning. That said, it's nice to have some more skin in the game with the design of a product.

Some other things to keep in mind is that you (most likely) will not get matching contributions for retirement or other benefits. That is fine if you are getting paid a high enough rate. If not, then you are missing another chunk of cash.

Contracting has the allure of new projects, less maintenance of products, and the ability to make more hourly. The truth is that the new projects and less maintenance of long term code comes at the price of ownership in the product. The high hourly rate hides the visible benefits of full time positions that you might not consider.

So, like many things in life, it all comes downs to tradeoffs. Which ones are you willing to make and what do you want out of your job.

Saturday, August 9, 2014

Do What You Love

Riding Bauline, Newfoundland, 1999
I love a lot of things. My wife, my kids, my music, and my many passions. One of those has been with me as long as I can remember.

That is biking. I still remember one of my first bikes. It was a yellow bike that was branded the Mark II. Pretty sweet and I am sure my parents felt they hit the jackpot when they came across that bike. Boy I loved that hard plastic wheeled bike. Not even inflated tires. It was a tank and had traction about as good as you'd think for hard plasticly (very hard rubber) tires.

Of the many forms of biking, Mountain biking holds a big place in my heart, for things I love.

It's something that sits unloved sometimes. Gathering dust in the garage, tires deflating, oil drying out, forgetting the thrill of the trail.

Then a call or text comes, "Want to go biking?" Hell yes I do!

I get out the gear, I prep the bike, and I go.

The other night I went for a ride.

It was great to get on the trail and hurtle downhill at speeds my Mom would disapprove of and my kids would watch in disbelieve.

Nothing quite beats the sensation of throwing that bike around underneath you as your legs and arms pump it over roots, rocks, around ruts, and then throw the bike (and you) into a turn.

As we speed down a section of trail with beautifully hard packed corners, I saw a rise coming in the middle of the S as the turn I was dipped into, leaning over to the right, was going to transition into a fast left hand turn before switching back to the right. Stupidity came over me and I said, I bet I can jump that rise right into that left turn and swoop through this set of curves.

I write this like I had time to think this out. There was no time, my brain thought it, and I pulled up. The bike and I flew into the air.

Was this a good idea I started to think. But before I could finish the thought, the bike and my body knew what to do. Lean back to the left like I was entering that turn on the ground instead of in the air like I was.

Thump! The tires hit. My legs and arms bent. And my ass and rear wheel threw my bike and I into the turn and we both flew through it beautifully.

We had done something stupid again and both made it through.

Mountain biking is freeing. It frees the mind and the spirit.

Mountain biking is exhilarating. Am I going to fast? Will I make this turn? Phew! Did it.

Mountain biking is pounding. It makes the blood flow and the muscles ache as you drive to go faster and climb the hill back up.

Mountain biking rejuvenates my youth as I slip back into my gear and get to pretend to be a Scout Trooper on his speeder bike, whizzing through the forests of Endor.

What do you love?

Go do it.

Remember why you love it.

Tuesday, August 5, 2014

The Illusion of Expertise

Replacing a section of my front
step. Definitely not my area
of expertise.
How much time does it take to become an expert with a new thing?

Let's pick a language.

I mentored a Junior Engineer on a work term who did some Perl development for our project. He then applied to work with us full-time when he graduated. Hey, I must have done something right to have him want to come back.

When reviewing his resume he had listed Expert Perl Knowledge or some such phrase. He wrote 2 scripts for us based off of scripts I had written. I asked him in the interview if he had done more with Perl after we introduced him to it. Nope.

Expert level knowledge? Sheesh!

As a professional developer I get asked to solved problems I have no idea how to solve every day. It's par for the job.

This is no different than many jobs I am sure. I know I have asked building contractors to build or fix something that they've never built or fixed before. So as a professional your expertise comes from being able to tackle these problems without fear. I am paying them for their past experience and ability to successfully deliver; same goes for being a software developer.

What do I mean by without fear?

I have worked with people that say they can't do something since it is outside the realm of their experience? They are asked to add some new functionality to an existing app or script and they say they can't, they don't know that language. I think this is the wrong attitude.

As an Expert, you are expected to step up and say, "Sure, I don't know that language but the program is already written and it just needs some small changes. I can take that on and learn a bit about the language it is written in at the same time. Thanks."

That's how I like to approach tasks outside my realm of Expertise. With contracting, this has become something I have to say more often. Does it slow me down to learn a new language? Sure, I don't know it off the top of my head but with the wealth of information on the web and help within IDEs, there is no reason not to jump in and try out a new language.

If you think you need to be trained in a language or domain to work in it, then you are missing out on being more useful to your team. Being willing to jump in and work in any language is a plus for you in your career that will make you more valuable as an employee.

Don't fear your lack of expertise. Dive in and take on challenges. You grow more from them than staying in your comfortable shell.

Saturday, August 2, 2014

Building Web Services Quickly

Haven't We Been Here Before?
Seattle from the harbour.

The last time I built a web service was back in 2009. I figured out Google App Engine (GAE), it was great since it used Python (my pet language at the time) and with free hosting at the level I was going to use it, that was the platform for me.

I built Hockey Tweet with GAE and then designed Tweety10, a Cocoaheads Ottawa app, which a team of 6 built in 3 weeks in 2010 for the 2010 Olympics to use GAE as well. I ramped up one of the guys on GAE and he built out our web service while I worked on whatever needed my help.

What's This Web Service For?

I have a team that is interested in hiring me, possibly on contract, for their app. They would like a portfolio to see what I have done; which is hard to show when you work for large companies. So I am building a demo app, that will have a web service backend. As such I need to build a web service to simulate some of the features they mentioned. So I am cooking up a web service to simulate the backend service they want to build. I figure this is a good portfolio piece.

You see, I have worked for many teams/companies but those have been larger teams that had many people building the end-to-end solution. For this, I need to show I can build the app end-to-end. They are looking for their own on-site web services programmer but I need something to build my app against for the demo.

I also want some experience with technologies/framework/APIs I have not used yet. There are a lot of frameworks and APIs available to use in modern mobile apps and as such it is hard to find time to learn stuff you don't need for your day to day job. So, I want to try out some stuff I would need for this project, if the team decide to go with me, and also that will help me improve my portfolio to show that I can build an app from scratch with various technologies to meet a clients needs.

Tonight I laid out the storyboards for the app based on the initial use cases the team told me about. The storyboards let me get an idea of what data I will need to support the app. With that in mind I can also think about what the API calls should be. I see the storyboards as a visual walkthrough of the user stories, a kind of overview of the apps back-end.

Deciding on the Web Service Framework

I did some research an evening or two ago on various web frameworks so I could figure out what to mockup the backend web service in. I decided on sinatra, which is built on ruby. It is an alternative to Ruby on Rails and instead of following a Model-View-Controller design it is geared towards quickly developing a web application. So in other words, throw good design to the wind and hack up that web service fast. Perfect.

With Sinatra, you get the basics, but there are some additional features I want which were easy to add. I have added the following gems:
  • gem install sinatra
    • Basic sinatra framework
  • gem install sinatra-authentication
    • Adds authentication framework for your apps. I want to simulate adding users, login, logout, and then mapping users to resources (i.e. events for a user)
  • gem install sinatra-jsonp
    • To add json data payloads.
  • gem install shotgun
With that I have a basic web service running that I can talk to.

Next I will start to build up the API and write tests to hit the web service. I will then start to fill in the app by populating the UI with the data I am pushing from the web service.

I could skip the web service and do this with dummy data in the app but I want some current experience building a web service and so I am approaching the demo app this way.

Monday, July 28, 2014

Today's Challenge: Move

I took a couple weeks off from running. Studying for an interview, a trip, my wife on a business trip (solo Dad with 2 kids), and working on my house meant I had to cut something. So I cut running.

Thankfully, the house has been a good physical activity that has included a bit of movement to keep me happy. You see, I am happy when I am physical.

For me, running, swimming, biking, and everything else I do is not just to stay in shape, it's to stay happy. Read any number of studies and think about our past. Humans were meant to move.

So this morning I got in a run and I feel awesome. The thing is, before the run, and last night I knew I would go for a run today but I did not want to. I am sure you probably don't want to either.

Here was my thinking yesterday:

  • I am too sore from house work (painting, caulking, scraping paint).
  • I have put on weight not working out the past 3 weeks.
  • My sneakers are probably too old and I will be sore.
  • I'll probably get blisters.
  • Blah Blah Blah

I woke up at 6:15 AM this morning and felt great. Surprising since last night I went to bed about 10 after taking some Advil since I was aching all over. I was painting the house this weekend and spent a solid two days working on the house. It is coming along great but I did not expect to wake up feeling good.

So, I ignored my few aches and pains. I stuffed my fat ass into a pair of running shorts. I laced up those old sneakers. And I pounded the pavement.

As I ran I felt free. I felt alive. I felt good.

Ya, it was not my best run, my fastest, or my cleanest. But I did it.

As I thought about this I realized we are just meant to move. This movement can come in many forms. For example, if you are like me you don't wake up thinking, how can I squeeze in some time to paint the house today? But these days I think that. Is it just the fact that house is going to look good? Maybe a bit but a lot of it is climbing up and down that ladder. It is movement.

When I bought our current house I had many people tell me it was a mistake. They said, "You should have gotten a new house so you don't need to do any work on it for 5-10 years."

You know what those people were telling me? You need to find more ways to not move.

Screw that.

I think you should buy that house that needs a coat of paint. It needs some work done. Don't know how to do it? Great, learn. I sure as sunshine don't know how to do a lot of what I do. I just figure it out.

The best part of figuring it out and doing it is you get so many intangible benefits. You get exercise. You get a sense of accomplishment. And you get to know you just paid yourself first since you never paid some contractor to do a job you won't be happy with since it took longer than you expected and cost more than you wanted to pay.

So, for me. I say, find more ways to move. Find more ways to learn. Find more ways to work with your hands. Even though you think that it will suck, you'll thank yourself in the end for having done it.

Your challenge today? Move.