Category Archives: Advice

Applying The Creative Writing Process to Software

Grabbing the best ideas from other industries and applying it to your own is a fantastic way to learn and discover new ways to do things.

I was listening to the Tim Ferriss podcast yesterday in an interview with Neil Strauss.  Two best selling authors discussing their creative process for writing a book.  It got me thinking if some of the approaches they discuss could apply to to software development -which is also a highly creative process.

Let’s break down Neil’s process a bit.

The first part is to do a lot of research.  For example, when Neil is doing an interview with a celebrity, he will read everything they’ve written, listen to ever song, devour every bit of information he can about the person.  He writes out a list of 100 questions for the person and studies it like you would for exam prep.  Finally when it’s time for the interview he puts the questions in his back pocket and forgets about them.  As a result of this level of preparation and study the interviews can flow naturally.  He has a backup of questions to draw on if the conversation stalls but usually he can riff off the bulk of knowlege he has collected to build rapport and get to the really interesting details.

With a cache of notes from research it’s time to start writing.  There will be several drafts and the goal of the first one is to “Write to the end”.  Convert the pile of notes into a story as quickly and rough as possible without self editing along the way until you get to the end of the book.  This first draft will be read by no body else.

After the first draft you are just 1/4 the way finished.  The second draft is done for the readers.  You cut out all the uninteresting pieces, ensure the story arc is solid, characters are developed enough, flow is good, and jokes are funny.  You do this by putting on the hat of a reader and ruthlessly editing your first draft.

The next step is to put on the hat of a hater.  To deflect criticism before it happens you go through it again with the perspective of someone who wants to debunk your stuff and criticize your ideas.  At this step you fact check everything, and make sure there’s nothing offensive, or at least that the counter points are acknowledged and dealt with.

Finally it goes to the editor and is test read by anyone who wants to read the manuscript. Listen to their criticism, and adjust your book to improve things and cut parts that people don’t find interesting.

After enough feedback you’ll know when to lock down the book to a final version and send it to be published.

For an average size book this whole process can take upwards of a year to complete.

There are some lessons that we can take from the best approaches to writing books and apply it to writing software.

Notice that this approach to writing a book is not Agile, and it’s not waterfall, it doesn’t involve sprints, scrums or user stories. It’s completely unique to the way most software is created.

The first part of Neil’s process is research.  You might roughly correlate this step to requirements gathering but that vastly understates the effort Neil goes through.  I have never met a developer that thoroughly masters the domain knowledge before typing anything the way Neil does.  Taking months and often years to interview people, take courses, and generally immerse yourself in the space you will eventually write about gives you skills and knowledge to be able to write “to the end” without pause.

Side note: Interruption is one of the most detrimental things to the creative process. Stopping to look something up, or ask a question of the client can waste half a day of productivity.  Agile methods promote this open communication during development… maybe there’s a better way.

Writing to the end for the first draft is something not possible without having enough domain knowledge to do it in the first place..  There really isn’t a comparable product in any software project I have personally worked on which compares to this first draft.  The scope of Neil’s first draft expands far beyond what is in the final book as he will likely cut 50% of the pages during editing.  It has me wondering if it would be a good software development approach to rip through a 20,000 line first cut of an application knowing that I’d delete 1/2 of the code before being finished, slashing out features along the way.

If we did write this quick rough first draft application with the intention of whittling away anything superfluous to arrive ultimately at a publishable product then the next step would be to put on the hat of someone who wants or needs to use this software. Can you make the interface more intuitive? Can you give it some life? Are there any features that are more complex than they’re worth? What can be cut without destroying the utility of the application?

It would be only after these changes have been made that anyone other than yourself would see a demo.

In Neil’s process the final step is essentially debugging. Going through the application yet again with an eye for correcting errors, fact checking things, getting a lawyer’s review for liability etc.  At this point you would also ask for the input from as many test subjects as you can, gathering and filtering feedback to fine tune rough edges.  Essentially you want to make sure that if someone is trying your software they don’t have a reason to ask for a refund and they can’t claim that you or your company are incompetent.  The final product has to be great.

Only after enough friends, family and colleagues have used the software that you feel confident in it do you call it done.

It’s interesting to wonder if this would produce a better product than the typical agile developed software.

