11 Jan 2016
As the new year kicks off in full swing, I am reflecting on my 2015 goals and setting some new ones for 2016.
Here is how I did on each of last year’s goals:
- Create a business plan - Fail. I did not create a business plan for Pixegon. This might have to carry over.
- Grow Pixegon (my mobile consultancy) to 2x 2014 revenue - Success. We not only achieved this goal, but surpassed it. Pixegon did a total of $1.1mm in revenue in 2015!
- Hire a “director” - Success. OK, so this one is sort of in the middle. I didn't quite hire a director per se, however I did elevate my senior employees to more management roles. This allows them to take some of the day to day tasks off of my plate.
- Move to a weekly - Fail. But I'm OK with it. This isn't very important.
- Morning Routine - Moderate. Some days were better than others
- Blog twice a month - Huge Fail. I averaged .41 times per month.
- Take off / reduce workload - Success. More camping!
- Give away more than 10% of personal income - Success. Our family was blessed with multiple opportunities throughout the year to be a blessing to others in addition to our normal donations.
Overall, I’d call 2015 a success. I managed to hit the goals I felt most passionate about, and more importantly, this exercise has helped me to determine what I should focus on. With that being said here are my goals for 2016.
- Land ONE new client. Sounds crazy I know, but allow me to explain. Pixegon has been fortunate enough to work with some pretty incredible clients. Many of these clients trust us to be their primary dev team throughout the year. I intend on finding at least ONE more client like these in 2016 (Referrals welcome ;) ).
- Build Something New. As I continue to build a company, it's often hard to get back to my roots of writing code and actually creating something. I miss this. It provided so much value to me over the course of the years. So, this year, I want build some "side projects".
- Hire. I hope to grow the team by at least 20% this year. (We are always hiring most positions).
- Be more intentional about EVERYTHING. I have really been into a few blogs lately (Mr Money Mustache, The Minimalists, 4-Hour Workweek, etc...). What I have really learned is that I want to be more intentional about everything I do (Family, Time, Money, etc...). Part of this is removing my dependency on my phone, simplifying my life, and scheduling undivided time for the things that are important.
- Stop Complaining. I read this incredible book called A Complaint Free World . He talks about the power of Not complaining. This has really resonated with me.
- Blog Twice Per Month. OK This time I mean it (1 down, 23 to go! )
- Read 5 books. Arbitrary amount I know, but I need something measurable.
That’s it. Here’s to a healthy and productive 2016!
Feel free to link me to your 2016 goals blog posts in the comments.
28 Jul 2015
It’s late, you have been hacking all night to get the client a build. Finally, around 2:30 am, you hit submit and publish something to the client and go to bed. When you wake up in the morning, the first thing you see in your inbox is an email titled “Completely Broken!!1!”.
How could this be? You stayed up late, you hacked, you tested and you sweat over this build to find that it crashes for the client when they try to do something obvious.
As developers, we often can’t see the forrest through the trees. What this means is, we get so deep into the code working on a new feature or fixes that we often don’t notice when we break things. This doesn’t mean that we are bad developers, it just means we think differently about development. It also means we can’t personally handle everything.
However, from a client’s perspective, failures like this can really tarnish your brand. They start to get the impression that you are unprofessional and even worse, start to doubt your abilities as a developer.
QA (short for quality assurance) is an idea that someone other than the developer tests the build before the client ever sees it. These people are responsible for
- Regression testing (as in the scenario above)
- Generating a test plan/matrix
- Ensuring parity (if needed) between multi-platform applications
If the QA team is doing it’s job, the client won’t every see these obvious failures mentioned above. This can greatly improve the client’s perception of you/your team.
OK, QA sounds great, how do I get started? Well, it’s actually relatively simple. First off, I assume you are doing some flavor of agile, and hopefully logging tickets for each task. If not, you should (even if you are a one man show). Here is a rough flow that my team follows:
- Developers determine which tickets to work on for the current sprint
- Developers complete a ticket and move it to a “dev complete” column in the task manager (Jira, Trello, Pivotal Tracker, etc…)
- Developers deliver a build internally
- The QA team takes the build and goes through their testing matrix to check for regressions.
- If a regression is found, a bug ticket is created for the responsible developer
- New features are added to the QA test matrix and tested
- If the feature has bugs or doesn’t work as intended, the ticket is rejected and pushed back to the developer
- Once everything passes, the build is green-lit to be sent to the client (usually one build per sprint)
Like anything, you may develop your own version of the above, however this should be a detailed enough outline to get you started.
In my experience, clients will generally give you some pushback when you say that you are billing them for QA hours. They will say things like “It’s OK, I can test the build myself.” or “I understand, things won’t be perfect. We will through this together”.
While this all sounds good at the surface, the fact of the matter is, it almost always will end unfavorable. The client might have some level of tolerance early on, but as you start sending them more and more builds, each potentially missing/breaking features, they will become less patient. I have seen this happen plenty of times even with the most tech savvy of clients. Here are a few ways you can build QA into your billing process:
Add it as a line item
This is where you will most likely see the most opposition. Make sure to explain to the client that their time is valuable and you don’t want to waste it. Also, ensure that the cost of QA is drastically less than the cost of engineering or you will get questions like “Why am I paying you full price to test?”.
Be sure to tell the client that QA is just part of your team’s process. You simply don’t operate any other way as you know that this is the best approach for both parties. Hopefully, this will establish your expertise in the domain and the client will respect you for that.
Bake it into the cost of engineering
Often times, you may not bother with too many line items. You may just have something like Engineering $200/hour. When/If the client gives any pushback about cost compared to other shops, simply inform them of all they are getting inside of that hour (Engineering, Consulting, QA, Project management, Office management, etc…). It actually works out to be a much greater value for them than paying say $125/hour for a “code monkey”.
I absolutely believe that QA is crucial to the success of any software agency or freelancer. Not only does it allow you to come across as more professional, it also helps keep you sharp as a developer. While I’m not suggesting QA is a silver bullet (I still believe in Unit / Automated testing), I feel that everyone should at least have some layer baked into their process.
07 Apr 2015
There is a familiar phrase that I hear all too often when a client comes to me with an existing application. It goes something like this:
“Our team spent quite a bit of money on our application and we don’t want to ship it. We are not proud of the product.”
It blows my mind that many developers and development teams are still in business given the poor quality of products that I see getting churned out all of the time.
When I encounter these types of situations, I immediately know that the team (or individual) behind them is much more interested in a ‘quick buck’ instead of the longevity of their company. Poor quality in software is directly related to cutting corners.
A few examples of cut corners:
- Using inexperience developers without proper guidance. I am all for hiring ‘staff’ level developers, however, they must be properly mentored and trained so that there is no compromise on quality. If you must compromise on something, compromise it on time.
- Outsourcing the project without proper guidance. Although I don’t prefer outsourcing given the communication challenges, I am not opposed to it. There are plenty of talented individuals all over the world. However, given the varying degree of abilities and communication issues, one must not rely 100% on an outsourced team to ship a product.
- Not following coding standards/guidelines. This could be things such as: not commenting code, not testing, not leveraging a QA team, or simply writing “smoke an mirror” code.
I can usually identify immediately which of the above applies after spending a few minutes with the code. In fact, I have built much of my business around saving these types of projects.
So I urge you, although it might cut into my market share, *please *build something you are proud of. This is not only the right thing to do, it is also **critical **to your future success as an independant software developer.
27 Jan 2015
During my years of mobile development, I have heard the phrase “I have an idea for an app!” hundreds, if not thousands of times. Sometimes it would be from family members, sometimes my dentist during a cleaning, and sometimes from a naked dude standing in the sauna at the gym. Everyone pitches app ideas to me.
What I have learned from hearing so many pitches is this: apps really fall into one of three (sometimes four) categories. Allow me to elaborate.
1. The app has been done before
This is the most common category of app idea I hear. Usually, these are along the lines of, “It’s like Instagram, but for finger painters…”, etc… where the user takes an already proven idea and tries to tweak it in some way that they feel makes it new. Most of the time, these people have not even done any research to check as to whether or not a solution already exists.
The biggest hurdle in developing an app that has been done before is visibility; How are they going to get people to find the app and why should they choose it over the competition?
2. The app idea is too niche
Every now and again, I will hear a truly unique idea. Keep in mind, unique does not necessarily mean good. For example, I might hear, “I want an app that you can take photo of your cat, put it on a weather balloon, and send the balloon to space. ‘Catz In Spaze!’”. While this is unique, and technically feasible, one would be hard-pressed to make a real business out of it as it would be hard to get enough users on board to make it profitable.
3. There is a reason the app does not already exist
“I want an app to map out all of the grocery stores layouts in the world, so husbands can finally shop efficiently!” This is a great idea. It really is. So great, that I have literally heard it no less than ten times from various people over the years. Often times, I can predict when someone is about to pitch this particular idea, just by the setup: “You know how, like, shopping is hard, and like, you can’t find stuff…”.
There are some real technical hurdles surrounding this problem. While there are a few apps that have tried to solve it, no app will really accomplish the goal unless they have all of the following: total store participation, a large enough group for crowdsourced data, faster and more reliable GPS to know exactly where you are in the store, stores stop changing layouts, etc… You get the idea. There are a lot of reasons a solid solution for this does not exist.
There are other countless examples of app ideas falling into this category. Another fun one I get pitched is a killer app that converts any photo into a (caricature) [http://en.wikipedia.org/wiki/Caricature]. I’m sure someone will link one in the comments, but they are all mediocre at best.
Bonus #4: The app is used to augment their existing business
This is actually my favorite type of app to work with. The user has an existing business and wants to build something that benefits their business in the mobile space. I see ideas from evaluation tools for employees to apps that allow users to order products directly from the business.
I like these because the success of the business does not depend entirely on an app. Also, there is generally an audience built right in at launch time so everyone is happy.
I am not writing this post because I’m jaded and sick of hearing app ideas. Quite the contrary. I love hearing app ideas and would love to hear examples challenging the stereotypes that I have created here.
I give this spiel to clients from time to time and wanted a place that I could point them to, so feel free to send your clients to this post the next time you get the grocery store mapper pitch.
29 Dec 2014
It cannot be overstated that writing down one’s goals is critical to acheiving them. Pair that with sharing them with others who might help keep you accountable and your probabilty of achieving those goals goes way up.
With this in mind, I have decided to share my 2015 goals here on my blog in hopes that I will do a better job of acheiving them in the new year. I tried to focus on more measurable goals rather than things like “eat better” and “exercise more”.
So, here they are in no particular order.
- Create a business plan
- Grow Pixegon (my mobile consultancy) to 2x 2014 revenue
- Hire a “director” to help with oversight of current developers
- Move to a weekly rate instead of hourly
- Be consistent with morning routine
- wake up early, pray, blog, mediate, read Bible, write down MITs,
- Blog twice a month
- Grow the blog’s mailing list
- Take off / reduce workload on Friday’s to spend the day with my family
- Launch Autumn Village
- Give away more than 10% of personal income
This list is definitely not complete, however it’s a good start. I hope to refine it over the coming months and more importantly, stick with it.
What are your 2015 goals? I would love to hear about them in the comments or via email.