≡ Menu

A History of Failure: Learning From My Failed Products

Right now you’re reading the blog of someone who has had no major success building a profitable SaaS solution. Writing customized software for clients as a consultant? I have that down (though always looking to grow). But building a profitable SaaS product: not yet. So why should you take my advice about building one? I have a really great track record of failures that I hope can help you when you’re building your next product.

Building a failure of a product is no fun, but each one serves as a great learning experience. Each one of my failures have influenced the next product I built. I’m building my three new products differently now that I have several failures under my belt.

Lastly, I don’t want to promote the idea that having a failed product is necessary to be a competent entrepreneur. Unquestionably I’m envious of people who have successful products on their first try. However, I’m always suspicious of those success stories; sometimes a success story is better sold when the list of previous failures is left to lie silent.

Kwolla

The first product I sold online was named Kwolla. Kwolla was the result of a failed startup I was hired to build. Kwolla was originally named Prospect Vista and was a social network for businesses. You could think of it as a merge between YouTube and LinkedIn because a public profile that advertised your business was the value proposition. There are many reasons why Prospect Vista failed, but we decided that the software behind it was still valid, so we packaged it up as a social-network-in-a-box tool. For $79 you could buy a copy of the software, install it on your server, and instantly have your own social network.

Selling Kwolla actually went very well. In total I sold $2400 worth of software and Kwolla consulting combined.

Kwolla failed because I essentially shut it down. I made two big mistakes. First, I had this notion that I no longer wanted to write PHP anymore, and thus was going to rewrite Kwolla in Scala. Next, I actually started rewriting Kwolla (in PHP albeit)! This was insane. In my hands I had a product that was making money and I shut it down because I didn’t like the codebase behind it. The code was sloppy in places and it bothered me. So I completely killed it.

It was a horrible decision. I wish I would have kept on building the Kwolla site and product. Over time I could have refactored the code and made it better. But, my the engineer side of my brain kicked in and I couldn’t deal with the bad code.

Key Takeaway: Don’t rewrite major software applications from scratch, and keep on with a good thing.

Accthub Version 1

After I shut down Kwolla, I went to work for an e-commerce company for a while. I concentrated on building my consulting business on the side in that time, and didn’t really work on any projects for myself. While at the company, I had an idea to build a centralized user management API so that our many different e-commerce sites could communicate with this central user management API. I was itching to build a product again, so building this central user API seemed natural.

I wrote out a spec and eventually built the API: Accthub. A hub for all of your accounts. Neil, my co-founder at Bright March, designed a beautiful landing page and we built a great marketing site around Accthub.

We launched to absolutely zero users. We attempted to market it as a Parse for user accounts (even though Parse had user accounts). In total, 76 people signed up for the service and not a single person paid for it.

Ironically, even though this idea failed for us, two other companies are building it: Stormpath and UserApp. It’s clearly something people wanted, I just hope they have more success than we did building their applications.

Key Takeaway: Do market research before you spend a tremendous amount of time and effort building a product. Launching it to no one doesn’t help at all. Even worse, I originally wrote Accthub in Java and then completely scratched it and rewrote it in PHP because I knew it better and was more comfortable with it.

Accthub Version 2

It’s funny how the key takeaway in the first iteration of Accthub didn’t hit us until after we attempted to re-build Accthub again. The second version of Accthub aimed to be like Mozilla Persona, except not free, not from a major highly respected non-profit company. Essentially, you, the Internet user would register an account on Accthub and then use it to sign up for other sites that integrated with Accthub. Then, you could give explicit permissions as to what every site could do with your data that you let them use.

This idea sounds really cool, but there are a lot of problems with it. Who is going to pay for it? Internet users won’t, they’ll clearly give their private information away for free without any thought. Companies won’t pay for it, they can just use Facebook, Twitter, or LinkedIn authentication.

We applied to Y-Combinator with this idea and didn’t even get an interview.

Key Takeaway: Really validate your idea before you build it. With Accthub Version 1 we got some traction. Fortunately with this version, getting rejected from Y-Combinator was enough for us to scrap it before we built it in earnest.

