Don’t Confuse Self-Worth With Entrepreneurial Success

I dedicated 15 years to becoming a professional recording artist. My favorite musical time was spent with Doug, Eugene, & JP in the band called Moneypenny (1995-2000). We were predominantly a live band. We regularly played live gigs across Ireland and had huge amounts of fun doing so. We also played national TV and radio a number of times. We released an album and a few singles.

How we looked back in the day:

That was 10 years ago.

I haven’t been able to talk about music since then (until recently).

During that entire musical phase I placed so much of my self-worth on “musical success” that not achieving it was a huge blow.

It’s an important lesson for all want-to-be entrepreneurs.

When we undertake entrepreneurial endeavors we are told to put everything into it.

But how much is too much?

At what point do we draw the line and understand that our own self-worth will never be fulfilled by building a successful business, or by becoming an internet rock star?

I get the feeling this is the central theme of “The Social Network”.

No matter how much success Zuckerberg was able to achieve, no matter how rich he was able to become, he could never get the acceptance he craved from his peers. Finally, he understood this when he became the richest most famous graduate of his college class – yet the one girl he craved to accept him wouldn’t even return his Facebook friend request.

Put a Picture Of You On Your Blog

It’s only a small detail. But it can make a big difference.

On a side note.

A friend of mine saw the above picture and said “It’s a weird angle. Too much chin. Too much cheek.”

I politely explained.

“It’s not the angle. It’s too much chin and too much cheek!” 😉

It’s not an iPad app, it’s an EVERYTHING app

When I released my iPad app Swarm I didn’t know what to expect. I was very lucky because it instantly hit the front page of the app store in the games category. It stayed on the front page for 2-3 weeks.The below chart is an accurate trend chart showing exactly how Swarm sales have been doing for the past four months since launch.

It doesn’t take an Einstein to see what happened here. When the app is no longer on the front page sales are a non-event.

At first I thought:

How can I tell the world about Swarm and keep up my sales in the app store? I know, I can drum-up PR on the web. Then people will learn about Swarm and purchase it in the app store!

But… doesn’t that sound like a leaky bucket?

Think of all the people who will be reading about Swarm NOT using an iPad. In fact MOST people will be on a desktop, others on mobile, some will even be on Google TV or any number of other devices.

Hmm.

I shouldn’t be thinking in terms of iPad app, or iPhone app, or even mobile app. I should be thinking in terms of an EVERYTHING app.

No matter what device someone is using when they hear about Swarm , they should instantly and always be able to download and purchase it there and then. That’s the only possible way to capture 100% value from marketing & PR efforts.

CSS3 and .png’s Are Pretty Sweet

I recently created an iPad game using CSS3 and .png’s. The results are pretty nice. All the chrome is CSS3 (i.e boxes, curved corners and gradients). All the playing pieces are .png’s with glows and semi transparency. There are 8 sprites in total which are dynamically copied, and placed by jQuery when the game loads. These are screen shots form the iPad.

Why You Need a 360 Degree Resume

Little did I know – when I built this site – what I was really building was a 360 degree resume. I’d never heard the term before. Because it didn’t exist (until a few minutes ago). It was just coined by a friend of mine during a phone conversation. We were discussing the site that you’re looking at now.

Here’s what he said:

“Your site is very different from a traditional two dimensional resume. It’s a bit like walking around you and looking at you from different angles.

You have control over what you’re showing to people… but to them it feels like you’re standing there and they are able to inspect different aspects of your online persona at will.

It’s much more of a warts-and-all experience, which makes sense given today’s all access social media expectations. People don’t expect things to be hyped, polished and packaged in the same way as days of old.

The beauty of it is it enables you to pull in many different aspects of your working-self to create an overall picture of who you are.

For example a prospective employer can listen to your podcasts or view your tweet stream to get a sense of how you interact with people and what kind of ideas you have.

It’s very powerful and very compelling and it’s apparent that it’s genuine.

It’s sort of like a 360 degree resume.

Nice site.

I like it.”

Let The Blog Race Begin