There are a couple of significant differences in software vs book writing however that need to be addressed.  Software is rarely a single developer’s sole project.  There is usually a team to divvy the work between. This team adds some communication load to the project as people need to be in sync.  This team approach doesn’t work well if all the domain knowledge is stuck in scribbled notes and in the head of  one guy that did the research.  Would Neil’s approach scale to writing a 10,000 page book with 4 other writers?  The counter point would be that if you’re looking at writing a 10,000 page book maybe it would be better to write 20 500 page books and only have a single author per book.

Software is also not written linearly.  When you start to write a book chapter you may be able to start writing and continue without stopping the flow of words.  You probably wouldn’t be halfway through chapter 18 and realize that it would be good to foreshadow what’s happening earlier, then stop and go back through to find a good spot to add that foreshadow element to an earlier chapter. A disruption like that would completely disrupt the flow of your writing.  It’s difficult to write software without jumping around like that.

Programming languages are much more rigorous than English.  it’s not always possible to skip pieces where you need to know an answer to get a working program. There can be hard dependencies that prevent you from moving on until they get solved.  Again this is an opportunity for interruption.

It would be interesting to try this method on a software project to see how it translates.

If you are interested in getting more details from Neil Strauss and Tim Ferriss about the creative process check out this video:

Capital vs Labor

A lot is being said these days about inequality. It is an issue that probably won’t be going away anytime soon as the trends continue to push the top 1% of earners even further away from the 99% as the middle class is getting hollowed out.

In the ground breaking book Capital in the Twenty-First Century Thomas Piketty goes into great detail about the real data about inequality over the past 100+ across 10+ countries.  It’s the most thorough data ever compiled on inequality.  The economic theory put forth after examining the evidence is that when the return on capital investments is greater than the growth rate of the overall economy inequality increases.  This seems to make sense intuitively as the families with capital to invest are the ones that see the most gains (on average)

What does this result have to teach us about running a business right now?  Well, we live in a time where capital is returning better than labor.  In concrete terms that means that in the aggregate (ignoring local anomalies) the cost of employees is going to grow slower than the value you get from their work.  If there’s something you can take home it’s that it is a great time to be investing and growing your business.  Hire employees, create products, launch services!  Take your profits and re-invest it – acquire assets, purchase stocks/bonds, and don’t let it sit idle.

On the other hand you will be on the loosing side of the equation if you are the employee eeking out minor raises every year.  If that is your situation then now is the time to get your shit together.  Aggressively get yourself into a position where you have capital to invest (pay off debt, grow your savings). Create assets such as publish a book, write software or invent something (something that doesn’t require ongoing labor). It has never been easier to sell things into a global marketplace.

Interestingly, during the time when the rate of return on capital was less than the economies growth rate, it was a great time to be an employee.  This happened during the golden years between 1945 and 1970 when the classic advice of get any job at the bottom of a corporation and work your way up by being a go-getter actually worked!

Personal 20% Time

A 20% investment seems to be the sweet spot for a doable amount that still results in significant benefits.  In Personal Finance saving 20% of your income is a great goal to strive for;  Businesses like Google and Thoughtbot have policies to spend 20% of your time on business investment.  You can apply this to your personal goals to achieve equally impressive returns.

Making 20% time work for you depends on one underlying premise: that it is an investment that can move you forward.

That means playing video games and watching TV doesn’t count.

For something to be considered an investment there has to be a reasonable chance that it will help you get towards your goals.  Even baby steps will help in this regard.

But also, taking some risks to learn and try something new can pay off big sometimes.

Taking one step back is often required to take two steps forward.

I have a goal at the moment to become a top tier Javascript developer (there is a lot of shitty javascript out there).  To reach that goal I am investing time into reading books on Javascript and Node.js.  As well I have started creating some commandline scripts, and web applications to put my learning to some productive causes.

Reading just a couple of books will put you in the top 1% (which is kind of sad).  Launching a handful of open source tools based on what you learn puts you into a category of developers numbering in the low thousands.  Having a popular open source tool would put you into a category of the top 100 or so developers.

Top tier developers (on any platform) are paid handsomely in our winner-takes-all economy.

It could all start by investing that 20% time into yourself by learning something new and then creating something new.

How to find time

One of the hardest things in getting productive work done has always been finding time to get focused work done.  There are so many demands on our time that what we want to accomplish gets pushed out in favour of other more immediate or more pleasurable things.

