Disrupting an Industry

A colleague and I had a recent discussion about this: what does it mean to “disrupt” an industry?  I think we’ve all heard it at some point another – usually in a bunch of marketing speak.  But what constitutes a “disruption”?

In my mind, a disruption is some sort of rapid introduction which forces a rapid reaction from the rest of an industry.  If a company fails to react, it may find itself facing a reduced market share or bankruptcy.  A disruption is not a gradual change, nor it is it a soft change.

A few thoughts about the subject have been on my mind:

In order to disrupt an existing industry, it generally takes some sort of new technology which makes an existing task (or series of tasks) easier, faster, or simpler.  Streaming movies on Netflix is an example of this.  Rather than having to get off your couch, walk/drive to the movie store, browse over a series of movies, pay the clerk to rent it, then go back home (only to discover the VHS tape you’ve rented is stretched and garbled), now all you do is fire up Netflix and start streaming a show.  Companies like Blockbuster failed to either accept (or counter) this kind of change, and as a result, didn’t fare so well.

There are a few considerations in regards to disruption:

  1. What gains are to be made with a disruption? If the potential revenue gains are small, there’s a smaller chance that it’s a good target for disruption. It’s not too likely that someone is going to introduce an iPhone app that’ll destroy lemonade stands, partly because there’s little to no revenue in it.  Because there’s little revenue in it, it’s not as big of a target.
  2. How difficult is it to disrupt a given industry?  There’s a lot of smart people out there, and the low hanging fruit is usually the first to go.  For example, when I was a missionary, my old mission president and a colleague created a system for computerizing index cards in libraries.  This was something that hadn’t really been done before (at the time), and as a result, they did well.  Because the market of library card catalog equivalent software is already established, they likely wouldn’t be as successful if they were to do it again.
  3. How “big” is the disruption?   If you created an app to save someone a single click per day, it’s not too likely to catch on.  If you save them an hour of work a day, it’s a lot bigger of a deal.  This is why I say a disruption has to be significant in order to be consider a disruption.  This also involves the number of potential people affected by the disruption.  Saving a single click to half a dozen users per day isn’t going to make you a billionaire.  Saving a hundred million people a single click per day has a potentially bigger impact.*  The value of the impact could be measured as the number of users affected times the impact per user.

A conference I was at recently got me thinking more about this: what industries are ripe for disruption?  What is the next “low hanging fruit” which could be automated or digitized?  This is a difficult question, and to a certain extent, I think is impossible to predict.  I never would have guessed that app that helps you take grainy, washed out pictures of food could be worth a billion dollars.  I also wouldn’t have guessed that a chat app would also have a similar value.

A few things are coming to my mind, which are ripe for disruption:

  • Video chat.  I use Skype a lot at work and home, and I’ve grown to hate it.  Someone is totally going to create a decent cross-platform web based video chat.  Even if it resorts to using black/white imagery, if the frame-rate is good, I think people could go for it.
  • “Real” social networking.  There’s a growing counter-culture movement of people getting outside and actually doing things in person, but in an augmented way.  Pokemon Go is a perfect example of this – it took a video game outside.
  • Wireless headphones.  It may just be my perspective, but there’s very few wireless headphones that actually work well, sound good, have decent battery life, and are reasonably priced.  I think the first <$100 (USD) pair of wireless headphones that look and sound good, and have decent battery life will sell well.  People hate dealing with cords, especially headphone cords.
  • Non-Apple laptops.  Manufacturers are slowly figuring this one out, but I’m amazed it has taken them this long.  Try to find me a decent Windows based laptop that has a 1080p screen, a decent keyboard, decent battery life, and is made from something other than plastic.  That criteria alone narrows it down to maybe half a dozen models.  It’s only a matter of time before someone does it right.  The question is, who will have the guts to actually try making something decent?

* By this, I’m referring to Google’s search engine, which doesn’t even require a user to click “Search” – it just starts searching as soon as they start typing in a query.

Producers vs. Consumers

This is something that I’ve been thinking about lately – how there are basically two groups of people online: producers and consumers.

A producer is someone who makes content.  It could be a blog or forum post, a video posted to YouTube, a Twitch stream, a tutorial, a song, or almost anything.  Anything that someone else can watch, listen to, or read.  A producer can be a single person or a group of people (or even an automated bot).

A consumer is someone who consumes content made by producers.  It could be someone watching a YouTube video, reading a blog post, or listening to a song.

It is incredibly difficult to be both a producer and a consumer at the same time.  Usually you are doing one or the other.  (The exception that comes to mind is listening to music while doing something).  In most cases, you are one or the other – a consumer or a producer.

