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


Why it's Good To Pay For Freemium Software

Nothing in life is free. Nothing on the web is free.

Sure. It may be free for you… but someone, somewhere, has to pay for it.

If you make the decision to pay for the Freemium software you use it’s “better for you” for the following reasons 🙂

  • The team behind the software is more likely to stay in business and keep the product live
  • You will get preferred support from the team who make the product
  • The team behind the software will feel appreciated and more passionate about improving it
  • You will see more value in the software because you paid for it
  • You will have a bigger voice in the direction and new features of the product
  • Your SMALL payment will make a BIG psychological difference to the team. A happy team makes better software.
  • You will (most likely) feel a sense of good karma about rewarding the team for their good work
  • Your money will be re-invested in better resources thus improving performance
  • If you rely on the software it’s better for you if the company behind it is well funded

There may be other reasons. Please add them to the comments below and I’ll put them in the list. 🙂

How to trump Microsoft, Google, Twitter & Facebook

This is a long post, so to sum up… this post describes the Venture Matrix (working title). A new type of company incubator that itself is a new type of company that anyone can join… company 2.0 if you will. It’s a cross between the Borg, peer-to-peer networking, MMORPG, socialism and capitalism in their purest forms. The main principle behind the idea is to use proven software patterns to manage and delegate work required to create a new efficiency in the market of starting companies. An efficiency that has hither too been impossible.

The Problem

One question that often gets bandied around the interwebs is “Where will the next Google come from?”

In fact, over the past few years I’ve had plenty of discussions with work colleagues about this topic. We always try to fathom what type of core product it might be that ends up turning into a multi-billion dollar world dominating empire.

Centralized Necessities

To be a really big business (and I mean biiiig) you need to dominate a centralized necessity.

For example, we all need phones and phones need to be connected together – without this centralized necessity phones wouldn’t even work. ATT were so successful at dominating this that they became a monopoly and were forced to break into smaller pieces by the government. Likewise, all computers need an operating system. At some point in history Microsoft made some clever maneuvers to ensure that they dominated this centralized necessity.

When the internet came along we all needed to find things – as far as the net’s concerned finding stuff is a centralized necessity. Online there are two patterns to find things 1) by using search & algorithms 2) by manually navigating organized links.

So, it should come as no surprise to see that two of the biggest internet companies dominate the above centralized necessities. Of course I’m talking about Google & Yahoo respectively.

A side note here:  It’s very rare that first movers end up dominating a centralized necessity. It’s usually after the first guys prove that there is something interesting that everyone else piles in and a winner is found. Google didn’t invent search. Microsoft didn’t invent operating systems etc.

What’s The Next Opening that Could Trump Google?

Good question! We have three possibilities here:

  • Undiscovered centralized necessities that already exist (very rare)
  • Existing centralized necessities that are already dominated (nearly impossible to topple)
  • New centralized necessities that are about to exist that we don’t know about yet.

So, the most hopeful possibility is in discovering or creating new centralized necessities. The problem is we have to wait for critical mass to hit before we can see where the next big thing will be.

Twitter is interesting. If the pundits are to be heeded then the centralized necessity here is that everyone wants to connect to each other in a super simple way from any device that is connected to the internet.

The Birth of Companies

This whole centralized necessity thing is something I’ve been pondering for a few years now. I’ve been thinking about all sorts of products and services that could be the new centralized necessity of tomorrow.

At some point along the way, I’m not sure exactly what made me think of it, I had the revelation that the very creation of businesses is a centralized necessity… and, just like anything else it can be improved, refined and perfected.

I wondered if it might be possible to start a company that can dominate in the world of starting companies!

If you look at the patterns and processes required to start new companies there is a huge amount of room for improvement. This is always the case when anything is difficult. Any one who has tried to start a new company will be able to attest just how difficult it is! Here are a few of the things that we need to do when starting a new internet business…

  • Think of a winning business idea (WBI)
  • Create and follow an execution strategy for the WBI
  • Find & manage people to build the WBI
  • Find cash while the WBI is being built
  • Launch, Market & Support the WBI
  • Etc., etc.

Company 2.0

Since I’m a programmer by trade I decided to have at go at refactoring what a company was – at least as a brainstorm – and see where it took me. The first thing I thought about was, could I apply technology patterns and concepts that have proven to work so well in the digital realm to real world companies.

In programming small and decoupled functions are good. Large and coupled functions are bad. Small functions are easy to understand, they can be re-used in lots of different circumstances, they require less work to maintain, they are light and zippy and can turn corners better. Large functions are bulbous and waddle along, holding back the software stopping it from moving forward at anything other than a snails pace.