MajorApi

MajorApi was the first product we built that showed a lot of promise. With the strain of failures behind us, we knew we wanted to approach MajorApi differently.

MajorApi was born from the idea that integrating with QuickBooks is really, really difficult. Way more difficult than integrating with any database (essentially what QuickBooks is) should be. We were working on integrating with QuickBooks for a client and spent a huge amount of time just figuring out how to connect to QuickBooks and send in and extract data. Judging by the the thousands of StackOverflow and random forum posts out there, we surmised a lot of other developers were having this issue as well.

So we came up with an idea: a REST API for QuickBooks. We finally cracked the “integrating with QuickBooks” code, and felt that if there was a service that charged a monthly fee to provide a nice API on top of the horror that is integrating with QuickBooks that developers would come rushing in to use it.

To validate this idea, we set up a simple landing page. It explained the problem, our idea, and our proposed solution. I submitted a link to it to Hacker News on a Saturday night in early December 2012. That night, the post blew up. We had several hundred people sign up for the mailing list saying they were interested in what we were building.

Even more encouraging, Intuit themselves caught wind of the landing page and flew me out to Mountain View to spend a day with them. They offered me a very nice job in exchange for not building MajorApi. Stripe was also interested in integrating MajorApi with their service. So, when Intuit offers you a job to not build something, and Stripe wants to integrate your product with theirs, and you have hundreds of people interested in using it, it’s definitely time to build your product.

I declined the job at Intuit and built MajorApi. And three months later in March of 2013, we launched it. And people started using it – kind of. And then really not at all when you really looked at the analytics. Mailing list people signed up, saw they had to download a piece of software, and it only worked for QuickBooks Desktop and that was it: they were gone.

We also applied to Y-Combinator with this idea which we felt surely would get us an interview only to wind up completely rejected again.

MajorApi limped on for the last year. We finally shut it down in January 2014 and are in the process of open sourcing it.

Key Takeaway: We built a product that people were interested in, but we built it in a silo. We didn’t reach out to any members on the mailing list while we were building it to find out what they really wanted or were willing to pay for. Instead, we kept our heads down and built a product we thought people would have wanted. I would have much preferred to launch to 20 developers immediately ready to start paying $50 a month for this service than 200 people who created a free account.

Final Thoughts

Building a successful product is hard. Very hard. I’m not ashamed at all about my failures. Even the most successful products out there were most likely built by people with a long history of small failures that they learned and grew from.

It’s always best to put another tally mark in the Successful column, but don’t be ashamed of the ones in the Failed column either.

0 comments

Worth the Click: January 2014

2014 is going to be the year my business becomes huge. To do that, I have to start thinking a lot more like a marketer than a programmer. I’ll always love programming and software development, and I’ll always ensure it’s part of my profession, but to really accomplish my goals I need to grow. January’s “Worth the Click” is focused more on marketing than programming. Here are some posts I read recently that really helped me out.

  • Idea to Customers in Three Days – Few posts got me as excited this month as Brennan’s “How I Went From An Idea To Paying Customers In 3 Days” did. This excellent article details how he went from a WordPress plugin idea to paying customers (at $197 a pop) in three days time. It contains tons of actionable advice, and really got me excited for building my products. I’ll be duplicating his actions in this post for a product idea I have and documenting it all the way.
  • How Do You Create a Product People Want – Building a product people want is hard – really hard. But you can save yourself a lot of headache and trouble if you follow Amy’s advice in this article. I know I’ve done steps 1 through 6 with several of my own products many times.
  • Do You Cold Call – This link is not an article but rather a Hacker News discussion on cold calling. It done properly, it can be quite effective. The discussion is great because you get feedback from people who do a lot of cold calling and people who get cold called a lot. Tons of great advice in this discussion.
  • Guide to Surviving Self Employment Software Development – This article has some great advice on how to get through self employment. Marc’s advice on overbooking is valuable: it’s a nice position to be in, but it can actually sink your business quickly. Each tip in this article has a nice Lesson Learned summary at the end if you’re in a rush.
  • Cold Emailing – Does cold calling intimidate you too much? Try a cold email instead to get your feet wet. This article from Noah Kagan shows exactly how a cold email should read.