It is easier to be a consumer than a producer.  Consuming content doesn’t take as much talent, skill, or effort.  Anyone can watch a football game, but not everyone can play football, and that’s fine.  Not everyone who watches football wants to play football.  There’s nothing inherently wrong with being a consumer, unless that consuming is taken to an excess.

From a financial perspective, you won’t ever get rich being a consumer. If anything, you become less wealthy being a consumer, as you are spending your time (and potentially money) by supporting a producer.  There’s nothing wrong with supporting producers – quite the opposite!  But if your plan is to become wealthy by consuming someone else’s products, I hate to be the bearer of bad news, but it’s unlikely to happen.  Water doesn’t flow upstream.

Lately I’ve found myself more and more motivated to become more of a producer.

The Giraffe Principle

I discovered something a few years back that I call the giraffe principle:

If you are willing to reach, you can get things other people haven’t gotten to.

The first time I really noticed this was in the grocery store, when shopping for fruit.  All of the fruit closest to the edges of the bins was thoroughly picked over, but the fruit that was further away had better selection.  It was ripe, less bruised, and better smelling.*  People were basically being lazy and picking whatever fruit was closest to them, rather than reaching a bit further away and getting a better piece of fruit.  This really could be re-worded:

You can expect the same results with the same behaviour.  Different results will require different behaviour.

If you want to do something great, you’ll have to do something different than the average person.  Rather than watching TV in the evening (like an average person probably does), or checking Facebook 20 times a day, do something else.

In my case, that “something else” has been a few different things: woodworking, web programming, cooking, etc.  I have a huge amount of respect for those that produce content, rather than consume it.  For example (and a bit ironically), lately I’ve been watching a lot of Cody’s Lab, Engineering Explained, and This Old Tony on YouTube.  I suspect each of them are getting a decent little income from YouTube.  It almost makes me want to start recording some of the things I do.

Footnote: when purchasing fruit, don’t be afraid to smell it.  Smell and taste are related, and if it has less smell, it’ll probably have less taste as well.  This works for things like apples or peaches, but not so well for bananas. 😛

Bad Developer, No Twinkie Part 10: Providing Terrible Estimates

This is a tricky one.

At one point or another you will be asked to give an estimate of how long it’ll take to do a given unit of work.  Unless you have tons of experience and practice at this, you’re probably going to give a terrible estimate.  Giving a good estimate is like learning to play the bagpipes: anyone can do it, but only someone with a lot of experience can actually do it well.  And in both cases, no one likes it if it is bad.

So how do you give a “good” estimate?  The easy answer: don’t give an estimate.  At least don’t give an estimate until you feel you have enough information to give a reasonable estimate.  To misquote Donald Rumsfield: ‘There are known knowns.  There are known unknowns.  And there are unknown unknowns.’  If you are basing your estimate only on the ‘known knowns’, your estimate will be wrong.  The more information you can gather, the better your estimate should be.

Other things that you may wish to consider when providing estimates:

1) Don’t give an estimate at all until you have a better idea of how much work it entails.
2) Don’t give an estimate until you’ve secretly done what is being asked, then you will know exactly how long it “will” take.  (This isn’t always an option – especially on anything larger than a few days worth of work).  Then, instead of sitting on your hands for the next while, start working on the next request.  Again, this isn’t a very good idea, but it can sometimes work.
3) Take your initial estimate, then double it.  Then double it again.  Then for good measure, add another 50%.  It’s amazing how many problems go away when the solution takes 6 months and takes half a million dollars.
4) Give a range, and state assumptions for the range.  The lower the estimate, the more assumptions you will need to complete it on time.  The higher the estimate, the looser the assumptions.

Losing Sight of the Goal: Making Stuff

As a software developer, it’s your job to make something.  Maybe it’s a website.  Maybe it’s a mobile phone app.  Maybe it’s a hat trading simulator for the core of a video game.  Either way, your job is to make something.  Sometimes you aren’t writing code.  That’s completely okay.

Maybe it’s just my Canadian background, but have you ever heard the adage about spending 90% of your time sharpening your ax, and 10% actually cutting?  The ratios are likely swapped, but there’s some truth to it.  In doing your job – making stuff – you sometimes need to do a bit of research.  You might not know how something works, so you spend time reading API documentation, Wikipedia articles, or ancient PDFs of algorithms that you need to use, but don’t understand.  You often need to discuss things with co-works, clients, or shareholders, send emails, and write documentation.  That’s time that you aren’t spending writing code, but that is still time spent doing your job – making stuff.

Never lose sight that the goal is to make something – not write code.

