We build innovative web based applications

This is a response to Rand Fishkin's blog post "24 things I know now that I wish I knew then" which is itself a response to Rae Hoffman's "Entrepreneurial Lessons: 48 Things I Know Now That I Wish I Knew Then"

1. "Premature optimisation" applies to nearly everything (automation, scale, others?). The famous Paul Graham adage "Do things that don't cale" is the same advice as "premature optimisation is the root of all evil". Think about it.
2. No one cares what you do - they will all forget your embarrassing marketing gaffs or shitty 1st version of your software. Ship and self-promote fearlessly. You'll learn along the way how you should actually do it.
3. Your business will take at least 5 years to do anything interesting.
4. Don't pay attention to the tech press (and MOST OF ALL the "valuations and funding" press)
5. You don't have to move as fast as you think you do (this is a lift from Mike McDermot, CEO Freshbooks from this post)
6. Play life like a game of chess: look at the situation as it is now and ignore what you had planned up until this point (I learned this one by playing lots of games of chess simultaneously to the point that I was unable to remember individual game plans so I had to assess each board as it lay - very powerful stuff)
7. Value your family and your friendships - celebrate what's amazing every day in your life and use it to give you perspective (and help keep you from the "deferred living" trap)
8. Not everyone gets rich in their early 20s and you won't feel any less fantastic if you manage to "succeed" at any time in your life.
9. VC funding works in a really specific set of circumstances and results in acqui-hires most of the time: it's NOT like being given money.
10. You don't need funding yet.
11. Your first business should not be a heavy technical investment even if you are a coder.
12. Become profitable at anything that doesn't take up all your time, rinse, repeat.
13. Don't invest in product, invest in outcomes.
14. Don't write your own software, even if you're a coder, unless you want to go down the VC/YC acqui-hire route.
15. The only thing that matters in a new business is sales. All activity should stem from that: marketing, customer service, development.
16. The market is huge, and you can compete. There isn't only one dry cleaner in New York.
17. First mover advantage is almost always bullshit.
18. Frugality creates opportunity. Just because you're planning on being rich, doesn't mean you can spend like you already are.

There has been spirited debate on Hacker News this morning following Jeff Atwood's post "Please don't learn to code".

Let me start by saying that fundamentally I agree with Jeff - the whole "everyone must code" and comparing creating software with literacy and numeracy meme is pretty ridiculous. I don't begrudge anyone their right to a hobby, though so if the Mayor of N.Y is keen to learn to code, good on him.

I would like to add a word into this debate, though, and that word is automation. Computers are fantastic communication tools and that is one of the primary purposes for which they are used today.

They are also fantastic tools for automation, and I think this is where the shift to GUIs really left a lot of the utility that existed in early computing behind. Yes, I realise that GUI platforms generally have automation tools associated with them but automating a GUI task is kind of less precise and, in my opinion, a little more confusing that automating command line tasks.

I think that every man, woman and child who uses a computer should be taught the concepts and basics behind using their computer for automating tasks.

There are a plethora of options for educating people in this area and I don't think that [INSERT PROGRAMMING LANGUAGE HERE] is the best place to start.

In fact I'll even go so far as to say that I think every man, woman and child who uses a computer should learn about the command line as well (I realise that the utility of the command line varies by operating system but I wouldn't be averse to a Linux/UNIX variant being used as an educational tool - the concepts are all the same no matter where you go).

From there, people can go on to coding if they wish, or they can improve their productivity at work through automation, or they can create a script to manage their photos or music, or whatever they want. Once people get a taste of automation, they really start to go hog wild with it so the computer is their proverbial oyster.

So in conclusion I'd just like to say that yes, I agree with Jeff that the "everyone should code" meme is bullshit, but I also agree with the notion that everyone should learn to do more with their computer than just passively use software, and that we should call it automation, not coding.

This is an unpaid and unsolicited editorial piece. I don't have any affiliate links or agreements with Andrew, I'm just a very happy member of Mixergy Premium, and I see this as a way of providing value for my own audience.

If you're not already familiar with it, Mixergy.com is a website where Andrew Warner interviews successful business people to learn and share the secrets to their success.

Since the interviews are free and life isn't, Andrew monetises the site in 2 ways:

1. At the start of each free interview he has 3 paid advertorial announcements
2. He sells a premium subscription service that gives you access to special content