For those of you who listen to the TechZing podcast, you’ll know that my co-host Jason has the idea that it will be faster (and easier) for him to build his blog from scratch in HTML rather than install WordPress. He talks about it here (35min. in) and here (23min. 35 sec. in).

Um. Ok.

I call that a Jasonism. So anyway – I set THIS blog up in about an hour and showed it to him. He liked it. He suggested we have a blog race. To see who can get the most blog views within a month. Ok. So starting Monday 11th Oct 2010 we’ll both be posting one blog a day for 30 days.

So let the blog race begin!

On Monday.

If he has a blog.

Update:

Aha! Here’s Jason’s newly built blog 😉

If you always re-invent the wheel… you should probably quit

If you’re hoping to become a CTO… and you never use other peoples libraries, frameworks, and platforms

You should probably quit 😉

—–

(In response to If you haven’t re-invented a wheel… you should probably quit)

If you haven't re-invented a wheel… you should probably quit

If you’re hoping to become a CTO… and you’ve only ever used other peoples libraries, frameworks, and platforms

YOU’VE FAILED

Here’s why. If you’re making decisions for an entire company:

– You shouldn’t get to choose a framework unless you’ve built a framework
– You shouldn’t recommend a library unless you’ve built a library
– You shouldn’t make high level decisions unless you’ve made low level decisions

If you think it’s a bad idea to re-invented the wheel…

Just quit!

Code the right way… and your start-up will probably fail

If you’re in a start-up and you’re spending a lot of time coding – “the right way” –  the way of cargo cults and W3C standards…

I’ll wager that your start-up will run out of money and that it will probably fail.

Why It's a Bad Idea to Warranty Custom Code (Bugs vs Mistakes)

A few months ago I had an interesting discussion with a client about “Bugs vs Mistakes”. During the discussion my client  said  that he didn’t like the idea that he was first paying a developer to ‘make a mistake’ and then second paying the developer to ‘fix the mistake’.

He didn’t mind so much about ‘Bugs’. ‘Mistakes’ were the issue.

My Client’s Classification of a Bug:

On one page we had a search box, but rather than use std HTML we wanted to make it look nice by adding a background graphic with CSS. If you typed more than 30 characters the text overshot the end of the background image that would be considered a bug (an oversight).

My Client’s Classification of a Mistake:

The site had a section where you could store credit card information and a section where you could store bank information. A mistake would be if the drop down in the bank account section had the text “Credit Card” when it should  read “Bank Account” (a copy paste error).

During the discussion he made the interesting assertion that software developers ‘mistakes’ should be warranted and fixed free of charge. That’s an interesting concept and worthy of discussion. In this article I hope to show that neither the customer, nor developer can benefit from a “Warranted Code” code agreement when developing 100% hand coded custom software.

ALL Bugs Are Mistakes

It’s difficult for a non programmer to appreciate just how many mistakes it’s possible to make when coding. It’s even difficult for a new programmer to appreciate it. It’s only after you’ve been coding for a few years that you can truly grasp the magnitude of what can go wrong.

It’s not the same as, say, the number of mistakes you might make when writing an essay. After all once you have finished the essay it stays the same and the words don’t change…

But dynmic code is a different story. Each line consists of variables that rely on other variables that rely on functions that are chained together. One logic chain may have a depth of hundreds of library functions that rely on other library functions and so on. An infinite number of mistakes and bugs just waiting to happen.

If a developer were to try to think of ALL the possible things that could go wrong during their daily coding sessions – their output would probably slow down by a huge order of magnitude.

It’s not unusual for custom projects to have more than 10,000 lines of custom code, all interacting with each other. There’s an old saying “Only one company in the world makes bug free code. It’s NASA. It costs them a $1000 a line”. I bet that most startup’s would not be willing to pay $10m for creating 10,000 lines of custom code 😉

So, as a result, coders have no choice but to choose a comparatively small amount of tests to check any new code is “good enough” before handing it off.

The typical tests a web developer performs after building web functionality might be:

  • Does a record get inserted in the database when I click the “Save” button?
  • Does the error popup if I don’t enter a value? Correct error message?
  • Is the inserted record correctly associated with the logged in user?
  • etc.