0 comments

We Open Sourced Our Failed Startup

MajorApi was our first legitimate attempt at building an actual startup. We thought we did everything right (for some definition of the right way to build a startup), but it still didn’t take off.

We put a lot of work into MajorApi and we’re very proud of it. Rather than just let it linger on an external hard drive in a Time Machine backup, we decided to open source it.

The code is MIT licensed and is comprised of two repositories: the main website and QuickBooks REST API, and the background data processing workers. Personally, I’m really proud of the code. It’s well tested and solves a relatively complex problem. It also demonstrates a great way to build a REST API in Symfony using one of our bundles. The main website was also beautifully designed.

While we’re not actively working on the project now, we are doing custom QuickBooks integrations. If you need to integrate with QuickBooks, get in touch with Bright March.

0 comments

Sales Tips I Learned as a Personal Trainer

Like a lot of programmers, I used to view marketing and sales as something that was scummy and below me. It amounted to essentially tricking people into giving you their money and they didn’t get much in return. It wasn’t until I became a salesman that my view on sales and marketing completely changed.

When I was in college in 2003 I became very interested in fitness and bodybuilding. To say it became my life would be an understatement as I spent many more hours at the gym than I did in a textbook or classroom. So, it was natural that I eventually got a job at a gym: why pay $40 a month when I could work there and use the equipment for free?

I got hired at the now-bankrupt Bally Total Fitness to manage the front desk. I was paid $8 an hour to scan cards, take payments, and direct people to salespeople or personal trainers. I absolutely loved that job. It was simple, and during a lot of slow times, I could work on classwork or personal projects. Eventually the gym changed directions and I was given a choice: either lose my job or become a personal trainer. I obviously wanted to stay employed, so I opted to become a personal trainer. This wasn’t an easy choice, since being a personal trainer essentially means that you’re a salesperson that also trains people. Sales ended up being about 70% of my job, with training being 30%. In the end, however, I enjoyed the sales much more than I did the training.

Within one month of being a personal trainer, I was the #1 trainer in the Dallas/Ft. Worth market selling around $12,000 a month in personal training.

Don’t Sell Anything

The biggest lesson I learned was to not try to sell anything at all. People hate being sold things, but people love buying things. Bally taught trainers and salespeople to be as high pressure as possible. Intimidate people into buying a membership, or offer ridiculous incentives that they can’t live up to. Coincidentally, Bally is now bankrupt, so those tactics don’t work long term. Instead, I made sure hiring a trainer was a choice the person wanted before they committed to a $2700 personal training package.

Instead of viewing the sales process as a process, I saw it as an interview. I was interviewing a potential client to ensure we fit well together and they were committed to changing themselves. This meant I had to give away a lot of free time and expertise, but ultimately this tactic succeeded.

Finally, I didn’t want to pressure anyone into an expensive package because I was going to be the person training them. Did I really want to train someone who started off disgruntled at me because they felt they got ripped off?

Show Your Investment

Sales comes down to many things, and one of the largest is trust. Can the person trust you enough with their money that they are going to get a return in some way on it? You gain their trust by showing your investment in what they are buying. For a personal trainer, this means being in good shape. Listening to their goals and tailoring a fitness plan for them. This shows you’re invested in them, and in return they’ll invest in you.

I showed my investment to my clients by keeping meticulous notes about each of their workouts. When I was interviewing a client, I would produce a little notebook that was filled with exercises and goals. I would explain that this was the exact notebook I used to track my goals and progress (it was) they would get their own notebook that I would use to track their activity. That way they could see their progress as well as hold me accountable for their goals.

Don’t Rely on Typical Sales Channels

The typical personal trainer sales channel was this: a person just registered for the gym, and now they get one free session. A trainer is chosen to give them the free session, and then the trainer tries to upsell them on more training. You can imagine how unsuccessful this was. Talk about having the person feel as if they are being ripped off. First they sit through a high pressure membership sales pitch, hesitantly agree to it, and then have to sit through a high pressure training package. I never got the conversion rate on that practice, but I couldn’t imagine it was very high.