Back in the day when Ben Franklin, Albert Einstein, Nikola Tesla, and Alexander Graham Bell were alive the mind numbing effects of TV were not yet felt.  These great thinkers could devote an extra lifetime to their pursuits. The average Canadian watches 30 hours of TV per week! The loss of productivity to TV is astounding.  Taking that TV time and instead using it to learn, experiment and pursue goals would change the entire country.  If people took back their evenings to tinker with robots, or learn an instrument we would be in a very different planet right now.

Reducing or eliminating TV is the low hanging fruit for finding more time in the day.

For Ben Franklin not watching TV didn’t provide any competitive advantage over other people of his time (no body else had TV either). Franklin found his extra time in the mornings. By waking up before the demands of everyone else could direct his day he was able to get an astounding amount of work done. The quiet solitude you can find in the early morning hours can be more focused and productive than the rest of your day.  It is the perfect time to exercise, plan the day, or study something new.

Converting to a morning person takes dedication and planning. But it will give you a couple more hours in your day to devote to your pursuits. (How to do this is worthy of another post)

People today, have the additional benefit of the tools of automation and convenience. Microwave ovens, coffeemakers and dishwashers can each contribute small amounts of time back to our day if used. By brewing your own coffee in the morning you save both time and money over waiting in line at starbucks.  Technology is here to serve us and make our lives more convenient so that we may devote less time to chores, and more to what we want.

Technology and automation is the 3rd leg in our pursuit of finding more time.

Finally, with so many things demanding our time, finding focus and eliminating distraction will make the time we do get more productive. As a software programmer I am acutely aware of the pitfalls of multi-tasking. The human brain just isn’t very good at actively working on multiple things at once.  It takes time to really focus our attention on a task and get into a mental state where we can accomplish significantly more. Whether through physical isolation or by using tools to reduce chatter or developing a pattern of work that provides time to focus you can get more done with the time you have.

Of course you need the motivation and ambition to direct the time you do have to productive means.

Minimum Viable Sale (MVS)

One of the big things about running a business is managing risk.  As an entrepreneur I know that 25% of businesses fail within the first year, 60% have failed by year 4 and 71% have failed or closed by year 10. Given that most businesses are started with the best of intentions and usually with all the time and equity the business owners can provide these failure rates are indicative of the tremendous amount of risk.

One of the most effective ways to combat the risk and reduce the chance of your own business failing is to seek validation of your business idea early.  Very early.

Lets say you have a great innovative idea for a business. To start with you’d probably ask around to your friends to see if they think it’s a good idea or not. Chances are your friends, not wanting to hurt your feelings, will agree.  “That’s an amazing idea” they’ll say.  With the positive feedback, you’ll probably feel pretty confident about starting to build your business right away.

Unfortunately that is a false sense of validation.  Your friends are probably not your target market, they are motivated to maintain friendship rather than stomp on your dreams, and they didn’t have to put money where their mouth was.

To really get a sense of whether or not your business has legs start with getting some commitments on sales from real customers, if possible negotiate full or partial upfront payment. This happens before you’ve built anything, before a line of code has been written, before prototypes have been developed. Validate that the idea has merit from actual customers and confirm that they’re willing to put real money on the table for your solution.

Only after having made your sales and having financed the bootstrapping of your business do you actually go ahead and create what you’ve promised. With customers in place you have eliminated one of the biggest and most stressful risks in business  - the struggle to find new customers.  The remaining risk is to actually deliver what you promised below cost.

Making that initial sale is almost never easy, and getting the marketing message correct from the start is nearly impossible.  Investing the minimum possible money and time into an idea so that you can market test it can be critical.

So here’s a new acronym for you: MVS (Minimum Viable Sale). MVS refers to the absolute minimum amount of effort and money required to craft a compelling enough marketing message to land your first sale.

The MVS probably includes a presentation (Keynote/PowerPoint), perhaps a website, it might require a business plan, some mockups or even a faked version of your product. For example: a mobile app could be convincingly created in something like Fluid UI without writing a line of code that could be used as a demo in a sales meeting.

Even for a free service, the MVS is worth creating.  In some cases the MVS for this could be simply posting on reddit if people would be interested in it, or linking to an opt-in form on a website to build an initial customer list.