In other words the developer is testing the ‘meat and potatoes’ of the application logic. As you can imagine when the developer has their head stuck in this level of ‘logic complexity’ it’s vey easy for them to miss something aesthetic such as… does the drop-down say ‘Credit Card’ or ‘Bank Account’.

Yet, from the clients perspective it seems astounding that the developer could pay so little attention to the front end and miss the obvious mistake staring them in the face – however from the developers perspective the front end is only the very tip of the iceberg.

For example, a web page on the front end might consist of two drop-downs and a button – but the backend interactions can involve thousands of lines of code with infinite error possibilities – and it is these that a good developer must focus on. After all, the wrong text on the front end is a 2 second fix, but badly tested code on the backend can bring the entire site down.

Don’t Eat Your Own Dogfood

In the world of software development it is widely acknowledged that coders should NEVER test their own output. This is for good reason. A dog can’t smell its own breath. It’s impossible for a developer to guess how other people might interact with the product they’ve made. There are other good reasons discussed here. If a developer was to FULLY test their own work it would decrease their output dramatically.

I know this because after the discussion with my client I tested the theory. I painstakingly tested all my new code to the Nth degree before releasing it. I was slowed down by about 80% due to the massive amount of permutations I needed to test for (rather than the core tests). My output became very low and my cost to ship each functional unit went up by a factor of 5. I also became bored and un-inspired with the work.

In my opinion, the very idea of warranted code is bad for the customer. It would force ANY sensible developer to test way more permutations than actually required – ‘on the clock’ – during billed time.

Yes the customer may end up with “better code” but at a huge price increase in cost and productivity.

A better idea is for the programmer to output work at their usual rate with a sensible amount of tests (i.e. database tests etc.) – but not test every possible outcome. Then as the project gets closer to launch, and bugs are picked up, they are can be cycled back to the developer who polishes them at that point.

With this method you only pay for “bugs that really matter” – vs – paying for “all possible code permutations” that a developer might think of.

You could go a step further and say that the appropriate time to get picky about how the software works and what it looks like is in the Q&A cycle (just before launch). Large software companies have an entire Q&A team that does nothing other than test software and report bugs to developers. Smaller software houses may not have dedicated teams, instead they usually have a dedicated Q&A cycle, in which everyone on the team focuses on testing the software and then cycles back bugs for developers to fix (once again, just before launch).

Development Cycle

A good testing/development cycle might look like:

  1. Brainstorm features
  2. Wireframe front-end
  3. Developers code new custom features
  4. Business owners check new custom features (loop back to step 3 as needed)
  5. Final Q&A
  6. Developers fix issues (loop back to 5 as needed)
  7. Launch
  8. Fix bugs that customers find

It’s important to note that at stage 4 we are not looking for 100% perfection. We should be looking for minimum viable product acceptable to the business owners. Then Q&A stage 5 will throw up plenty of finer detail bugs missed at stage 4 (and rightly so).

You will also note that at step 8 even more bugs are found by customers. This is why entrepreneurs should take a chill pill when it comes to perfectionist tendencies. In 20 years of software development I’ve never seen software that was bug free.

Conclusion

By using Q&A teams and Q&A cycles correctly entrepreneurs empower their developers to output code as quickly as possible without having to get bogged down in the minutiae of testing all the possible permutations as they go along. Even though it may be painful to see an imperfect product emerge, this is most likely a cheaper and faster way to develop software.

The likely alternative is to slow down developers by 80% and grind productivity to a near stand-still. It also risks stifling developers creative output, which can kill the spark and make a developers job less satisfying. Which in turn might give the developer itchy feet.

Update

There are some exceptions to this rule. For example if your software house has created a framework that you use as a cookie cutter system for all of your clients and you only create iphone apps  – then I can imagine you could warranty your work without too much of an issue (because presumably you would have tested your cookie cutter framework to the Nth degree).

The above article is targeted at developers creating one off custom code for a new start-up or business.

If you found this article interesting check out the weekly tech podcast I co-host (TechZing) which you can subscribe to on itunes by clicking this link or listen to here. You can also follow me on twitter @justinvincent


« Older posts
Newer posts »