Instead, I found much better ways to bring in clients. Every Bally gym had several dumb computer terminals that connected to a central server that did all of the processing, reporting, and data storage. One of the features of this system was that you could run reports on members. Before they locked it down, I would create an ad-hoc report that would show me all people in the area that had expired personal training sessions. I would call these people up, say if they came in I would give them half of their sessions for free, and if they liked my training style, would they consider hiring me as a trainer? This worked amazingly well. You can imagine how much easier it is to sell someone training when they have already purchased it before. My conversion rate was a cool 50% (I called 10 people, 5 became paying clients).

A typical sales channel for your SaaS product is you create an ad through AdWords, wait for a few visitors, maybe one fills out a registration form, and you might make a sale. While this is perfectly valid and scales well, it’s certainly no way to get your product growing.

A much better sales channel is to build an audience. One person doing this very well, and the person who taught me this strategy, is Brennan Dunn. I became aware of his products several years ago and have been following him ever since. I registered for his newsletter, listened to his thoughts, and got tremendous value for free, so when he started The Freelancer’s Guild, the $50/month fee was trivial to pay.

It’s so much easier to get someone to buy something from you when they already trust you because you’ve given them tremendous value for free. As a personal trainer, this meant I might give someone two or three free sessions to ensure they really are dedicated to training. But if giving away $80-$120 of my time meant I sold a $2700 training package, well, the math is trivial.

5 comments

The Dynamics of the MVP Have Changed

Every developer I know has an idea that is going to make them very wealthy. Most don’t act on the idea, and most ideas don’t make them any money, but they all have them. The key, of course, is action on that idea.

The initial action on that idea is called your MVP, or Minimum Viable Product. It is the minimum product you can build that you feel can gain some traction, or viability. Unfortunately, determining what that product looks like is very difficult and ever changing. It also requires you to have knowledge about your expected customer, and to fit your product for that customer.

In the early days of web application development, an MVP was a fairly polished product. It contained many features, usually took months to build, and looked solid (under the hood it probably wasn’t). Today, that delta from idea to the first code commit to the first production deployment can take as little as a few hours. This is still a reality I have trouble grasping as I struggle with overcoming perfection. Literally every single product I have released didn’t feel polished enough and I always have spent way too long worrying about features that no one ever uses or needs.

An exercise I do to get around this mental block is to ask myself these two questions:

  1. Will this MVP validate my idea quickly and accurately?
  2. Will this MVP allow me to on-board my initial customers?

If you can’t answer “yes” for both of those, then it’s probably best to move on to your next idea.

After you have determined that your idea is worth pursuing, it’s probably best to determine exactly what your MVP needs to do. In other words, how much pain am I willing to experience before automating this process? By answering this question, you will discover what pieces of your MVP can be automated, and what can be manual.

For example, Groupon started as a simple spreadsheet and WordPress blog and then grew from there as manually tracking coupons became too painful. With Forwarder, I knew that it needed some semblance of automation because I could not manually route calls myself. With MajorIntel, we’re working with customers one-on-one to build beautiful QuickBooks reports for them every week.

Coding and hacking and building things is a lot of fun. What is not a lot of fun is building something that no one uses. It’s a good use of your time to ask yourself a few questions before you run off and start building your MVP.

0 comments

Symfony Hosting

I host this blog on a service called WP Engine. It is excellent and I highly recommend it. One of the biggest hangups I had with WordPress is that I didn’t want to host it myself. Even a cheap $5 Digital Ocean VM was more of a headache than I wanted. WP Engine (and others) came along and solved that problem beautifully.

More and more Open Source projects are moving in that direction: a company forms around the project itself that offers hosting and white glove service. It’s a great business model as it helps to fund the core software while providing a way for people to make a living.

Most of the software we write for our clients is done in PHP using a framework named Symfony. Symfony is quite complex, but very powerful. With the exception of a company named ServerGrove, I have not seen any dedicated Symfony hosting providers.