Plenty of people listen to the free interviews, but let's look at why you should go with Mixergy Premium.

The difference between the free interviews and the premium content

Although the free interviews actually quite often contain specific tactical and strategic advice, they are largely focused on a narrative discussion of each interview subject's journey.

Whilst you quite often pick up a gem and generally gain a "business mindset" almost osmotically by simply listening to enough interviews, the free interviews do not have a strong focus on providing instantly actionable steps to improve your business.

In contrast, the courses you gain access to as part of your Mixergy Premium subscription are each an entire hour with a singular focus. Examples of some course topics are:

• Profitable ad buying
• Effective outsourcing
• Copywriting
• PR
• Customer acquisition

The list goes on. All the courses are taught by people who have successfully applied the material in their own businesses.

It should also be noted that with a premium subscription you also get access to all the back catalog of interviews Andrew has ever done on the site (they only stay free for 7 days) so for example if you wanted to see this interview with Kevin Hale from Wufoo, you'd have to go premium.

Is it good value?

In order to determine if Mixergy Premium is good value, you first have to look at the cost and then your return on investment. Fortunately, Mixergy Premium only costs $200 for the year.

Yes, that's right, $200 for one year.

So here are a list of ways you can get a return to cover your investment:

• Drink 6 fewer cups of coffee each month
• Drink 1 less six pack of beer each month
• Don't super size every 3rd takeout meal
• Drink tap water instead of bottled water 6 days a month
• Ask someone in the street for $2 each day. If only 27% of people say yes you'll have made your money back (that's about one person every 4th day)
• Walk your neighbour's dog for $5/week
• Mow your neighbour's lawn for $10/fortnight
• Send 2 fewer text messages per day

Whatever, you get the picture. This is a slightly facetious list but the point is: where is the fucking risk?!

To top it all off, Andrew offers a 100% no questions asked money back guarantee. So the short answer is that there is no risk.

Okay it's inexpensive but is the advice valuable

Yes.

Here is my Mixergy 101 course list:

1. Juan Martitegui's business blueprint
2. Brian Kaldenberg's customer acquisition
3. Dane Maxwell's copywriting
4. Derek Halpern's advanced lead generation

There are a crapload of other courses and more niche content but as a basis to help you get some value immediately, those are the first 4 I would listen to, and in that order.

I can personally report that, using nothing more than the strategies and tactics presented in those courses, I found a niche, conducted an ad campaign, built a landing page with copy that converted, got my first lead and signed up a customer.

And you know how I pitched them? I just laid out all the info from those courses and said "This is what I can do for your business".

What are you still doing here!? Go and sign up for Mixergy Premium now!

Sorry if this is a little "off topic" for this blog but I was really inspired by this recent (and wildly successful) experiment by Louis C.K in independent release of artist work.

My father, Nick Dooley has been performing as a street musician for a long time and this seemed very similar in concept to street performance, or "busking" as it's called.

I saw a lot of talk in the blogosphere in the following days/weeks after Louis released his video encouraging other independent artists to do the same, but also a lot of speculation that this is only a way for people who are already famous to successfully release work.

In order to test whether or not this would work for the millions of independent artists out there I thought I'd put up a landing page for my Dad with some tracks for download and a PayPal button to see what happened.

So without further ado, I give you Nick Dooley's Virtual Guitar Case

I'd love to hear what you think - feel free to email me on iain@workingsoftware.com.au

PS: I also registered the domain http://www.mp3busking.com/ - if you think this is a good idea and you'd like to have your own work listed on a publicly available directory let me know and I'll put something together.

Templating is a real hot button in the web development community. The only other topic I can think of more prone to sanctimony and religous flame wars is quality control and testing.

The high horses that people usually get on are that all too familiar TLA MVC (Model/View/Controller) architecture and "separation of presentation and business logic".

The poor pedestrians upon which they look down are those who have written "spaghetti code" - templates where presentation logic, markup, business logic, database access configuration and whatever else you might imagine are mixed up in the same file.

Well, I've got some news for you: you're all wrong.

What is spaghetti code anyway?

Spaghetti code is a really old term dating back to the days of goto statements and the transition from unstructured to structured programming languages.

There's not really one true definition and it's meaning has evolved over time but the common thread is that it refers to code where things are mixed together that shouldn't be, the result being difficult to understand if you didn't write the application (and sometimes even if you did).