In other cases the Minimum Viable Sale might be a production run of 100,000 widgets in which case something like a kickstarter campaign might be a good option to reach as many people as possible.

The concept for creating that MVS is to do the absolute minimum amount of work before getting paid to actually work  on your idea. By making that first sale you’ve validated your marketing message, you’ve identified your customer base, and confirmed that your idea meets a need that someone is willing to pay for.

I’ve worked in places where the business had a good idea, identified an underserved market and put heads down for 4-5 months working on building a product only to find out after the fact that the potential customers were happy with their existing system, or the cost to change their current system was more work than it was worth.  Month’s of wasted effort and tens of thousands of dollars in development costs down the drain. Alternatively they could have started by trying to sell the solution they had in mind with the intent of getting enough cash commitments to pay for the 4-5 months work upfront.  The added benefit of getting customers before development starts is that they can help refine the features required for it to meet the needs of the market. Win-Win.

Starting a business with an MVS before you develop your MVP (Minimum Viable Product) is a simple way to get off to a lower risk start and help ensure that there is a market for your MVP when it’s finished.

What Do You Know

iphone app

What Do You Know?

This is the product of my first experience with outsourced development. What Do You Know is a simple iOS game where the player guesses what word matches the pictures shown. We picked a simple game engine to start with our initial foray into outsourcing to keep costs down and to help us quickly get through an entire project and learn our lessons from it.

I’m very excited to see how this game does on the market. It is comparable or better than most similar games in the category which I hope gives it a good chance of becoming a hit.

Our biggest lessons on this first project have been:

  1. Maintain control over the source code yourself – get a code repository on bitbucket or github where your team can regularly push their code as it progresses.
  2. If you are hiring a outsourcing company request senior/experienced developers be put on the project.  Senior developers will produce a higher quality product, and give more realistic timelines.
  3. You’re the boss, coach the team to produce the best product they can by providing the best leadership you can to them.
  4. Have the final project reviewed in detail. Check the source code. Growing a good business on apps requires that you can leverage past development into the future through code reuse.

This game certainly won’t be the last time we hire programmers to develop games for us. Keep an eye out in the App Store for What Do You Know.  It should hit iTunes in the next week or two.

Competition is Fierce

EMBA_start_up_competition_996x446Our market economy is built around the premise that competition makes everything more efficient and better over time. For most products and services a careful analysis of the competitors is very important to your success.

This market analysis applies to all aspects that you can glean from your competitors. The product features and design, quality of service are obvious things for the engineer in you to look at for hints about what you can do better with your product. Business models, marketing and sales strategies are just as important to your success so look to those too for ideas that can be improved on.

Importantly, if you are planning a business idea and can’t be better than the competition in enough ways to matter DON’T WASTE YOUR TIME.

It’s an approach right out of Apple’s playbook.  Only enter a market where you know you can dominate with a superior product.

As an App developer it has become interesting to see the marketplace evolve into a much more competitive space over the course of a few years. With the vast amount of successful apps being free it’s impossible to compete on price, the race to the bottom has already finished. To develop a successful app now requires a great design, superb artwork, discoverability and viral tools for additional distribution, good marketing, and positive reviews.  There are only 100 apps in the top 100 highest grossing list, and those apps are (for the most part) doing all those things.

To have a great app idea and expect it to be a hit without addressing all these things that your competitors are doing is naive.

High Performance Static Websites on Amazon S3

I’ve been seeing more frameworks lately for generating static websites. The reason for these becoming more popular recently is the result of several developments.

  1. Cheap shared hosting is notoriously unreliable, slow servers overloaded with too many websites and hacked servers being able to infect and hack many other sites at once.
  2. The development of 3rd party services such as Disqus to power the dynamic parts of a website with embedded javascript. (removing the requirement of server side logic)
  3. The scalability, performance, uptime and low cost provided by Amazon S3 and their CloudFront CDN service.

The difference in cost between a scalable dynamic site and a scalable static website can be staggering.  So if there is a way you can convert a website over to be static (perhaps with a daily or hourly upload of new content) it may be worth your while.

A website with 1 million page views per month on Amazon S3 with CloudFront would cost roughly $6/month depending on the size of the assets.  Building up a simple server configuration with 1 database server and a webserver with small EC2 instances would bring the costs up around $150/month.