I’m interested in building a hosting service specifically for Symfony applications, and even more specifically, large scale Symfony applications. We would provide a lot of white glove services including:

  • Help with no-downtime deployments.
  • Symfony configuration management.
  • Scalability options and help.
  • Database optimization.
  • Symfony and server security.

All applications would be hosted on actual hardware that we would manage and be responsible for.

Is there a need for a service like this? If you write and deploy Symfony applications, how do you do it now? I would love your feedback. Either leave it in a comment or email me.

0 comments

Worth the Click: December 2013

December came and went very quickly. A lot of that had to do with the holiday season; I just didn’t feel as productive as I could have been. Regardless, 2013 was an amazing year: the year I finally struck out on my own. I hope 2014 will be even more amazing. Here are some links that are worth the click.

  • Cold Calling – This guest post on the Smart Bear blog details how to start cold calling potential customers. Cold calling is very difficult, and people are right to be weary of it. However, Robert gives some great scripts on ways to talk to people. It’s all about what you can offer them.
  • REST APIs With MartiniMartini is a popular web framework for Go. This tutorial walks you throw how to build an API with it.
  • Five Tips to Running SaaS – Thomas Fuchs of Scriptaculous and Zepto fame wrote about five things he has learned in the five years of running a SaaS company. Number five is particularly important to me.
  • Failures From Entrepreneurs – This post from Buffer resonated with me. While I haven’t wasted $1,000,000 on a business or taken outside funding, I have spent a lot of money on failed ideas, said “yes” way too often, and built things no one wanted. Chances are, you’ve experience many of these as well.
  • Know Your HTTP – Helpful printable PDF’s on HTTP.
  • Startup Lessons Learned From a Failed Startup – Great article detailing how hard it can be to build a product online, and how easy it is for them to fail. I’ve done this several times, and will talk about it in an upcoming post.
0 comments

The Problem With Framework Benchmarks

I’m a huge fan of the recent benchmarks Tech Empower have been doing against a wide array of web frameworks. It really is shocking how fast some of them are.

However, benchmarks like these fail to take a very important piece of software development into the equation: the holistic development experience.

Measuring speed is relatively easy. Measuring how easy it is to develop using a specific framework, the tools and libraries available, the community, the professional learning tools, ease of deployment, ease of updates, and how frequently the core framework is updated is much more difficult to measure.

For example, in Round 8 of the comparison, Go comes out on top for JSON serialization. This naturally makes sense, as Go is a new fast compiled language meant for speed. Symfony comes in dead last. But any programmer would tell you to use Symfony just to output 28 bytes of JSON is silly. Raw PHP is quite fast, and beats out a lot of other frameworks and languages.

Also, because Go is newer, it doesn’t have the ecosystem that Symfony and PHP or Rails and Ruby or Django and Python have. These languages and frameworks might not execute as quickly, but the libraries, development and debugging tools, and communities available will help you develop and maintain software much faster and easier.

As with most software development, there are tradeoffs. Can your web application suffer an additional 10ms of processing time because you’re using a slower framework if your developers can be a lot more productive? That’s your call to make.

Now, I’m off to go investigate Vert.x and Netty.

2 comments

Small Software Consultancy Issue Tracking Is Broken

My fulltime job right now is growing a small software consultancy named Bright March. As a consultancy, we build software for other companies. This software is often long lived, and like all software has bugs and new feature requests. Furthermore, we use our talents to build products we think are useful and that can provide income in their own right. And finally, because we are a software company we want to use a piece of software to manage our workload and workflow.

Unfortunately, because of these unique situations, there hasn’t been a single piece of software that solves our problems. I think other consultancies have these issues as well, and if they don’t, I’m interested in hearing what they use to track everything (which I’ll call issues).

Soft Issues

  • Consulting with my accountant for payroll tax information.
  • Writing a new quote for a potential job.
  • A reminder to follow up with that potential client regarding that quote.
  • Weekly hours worked to bill existing clients.
  • Write a blog post.
  • Send out a few cold emails about our services / general marketing.
  • Find out how the Affordable Healthcare Act is going to influence our existing insurance from our broker.