In the world of web development, the term most often refers to the inclusion of both business and presentation logic in the same file as your HTML (and javascript and css or whatever else you have on your page).

A typical example written in PHP would look like this:

Why all templating sucks

This is where folks will start to get technical about why their code isn't spaghetti code.

Oh no! Not me because I use (Django|Rails|Haskell|Node.js|Symfony|CakePHP|Tornado|Plone) and the superior templating language (Django Template|ERB|Mustache|PHP|TAL|Smarty) doesn't allow business logic in templates and enforces a separation of concerns

You, the reader, December 2011

The problem is that in every single one of these circumstances, the templating engine has 2 primary responsibilities:

• The fragmentification and inclusion of common interface assets (to avoid duplication and maintaining the same code in multiple files) - eg. headers, footers, sidebars and the like
• The output of dynamic content

The output of dynamic content requires logic (if/else, loops being about the bare minimum).

The creators of templating languages have, to varying degress, availed themselves of a false dichotomy, namely that there exists "presentation" logic and "business" logic, the former of which belongs in templates and the latter of which has absolutely no place in templates and must be banished immediately.

I say false dichotomy because this is an arbitrary separation - a choice made by the person who created the templating engine and is completely subjective.

Even Mustache, which boasts to be "logic-less templates" is guilty of having some logic in their templates. After all, if I have a construct that performs logic, even if that logic doesn't look like logic, isn't it still logic? To take the demo on their home page:

See that last line that says "#empty"? In the demo you modify some JSON and render the template and it suggests "Try setting empty to true". Low and behold IF you set empty to TRUE, THEN the paragraph tag indicating that the list is empty is rendered. However IF you set empty to FALSE, THEN the paragraph tag indicating that the list is empty is not rendered.

So basically I call bullshit on Mustache being "logic-less". It may have the most ruthless attitude to excluding "business" logic (whatever the hell that is) from the templates but there's logic in there, to be sure, even if they're trying really really hard to make it look like there isn't.

It's all spaghetti code

So I'd like to proffer that all templating languages produce spaghetti code.

Surely not, because that Mustache template was heaps easier to read than the PHP example you gave at the beginning of this article

You, the reader, 2 minutes later, December 2011

Well let me hit you with this: although there are varying degrees of entanglement and obfuscation, and certainly one person might write more readable, maintainable spaghetti code than another person, that doesn't change the fact that it's still spaghetti.

I would like to formalise a new and more ruthless definition of spaghetti code:

As soon as I'm looking at more than one programming or markup language in the same file, I'm looking at spaghetti code.

Iain Dooley, December 2011

This issue was been popularly addressed in JavaScript for quite some time. The first time I recall seeing the concept of banishing things like onclick attributes from markup was when I first read about the Behaviour.js library and the whole thing just seemed incredibly sensible to me. Why is it that we still accept the equivalent in our server side templating engines?

The holy grail: Template Animation

So long as I'm updating the definition of spaghetti code, I might as well coin a new term while I'm at it:

Template animation: the practice of using static HTML files as a resource from within your application to be manipulated via the DOM to generate dynamic output.

Iain Dooley, December 2011

Instead of splitting up the task of templating in the following, arbitrary fashion:

We can create a non-arbitrary, completely objective separation where the view/template layer truly contains no logic what so ever:

When I first had this idea, it was because David Grinton and I had actually created a little PHP script for doing Django style template inheritance in XML.

It was a very short mental walk to realise that, with a system in place that was responsible solely for fragmentification of documents and re-use of common assets capable of returning head-to-foot complete HTML files, all the backend programmer has to do is load the file and manipulate it using the DOM to output the required response.

Whilst the impetus for this was the fact that we'd created a tool for fragmentification of XML documents, it really doesn't matter what the frontend developer uses.

Even Dreamweaver is capable of allowing a frontend developer to re-use common view components and it has no impact what-so-ever on the application layer so long as the server side developer is presented with a complete document to work with.

I created a little proof of concept which you can see in this class file just done using raw DOM functions in PHP.

Since DOM manipulation totally sucks I went looking for a jQuery port to PHP and found phpQuery and queryTemplates by the same author (neither of which appear to be being actively maintained), as well as HTML::Zoom for Perl on CPAN.