One of the nice things about developing a static website is that you can script things however you want to.  Concatenate strings in bash or PowerShell or go all the way to having a complex database backed CMS system and template engine.  It also means massively less complex server infrastructure.   No more nginx reverse-proxied gunicorn server paired with a database server and a host to tools to monitor uptime and send alerts should things break.

It’s for these reasons that I am working on my next project to have a static website backend instead of a dynamic django app.

Using a template engine like Jinja2 it is trivial to convert content over to static files ready to be uploaded.

Some tricks may be needed to handle things in a more complex static site.  Perhaps a small light server to refresh the static content every hour, or to run scheduled tasks, or to do other various asynchronous jobs.  Still the costs can be brought way down if your servers don’t have to handle the web requests.



Cockiness of Programmers

There’s no doubt that programmers are lazy people.  Anything that can be automated is, copy/paste code – you got it!

There is another trait of programmers that they assume because they can program in one language well, and have touched a few other languages over the years they can quickly learn a new language on the job.

Programmers are arrogant about their own skills.

The article What If Cars Were Rented Like We Hire Programmers? exemplifies the problem though their analogy is not accurate.  A programmers job is more like the mechanic or factory worker building the car.  If you had built or fixed only Subaru Imprezas for 10 years then you are not amazingly qualified to fix Fords.  If Ford is looking to hire, they know that there are 1000′s of mechanics more experienced on their cars in the pool.

I say this because after several years of writing Javascript, learning on the job, I finally decided to pick up a book.  The first thing I learned was just how much I didn’t know.

More programmers need to read books to master the skills they need on the job instead of relying on Stack Overflow and Google to solve all their problems when they arrise.

The thing to watch out for is the situation where you read someone else’s code and say to yourself “I have no idea how this works, or what it does”.  As a programmer that should be a red flag – you don’t completely grasp the language syntax.

If you don’t have a complete handle on the syntax of a language chances are you also don’t know how to write idiomatic code.  Without those two things mastered the code you do write will be poorly organized and buggy. The next programmer to come along to work on your code will hate you.  You will be that guy who everyone bitches about for writing bad code.

Bite the bullet, read a book from time to time.  Always be Learning.


ABT: Always Be Testing

Sales teams often have the letters ABC plastered somewhere next to their weekly leader boards and top salesman photo. It stands for Always Be Closing and it’s a motto that keeps sales people laser focused on their goals. Marketing teams should have a similar motto: ABT – Always be testing.

Lately I’ve had the opportunity to do a lot more testing on the performance of webpages and apps. One thing always holds true. Nobody knows what’s best – which is why it’s always important to test things.

This point cannot be more clear. If your head of marketing, lead designer, or CEO could peer into the minds of potential customers and knew the most effective way to sell to them, then they would probably be living on a beach somewhere. The fact that they keep coming into work by car instead of helicopter is enough evidence to show that they don’t have all the answers.

One of the things that gets under my skin about marketing is the focus on branding and brand related marketing. Reading a book about branding is like taking a walk back in time to the 1980s. It’s difficult to find good recent examples of successful brand marketing because more and more companies are discovering that it’s simply not effective. With more technology to play with it has become easier to track the performance of marketing efforts. TV ads can be tested in different regions. Web banners can be split tested daily to find the most effective ad copy.

You know what tends to happen when tested and accountable marketing comes into play? The clever catch phrases disappear, gimmicky websites get toned down and focused, and communication becomes more direct.

I recently heard a pitch from a brand marketing consultant who tried hard to impress upon us the importance of a good tagline as the basis for all marketing. It was not very good advise. One of the examples he used was Avis and their famous “We try harder” tagline. It was claimed to be a tagline that helped grow the business a lot. Question is if taglines are that important why aren’t they presented up front in current marketing.

“We Try Harder” shows up as a footnote on Avis’ current website – barely noticeable. It’s not important enough or effective enough to use on their adwords copy. If taglines were good marketing they would be more prominent in current advertising.

I have tested a lot of marketing ideas over the years, and there are constantly surprises and unexpected winners. I would however never claim to know the best approach – The best approach changes year to year. The experience you get from testing gives you a pretty good place to start from for future tests.

When your business income is at stake Always Be Testing. Never trust the status quo, and don’t trust your copywriter to give you optimal sales copy (why buy one sales page when you can buy two for twice the price). Test every assumption. ABT.