Hard Issues

  • Client A has three new features to implement, they pay hourly. Each feature is an issue.
  • Client B has a whole new project to implement, it is comprised of 40 features, and this is billed as a lump sum.
  • Client C has three bugs they need fixed in their application. Two are paid fixes, one is not.
  • Need to upgrade all production servers to Redis 2.8.0 to normalize our stack. Non-paid.
  • Need to get offsite backups implemented on all production servers. Non-paid.
  • Build marketing website for new book. Non-paid.
  • Features 1, 2, and 3 for Forwarder. Non-paid.
  • Picto is growing and needs some new features as well. Non-paid.
  • Redesign Bright March website and logo. Non-paid.

And so on. I’m classifying soft issues as those that are related to the company itself: accounting, contracts, insurance, benefits, and payroll. As a two person business, these issues have to get done by one of us, so I need a way to track it. Hard issues are those that require actual development or IT or whatever your expertise is time. Some of these are public, some are private (our clients don’t care about upgrading to Redis 2.8.0 but I do because I want our server environments to be normalized), and some are for completely internal projects that operate like normal software issue tracking does.

This is a fairly unique workflow that is generally only experienced by small software consultancies. Any client service company sufficiently large enough has entire divisions devoted to handling these tasks. Companies that make installable consumer or commercial software or Saas applications can track issues as they relate to the software itself because hourly work is not as necessary to track. There are many issue tracking packages out there that handle this wonderfully.

I have tried a lot of software to solve my issues, and each came up short (and usually by no fault of their own, they simply aren’t the right tool for the job).

  • GitHub Issues: Entirely too basic.
  • Sifter: Amazing for tracking issues for a piece of software; not the right tool for tracking everything else.
  • Things: Great for personal task tracking, doesn’t scale at all.
  • AgileZen: Again, great for Kanban and issue tracking for a piece of software, not for growing a small software consultancy.
  • Freshbooks Task Tracking: Very confusing to setup and use, seemed entirely wrong for my use cases.
  • Mantis: I really don’t want to have to host and hack this to make it work.
  • Basecamp: Works well for project management, but not software issue tracking.
  • Flow: Beautifully designed, works well for project management, but not software issue tracking.

Currently we are forcing Jira into working for us, but it does not feel very fluent at all. Jira is an amazing piece of software, and if you’re building just a piece of software for mass consumption, I highly recommend it. But it is not very well suited for the use cases I’ve outlined here. It also gets expensive very quickly.

Is there a need for a new piece of issue tracking SaaS product? Here’s the features an initial MVP would have were I to build it:

  • Set basic configuration for your company. Each of these can be changed per project or issue.
    • Default hourly rate.
    • Default bill frequency (weekly, monthly, project completion).
    • Default issue visibility.
  • Manage clients
  • Manage issues for clients.
    • Issues can be categorized into projects.
    • Issues can have an hourly or flat price associated with them.
    • Issues can be marked as public or private.
    • Issues can be assigned to a person from within your own company.
    • Time can be tracked against issues.
  • Manage issues for your company.
    • Issues are private.
    • Issues are non-paid.
    • Issues are uncategorized.
  • Reporting
    • Money owed to you (which could then be imported into an invoicing system, I’m not interested in building one, there are many).
    • Completed issues.
    • Past due issues.
    • Issues without assignments.
  • Dashboards
    • Clients can see a dashboard of public projects and issues.

Billing for this would also be extremely simple. $X per user per month with no restrictions on number of clients, projects, issues, or data stored. Users are people working for your company, clients would not require accounts to see their dashboard.

I want to hear from you. Do you own a small software consultancy? What do you use to track all of this? Am I missing something? Is this something you would be interested in beta testing? Email me or leave a comment below and let me know.

0 comments

Overcoming Perfection

Any software engineer worth their salt should care deeply about their craft. They should care about what tools they use, what technologies they learn, and what communities they support. Thus, it should come as no surprise that software developers are often perfectionists. And I’m certainly one of them. The hours I have toiled away at the most mundane minutiae would span several months when placed back to back.