What are the advantages?

Dramatically simpler resourcing and training (in-house or outsourced teams)

The single biggest advantage here is simplicity of resourcing and separation of skills. To illustrate this let's look at a counter example.

Recently, Luke Wroblewski posted his notes from the "Design for Continuous Deployment" presentation by Randy Hunt from Etsy. From the article:

The company has 140 people working on the product (design & engineering) and they are all pushing production code between 50-60 times a day.

In the section entitled "How do you do it?" the two key points are:

• Everyone at Etsy has a development environment on their machine. All the designers have local environments to do design work on GUIs.
• Quick start guides and packages are created for designers to bring them up to speed on how the process works.

This is emblematic of the problem in traditional templating engines/development frameworks, and it's fine if you have a design and engineering department, a profitable business and time for designers to get "up to speed on how the process works" by reading guides and packages (as well as the time to develop those resources in the first place) but ultimately this is not a solution for smaller, scrappier teams with less time and money on their hands.

The fact that Etsy even had to discuss this as a feat of engineering achievement shows just how big of a problem it is, and changing the way we approach templating solves this problem completely.

By defining an application first as a series of static, clickable HTML mockups and then passing these off to developers who "animate" them, you obviate the need for designers to be exposed to things like local development environments or logic of any kind.

You also create non-blocking workflows between designers and developers. Nothing a developer can do will ever break what the designer is working on. The designer will never have to wait for a piece of backend code to be written in order to design a new feature or refine an existing one.

Certain strategies can be used such as not changing ids and classes so that these "hooks" remain constant and you break the application less when changing it, but regardless of this, a breakage due to a change in the markup is solely a coder's problem. It's something that automated testing or even basic user acceptance testing will isolate quickly and which one person (ie. the developer) can fix on their own without the need for costly communication between the people working on the front and the backend.

I'll stake my reputation (whatever that's worth) on the fact that any "brittleness" introduced on the developer's side of the equation as a result of having to target specific pieces of markup can a) be reduced to an extent by not changing classes and ids too frequently and b) will be far less costly than the traditional headfuck involved with designers having to have a local copy of the entire application running in order to iterate on your application's interfaces.

Even as a single person on a project you'll find it easier to iterate and easier to find someone else to work on it if you want to at some point.

Dramatic reduction of technical debt on any project and any platform

Technical debt manifests itself most frequently in the inability to iterate quickly and keep your product current. This reduces your ability to compete and thusly your effectiveness as a business.

This approach to templating basically eradicates the biggest source of technical debt: having your interface tied inextricably to your codebase.

It is a simple fact of programming on the web that HTML(4/5/X whatever), CSS and JavaScript are present in every technology stack.

By prototyping your entire application in static HTML, CSS and JavaScript, you isolate the most valuable part of your application (the feature set and user experience) from the means with which it is implemented (or "animated").

The beauty of this approach is really that it doesn't matter at all what you use on the backend: or even that you are consistent, or that you start with the same approach you continue on with later, or that everyone uses the same coding standards or whatever.

If you're not happy with the code that's driving your application, just pick up and go somewhere else. I'm not saying this is free mind you, but it would be a hell of a lot easier to take a complete, static HTML prototype that was written with a PHP backend using Template Animation and reimplement it whatever-the-hell-language-is-trendy-these-days (or what language is easiest to find talented developers to work on). In other words: you can stick your language wars, I don't give a shit what it's written in so long as it works like this in the browser.

Not only does Template Animation release you from the long term bonds of your technical choices in backend technology, but it shortens the lifecycle of iterations in your product and makes it quicker, cheaper and easier to change the user experience because you can iterate in your static mockup without having to "re-templatify" - that is re-add a bunch of template tags/logic or re-fragment your templates.

Even things like modernising and progressively enhancing your "Web 1.0 application" to be some wonder of modern engineering, single page application with hash bangs out the whazoo would be far simpler when your HTML templates are completely independent of the codebase used to animate them.

Okay smarty pants, but some logic is always required in templates LOL!!!1

In considering the implications of building an application using this method I came up with a few hypothetical scenarios to test the waters and I've narrowed the type of "logic" that you still need in templates to 2 things:

1. Conditionally printing some value to the screen (eg. a form error or different menu items depending on whether the user is logged in or not)
2. Conditionally including some structural element (eg. a sidebar when logged in or a shopping cart if you've added items to it)

The solutions, however, are trivial and require no logic to be present in your templates.

In the first case, you simply include everything in the markup that might need to be there, and the programmer removes whatever is not necessary:

In the second case, the designer/HTML/template guy simply implements two versions of the template and the developer loads whichever is appropriate:

In that second example of course, we've got a bunch of duplicate markup, but that's not our problem. That is the job of whatever system you're using to fragmentify your templates and re-use common assets. Hell, designers don't even have to use the same tools as each other in order for this to work, let alone having to use the same tools as the developers.

What about haml/markdown/{insert markup abstraction technology}

The longer I work as a programmer the less I care for abstractions. This goes, too, for ActiveRecord as an ORM strategy (although that's a subject for a different post) - Joel Spolsky summed up the Law of Leaky Abstractions years ago and I think that's still relevant today.

But if you really want to use some abstraction on the front end that means you have to type less markup or write less JavaScript, be my guest! Just make sure that by the time I'm working with the templates and adding in my logic to them, they're head-to-foot complete HTML documents with no crap in them.

Just the same as our Fragmentify script runs in PHP and allows the HTML guy to iterate on fragmented templates, so too could a simple HAML or Markdown parser allow an HTML guy to iterate with a minimal locally installed environment. Whatever. I don't care. It's all HTML, CSS and JavaScript in the end, the only thing that Template Animation advocates is that the technological barrier between the frontend and the backend is never crossed - that our templates are truly logic-less and that I never have to try and find a freelance designer that is also familiar with Django.

If you've read this far, please don't hesitate to follow Working Software on Twitter, become a fan of Working Software on Facebook and subscribe to this blog via RSS. You can also enter your email address below and I'll send you an email when we update the blog.

Just a quick note to let everyone know about a new website deployment that we're very proud to have been a part of deploying:

http://www.energyforopportunity.org/

Energy for Opportunity is an organisation that focuses on skills and training for building sustainable power generation capacity in remote 3rd world communities.

Working Software supplied Django development services to get the website up and running, and helped with deployment and choosing a web host.

Congratulations to all the team at EFO - we're really impressed by the work they're doing and wish them all the best for the future.

I've been working with the Basecamp API to plugin our IRC bot that we use for time tracking and I'm astounded to learn that escaping single and/or double quotes for XPath queries in PHP does not have a well documented, best practices solution.

In fact, it seems as though this is not peculiar to PHP. I took a look around and found this excellent article by "Kushal" (s/he doesn't have his full name on his blog):

http://kushalm.com/the-perils-of-xpath-expressions-specifically-escaping-quotes

I've produced a PHP solution for the general escaping/concatenation problem:

https://gist.github.com/1155973

Anyone got a better/more elegant solution? I'm always a big fan of code golf :)

I just watched another fantastic TED talk video that Will Franco (a.k.a FlyWheel) over at Jive Systems linked me to a couple of weeks ago.

The video focuses primarily on changing from the "carrot and stick" model of management and incentives and into a "ROWE" (Results Only Work Environment) model for creative, 21st century tasks.

He frames the problem as being one of tasks that involve creativity vs. those that only require "mechanical" skills using a series of experiments done with the Candle Problem.

More specifically, that when 2 different versions of the same problem - one requiring the participant to overcome the problem of "functional fixedness" creatively and the other not - traditional extrinsic motivators either do not work or do work respectively.

About halfway through the talk, however, Pink states that software development is one of the things that can be pretty easily outsourced, and that's where I would disagree.

This reminds me of the famous section of the Mythical Man Month by Frederick P. Brooks, Jr.:

Men and months are interchangeable commodities only when a task can be partitioned among many workers with no communication between them. This is true of reaping wheat or picking cotton; it is not even approximately true of systems programming

This ties in closely with what Dan Pink is saying, but in quite a subtle way. What both Brooks and Pink are describing is a "purely mechanical" task vs. one which requires thought, creativity and communication.

The challenge in building software is that it takes a software engineer to know the difference.

Whilst it's simple for anyone to change the Candle Problem from one that requires creative output to one that doesn't, the process of "removing creativity" from the requirements of developing software is a software engineering task, and one that requires immense amounts of creativity.

In fact, the task of partitioning tasks on a project, particularly for a very early stage prototype, is often so much work that whoever might be doing the work would have been able to do the task faster themselves (and been more motivated to do it a better job of it!)

So think next time you are, or someone you know is, wanting to outsource software development: who's doing the creative tasks?

We created a tag based search engine that is capable of parsing business reviews and turning them into an awesome crowd sourced search engine, called WhatWhere.

Now we just need a crapload of data! We've created a page to collect "recommendations" which are kind of like micro reviews, about businesses in any area:

http://whatwhere.com.au/recommend/

Bookmark the page and help us build the most awesome crowd sourced search engine ever!

If you work in a technical field, there is an automatic stigma about you: you are incapable of communicating technical concepts to the lay person.

Recently I've been putting a lot of thought into communications and how I can improve my marketing material and a big part of that has involved conversations with a wide variety of people about our various products.

I'm also the primary point of contact for any and all support questions from our customers so I spend a great deal of time explaining technical issues to non-technical people.

It started to dawn on me that people were still telling me that I'm being too technical - even when I knew that I wasn't.

How can I tell I wasn't being too technical? Because sometimes people understood. It's not that the people who understood were any more technically competent than those who didn't, and it's not that those who understood were any smarter. It's just that they took the mental effort to think about it for a moment.

So is it just luck then that we manage to catch people when they have time to think? Well, that was my first thought: I just have to increase the number of people I communicate with in the hope that I'll catch enough of them just at the point when they're feeling receptive.

What if there were a way to increase people's receptiveness?

The other day we released our first public beta product based on Decal CMS, Decal Mockups - a live wireframing tool for creating content driven mockups using StackLayout CSS.

The video, the copy - I thought it was perfect. It was, in my mind, the pinnacle of my short marketing and communications career.

I sent out a big email to everyone I knew (and "knew" here is stretched to basically anyone who'd ever sent me an email) and one of the recipients was Will Franco, A.K.A FlyWheel from Jive Systems who specialise in creating and sending video email campaings.

I never heard back from him after that initial mailout but when he sent me his latest newsletter I replied "Hey so what did you think of the release?".

He replied (in summary) that it was wordy and impersonal and not "sticky" and various other things that were certainly not what I was expecting - given that I thought I had really hit the nail on the head with my marketing material this time.

My first reaction was "urr, hold on are we looking at the same page here?", but he linked me through to this video, and watching it changed my whole perception of business, marketing and communications (both personal and professional).

It's a TED talk by Simon Sinek about why certain companies succeed in inspiring, leading and innovating whilst others with the same resources, products and technical capacity fail. If you haven't clicked the link to watch that video yet, here it is in bigger font:

Go watch this video now

One of the biggest take aways from that talk is "people don't buy what you do, they buy why you do it" and Simon really hammers home that point.

There was something else, though, that stuck with me even more - and it's kind of the "slowest" part of the speech where he starts talking about biology and the lymbic system and blah blah blah science whatever (that's literally how I remember that section of the talk in my head) and the conclusion is that people make decisions with a part of their brain incapable of understanding language.

So what is the most important decision people are making when you're trying to communicate with them? They're making the decision to understand you.

Understanding is a decision

This may sound callous, but what this made me realise is that when people tell me I'm being too technical, much of the time what they're saying is "You haven't convinced me that I should take the time or effort to understand you".

They're actually deciding that I'm not worth understanding - and they're making that decision with a part of their brain that cannot be reasoned with using words alone.

This means that you need to start off by convincing the "gut instinct" part of them that what you're about to say (or sell or what they should go to the store and buy right now) is worthwhile to them.

That they had better make the effort to understand/obtain what you're saying/selling/offering them because otherwise the'll be missing out on something amazing.

Obviously the smaller the effort that's required, the more likely they are to make the decision in your favour so yes things have to be easy to use, and you have to use non-technical language and make your products intuitive and all that stuff.

The biggest message that I'm taking away from the TED talk by Simon Sinek is that even if you do all that stuff perfectly there are a large number of people who simply won't take even the smallest effort to engage with your product/business/company.

I think that what he's really saying is that by motivating people and telling them why you're doing what you're doing initially so that they take up your cause as their own, you'll find that people will jump over incredible technical hurdles you never thought possible in your wildest dreams to engage with your product.

Have you watched the video yet?