How can we apply this knowledge to the realm of real world companies? Let’s say we were to re-factor Microsoft. We might consider breaking its huge monolithic nature into lots of smaller autonomous company units. And when I say smaller units, I don’t mean units with 200 people instead of 2000 people. A function with 200 lines of code would be far too long, 6 lines of code is a much better function size. So, let’s break Microsoft into 1000’s of small autonomous company units with 6 people in each.

Companies with six people can move super fast. They can make decisions quickly. Because there are so few people everyone is constantly communicating, no one is left out of the loop. It’s no wonder that all the great tech companies have been started by a small group of people who advance on the competition at amazing speeds even though they are outnumbered by 100/1.

Headless Chickens

Now, you might be thinking that a company the size of Microsoft split up into 1000’s of units with 6 people per company would be utterly useless… after all how could they release a product like Windows that takes 1000’s of programmers to build – especially if there was only six people in each autonomous company unit. It would amass to a lot of headless chickens pulling and pushing in different directions… wouldn’t it?

That’s what I thought too… but then I decided to think of it as a technical problem and see if there was a pattern that could deal with a situation like this. We would need a clever way for a few people (i.e. Bill & Alan) to manage 1000’s of small companies of autonomous six man teams, and to move them forward in a unified direction to create a single product.

Network Patterns

As it turns out, there are excellent and proven patterns  to manage lots of small work units from thousands of different sources and skillfully combine them into a finished product. Bittorrent and TCP/IP to name a few.

Now, when we rethink the possibilities of managing 1000’s of six man teams we can see it would be perfectly possible if there was some kind of peer-to-peer software to help co-ordinate work tasks. It would be a company operating with somewhat of a hive mentality.

The difference between traditional peer-to-peer software and the type of software I’m talking about is, rather than use bit-torrents to manage the dispersal and reconnection of bits and bytes; I’m suggesting we can use the same principals to manage human workflow.

Of course now that we have thousands of decoupled six man teams working as part of a hive mind – all working on tasks that have been split up into bit-torrent style work packets – we need some way of controlling this system in such a way that it makes sense as a real company.

Could such a matrix style model be a REAL company?

Here are the big questions that would need to be solved in order for this to be taken seriously as a company…

  • How do we decide who joins?
  • How do we decide to advance people?
  • How do we decide who runs it?
  • How do we decide what projects to work on?
  • How do we determine who owns what?
  • How do we make money?
  • How could this get started?

Redundant thinking

Before I get into answering the above questions I also wanted to talk about why I think six man pods is the optimal pattern. Once again I’m drawing on software patterns, this time the concept of a neural net. In particular the idea of certain nodes becoming more powerful and also the redundancy that neural a net can offer.

Let’s imagine that our 1000 six man teams are set up in such a way that they are the exact same structure from one team to another. Off the top of my head this structure seems sensible…

  • Chief Executive Officer
  • Chief Technical Officer
  • Chief Operations Officer
  • Chief Design Officer
  • Chief Financial Officer
  • Chief Marketing Officer

Of course, just like in a real startup each person’s functions would vary beyond their job description – for example the CEO may well also be a full time coder – the main point is that in the context of the venture matrix these are the roles they hold.

By making each matrix node (or pod) the same structure it helps us build a super redundant workforce where packets of work can be passed from one pod to another without any down time. Just like TCP/IP packets can seamlessly be passed from one node to another on their journey across the net.

Startup Speed & Agility

Let’s say that we wanted to change a core aspect of the way we built projects across all 1000 teams of 6. For example if we wanted to move from raw php to using a php framework such as codeigniter or symfony. In a traditional company that kind of change would take huge amounts of time to spread across the company. But in the venture matrix we could move almost as quickly as any six man startup.

Incubation Continuity

You may also notice that each node’s structure looks a lot like a conventional company structure with CEO, CTO, etc – that’s there for a reason. The whole point of the venture matrix is to give birth to, and incubate new companies; at some point those companies need to be let go and be released into the real world to act autonomously.

What could be better than having 1000 highly trained teams with the perfect corporate structure (CEO, CTO, etc) already in place? Simply choose the best team for the company in question and launch the company with them at the helm.

How do we decide who joins the matrix?

The matrix could be run somewhat like open source, in that anyone could join and the more that they prove themselves the more likely they are to get a chance of having their code committed.

People can join as individuals and become assigned to a pod after proving themselves, or people can join as a ready made pod and become part of the matrix after proving their worth.

How do we decide to advance people?

Once again borrowing from software patterns, as people prove themselves in the venture matrix they could advance their ranking and ownership via some kind of points system (similar to MMORPG points systems). The same kind of advancement could also be applied to each six man pod.

How do we decide who runs it?

Part of (or maybe the main component) of the points system would be peer rating. As a group, the matrix could pick and choose the leadership by way of voting. There may also be some other criteria such as a pod consisting of six individuals who already have huge amounts of kudos and proven business skills.