Developer Logs/.plan files

One thing that I’ve done, as long as I’ve been working, is keep a personal record of everything I work on while I’m at work.  It’s usually just a text file, and for each day I add a new entry.  A daily entry would look something like:

January 19, 2017:
- (In at 7:56 am)
- Dealt with 5 emails related to project Twinkie.
- Reviewed pull request #1337.  Unit tests failing.  Pass back.
- Had meeting about frobnicating options.  Decided as a team to go with Option B.
- Logged new work tickets for tasks relating to Option B.
- Had brief meeting with Daryl and Larry about Option A.  They say B.
- Run into error with deployment: "System Error: Ran out of printer tape".
    - Resolved by running command: "sudo feed_me_a_cat".
- Review pull request #1338.  Needed small tweaks.  Merged it in.
- (Go home 5:31 pm)

It’s nothing super-detailed, but it at least can be used to refresh my memory of what I did on a given day.  These sorts of little notes have been incredibly helpful in a few situations.  Even in an environment where you don’t have to keep time sheets or specific hours, they can still be really helpful.  For example, if I ever run across a “System Error: Ran out of printer tape”, now I can go back and reference my notes to see what I did to fix it last time.

I even do this for my own personal projects, but in a bit less detail. In my personal projects, I’m not concerned about how much time I spend on something, but I am concerned about writing down little notes that I suspect will help me later on.

Eventually I’d like to make these notes into more of a narrative. Like when you are wandering around in Skyrim or Oblivion, and you come across a note left by a previous adventurer… or like John Carmack’s .plan file notes. They are definitely less technical, but still incredibly useful.

Code Smells

Some things in life stink.  Literally.  Just ask any parent with a small child who is still in diapers.  When something stinks, it’s natures way of telling us that either something needs further investigation (like a stinky diaper) or it’s a sign that we should stay far, far away (like a rotting corpse).

You may have heard someone say that particular code doesn’t pass the “sniff test”, or that the code “stinks”.  To the inexperienced, it can be difficult to detect this.  What are some indicators that code stinks?

Variables that are declared, but never used.
If it’s there but not needed, why is it there?

Poorly named functions or variables.  If you ever see something like “someFunc() someFunc2() and someFunc3()”, that’s not a good sign.  It’s a sign that code was either written in haste or not properly cleaned up after the fact.

Large swaths of commented out code.
 This indicates that code isn’t being properly cleaned up.  If you need to do something drastically different, do it in a different source control branch.

No code comments at all.
 I recently heard of a rather controlling developer that insisted that there be no comments in code at all.  While I believe that code should, to a certain extent, be self-documenting, this is an extreme.

Lots of “to-do” comments.
  This indicates that things aren’t done.  This is probably fine if you are a single developer working on a single project, but multiple developers working in the same code should probably be using something better to track what still needs to be d one.

Functions with “or” in the name.
 (e.g.: GetCountryOrState()).  This is a sign that things should be broken down into simpler steps.  For example, it could be split into a GetLocation() function which could then call GetCountry() or GetState().

Constant variables that aren’t explained.  There’s nothing quite like wondering what is so special about the number “35.10235” without anything describing what it is, or where it came from.

Excessive amounts of string parsing.  Unless you are writing something that handles a ton of  string related data, and you have to do some seriously funky things to it, excessive string parsing is a bad smell.  Most of the time it’s not necessary, or there’s a better way of doing things.

In Python, deepcopy().  Sometimes it is a necessary evil, but most of the time it isn’t.  If someone is using deepcopy(), especially if they use it a lot, that’s worrisome.

In any language, using the equivalent of eval().  eval() basically takes in a string, converts it into code, and runs that code.  Any time you use an eval(), a hacker grins.  I’m sure there’s a valid use case for turning a string into compiled code, and then running that code, but I have yet to see one – other than a compiler.  This kind of stuff is especially dangerous with JavaScript.  If you are using eval() in a web page, you’re just begging to have hackers abuse your system.

Not using stored procedures when you could be.  If you are ever working with a database, you’d better be using stored procedures.  I’ve seen my share of horrible things, including this.  Stored procedures won’t protect you from everything, but if you are still open to SQL injection attacks because you aren’t using them, then shame on you.  One particular application I worked on had SQL queries happening in button even handlers.  The original developer never accounted for people like Mr. O’Conner, who happens to have a single quote in his name.  A malicious user of an application like that could have easily destroyed the entire app’s database with a single, well placed string.  It’s 2017 – there’s no reason why anyone should be combining strings to make queries when stored procedures are an option.

I’m sure there’s lots of other code smells, but these are the ones that stand out to me.