When building a company, you often can’t spend the time on that minutiae: you’ll run out of money or time and go out of business. I’ve started to learn that first hand as I’m trying to grow Bright March. I can point to several distinct times when we have lost money on a project because I insisted it be perfect rather than “good enough”. Naturally, our clients love this, but unfortunately it will kill a business in the long run.

Companies started by developers are more susceptible to this problem than companies started by MBAs. Developers insist on their product being flawless before they release it, whereas the MBA is primarily concerned with the bottom line. Extremely successful companies are often a good mix of both. Jeff Bezos is an engineer at heart who obviously cares a great deal about proper software engineering but also cares deeply about building a successful business.

With Forwarder, I wanted to try a new tactic. I wanted to force myself to be uncomfortable with the initial product but to get it out there regardless. I want to share a few ways that helped me overcome my perfectionist tendencies and still get out an initial product that I’m proud of.

Writing Tests

The best piece of advice I can give engineers to feel more comfortable about their imperfect software is to write tests for it. When I say I study my code extensively, I mean it. I have spent hours deciding if I should wrap a long line to two lines or not. It can get bad. You know an immediate remedy to that? A green line showing all tests passed and a solid code coverage report. In my mind, I immediately forget about that long line and can move forward to the next feature or bug fix. You should not forsake good engineering practices just because you are trying to get your product out there quickly. You immediately revert back into perfectionism mode when you do forsake good engineering practices like testing.

Writing Idiomatic Code

Whatever your language or framework of choice is, learn its idioms and use them frequently. By doing this, you will feel like your code fits better in whatever framework or language you’re using. It also helps you avoid pointless arguments with yourself about line length or tabs vs. spaces. When I switched to Symfony, I completely changed tab styles (tabs to spaces), variable naming (snake_case to camelCase), and indent style (BSD KNF to K&R). It was tough because I was so used to seeing my code in one way, but I told myself that if I wanted to make the switch to Symfony successful, I would have to follow its idioms. It has helped tremendously. Ironically, Symfony doesn’t have an opinion on line length.

Using a CSS Framework

By using a CSS framework (ZURB Foundation is my favorite) I was able to create a nicely designed product without much difficulty at all. Having a nice design immediately makes me feel better about any questionable code I have hidden behind it. If you lack absolutely any design skills, head on over to Theme Forest and pick up a theme for two for $15-$20. I physically feel better when I have a nice design backing up my product.

Keep Your Features Small

By keeping your features small, you are able to accomplish them quickly. Checking off things on a to-do list has a positive psychological effect on our brains, so you will feel better about your finished features as you move to check off another one. With Forwarder, each feature was a new branch and they usually were no more than five commits. Make a list of your basic features, cross off the ones you don’t need (and there will be some), and then break the remaining ones out into even smaller tasks. Then get to work.

Deploy to Production Frequently

Deploying to production with each new feature has the same cognitive benefits as completing that feature in development. It puts a final seal on that feature. It’s out there, and users can experiment with it. Deploying to production frequently also means that you should have a good deployment strategy. Don’t have time to set one up? Use the one featured in my book Expert PHP Deployments to save yourself several days of work.

Stop With the Comparisons

Without a doubt, one of the largest forces that keep me in my perfectionism ways is by comparing myself to other successful applications. These don’t even have to be competitors: I find that when I compare myself to other applications, I immediately want to work on mine more to make it perfect. For example, I’m inspired by the success of Buffer, the social media sharing application. They have exactly what I dream of: a small product that does one thing well and makes money. What I don’t think about when I make that initial comparison is that they’ve been doing it since 2011. I have to frequently tell myself “just because you just discovered something exciting doesn’t mean they started yesterday.” Wait to make the comparisons later after your application is successful, in the meantime, just focus on getting it out there.

Overcoming perfection is a process without a clearly defined destination. To throw another wrench into the equation, sometimes your work does need to be perfect (for some definable amount of perfection). I trust as a professional developer you know when perfection is necessary and when it isn’t, and that in times it isn’t, my advice can help you.

1 comment