For example if a pod applied to join that consisted of Jeff Bezos, Larry Page, Sergey Brin, Bill Gates, Richard Branson & Warren Buffet – it should start off with a certain amount of pre-assigned weight within the system. However, having said that, there should never be a point when one node has absolute power and cannot be de-crowned.

There should be in place some kind of system that ensures the entire structure is in continual flux and that the best team at any given moment is making core decisions.

How do we decide what projects to work on?

Within the main peer-to-peer infrastructure that runs the venture matrix there could be an easy way for people to submit business ideas that can be rated by all members of the matrix.

When an idea hit’s a critical mass of popularity within the venture matrix then it moves to a new phase called the “demo build”. In this phase we hand out piece meal parts of the project in order to get it to move from an idea to a working demo.

Because the venture matrix has such a large pool of talent to choose from it shouldn’t be hard to find the most qualified people to work on the project and bring it to life. It can either be handed out to individual pods or groups of pods.

If the project is designed correctly it should be possible for multiple pods to take “thin slices” of an idea and help to build a working demo within a few weeks. This is made possible because each six man team uses the same working practices, technology, libraries and software components. Thus enabling each pod to take a “thin slice” and make it happen super fast.

During this phase we take note of which people become passionate about the project. There may even be scope to create a new pod that consist of the folks where were most passionate about the project while building the demo. If this happens then we can set up the new pod as the main driving pod behind the business that could help to build it to the point of being ready to become autonomous – and of course the same team may be selected to take lead the company out in the wild.

How do we determine who owns what?

As people build their points within the matrix they are also building their shareholding. Also, if people become more passionate about and involved in a particular idea then they are awarded a larger part of that business. And if they are part of the team that takes a business into the real world they will receive the largest possible piece of the business.

How do we make money?

The venture matrix should always hold some kind of equity stake in the companies it gives birth to. It makes sense that profits from these kinds of investments should be re-invested in the venture matrix. In time the venture matrix could become part owner of many hundreds of businesses.

How could this get started?

As idealistic as all this sounds I personally believe it could become a reality. All it would take is the right group of people to form the first few pods and define the working practices and “constitution” of the company. Step 2 would be to build the peer-to-peer software that could make running the company possible.

So essentially it would be quite important that the first few pods consisted of people with the necessary skills and talent to build the software – along with the legal know how to structure such a strange company.

Where do we go from here?

The main purpose of this post is to get the idea out there and to get general feedback. I’ve been thinking about this for a few years and would be interested to hear general concensus. I was going to hold back on it for a while longer but then after reading this post here I decided it was time to put it out there!

In conclusion

To sum up, the Venture Matrix (working title) is a new type of company incubator that itself is a new type of company that anyone can join… company 2.0 if you will. It’s a cross between the Borg, peer-to-peer networking, MMORPG, socialism and capitalism in their purest forms. The main principle behind the idea is to use proven software patterns to manage and delegate work required to create a new efficiency in the market of starting companies. An efficiency that has hither too been impossible.

Shutup Brain. Stop Thinking About Cool Shit.

Shut. Up. Brain.

During the past 16 episodes of co-hosting Techzing & interviewing people like Peldi from Balsamiq and Jason Cohen from Smart Bear I’ve learnt that being a successful entrepreneur is about looking at the BIG picture. Covering ALL the business bases. NOT being tunnel visioned. But as usual I’m only focused on one thing…

Cool shit.

When will I ever learn that I can’t build a real business just by focusing on the tech.?

That’s why I need to slap myself in the face and start to think about the big picture. Even though my brain is unendingly and compulsively spinning with things things like…

  • Is jQuery’s $().keydown routine hogging too much processor time? I need to profile it.
  • Why does the content window look funny “for a split second” when Tweets are loaded?
  • What’s the most optimal schema to create a Twitter groups system

The thing is. I’ve already developed the working software that fulfills the value proposition. So why the heck am I focusing on the tech. minutiae details? Why do I continue to add features? Why don’t I start doing the things that REALLY matter to build a REAL business? Things like…

  • Oh, um, marketing “the thing that brings eyeballs’ to the product”
  • And, um, sales journeys “the thing that converts people into paying customers”
  • Erm, integrating Paypal “the thing that brings me money”

I’ll tell you why. Because that’s boring. BORING. All the fun is in the cool shit. All that other stuff is a pain in the ass.

But somewhere along the line I have to change my pattern. I. Have. To. Grow. Up. Must. Pull. Brain. Away. From. Cool. Shit.

So, there you go. This post is a triumph! I’ve started marketing TweetMiner.

Now I just have to go build the boring ass sales journeys.

Zzzzzzzzzzzz……

p.s http://TweetMiner.net is a web based RSS reader fully integrated with Twitter. It makes it easy to follow your RSS feeds and click a button to Tweet stories (and schedule those Tweets)