Things You Should Shout at Brilliant Web Developers | Hacker News Reader

Things You Should Shout at Brilliant Web Developers

blog.jonathanmarkwell.com

52 pointsjot49 comments

> How dare you assume that your competitors have the time and skill to copy you.

Unfortunately your competitors don't need your skills to copy you; once you make your thing public, everybody will see how to do it and copying your product becomes trivial. But the good part is that only successful projects are copied, so you really shouldn't worry about it -- when people start copying you, it means you are on the right track.

Have you ever worked on a rebuild? Copying is surprisingly hard, almost never trivial. Check out how bad Rocket Internet's products are compared to the services they copy. They are pros at copying and still they can't get it right.

People copy when they know it's worth the risk. That's why successful projects are copied. I agree with you that it is a very good indicator that you are on the right track. :)

Sometimes this is true, but many products are trivial to copy, like Instagram, or twitter. Most of us here could probably copy either of those in a weekend or two.

Copy basic functionality perhaps.... I doubt the majority here could scale nearly as effectively as both of those companies have....

I don't know. Scaling as effectively as Twitter doesn't seem like a particularly high bar. They spent a year or so after they got big being down almost as much as they were up. The "fail whale" was just about the most common thing to see on twitter.com.

Of course, now that Twitter is established, you cannot repeat their mistakes if you want to succeed.

Relevant[1] front-page discussion.

[1]http://highscalability.com/blog/2013/7/8/the-architecture-tw...

Plus there's a degree of polish and stability that takes a few months to hit.

Is there a single example of a service which failed to scale? Once you have user growth, you can get investors to fund scaling regardless of the technology choices made the beginning.

That might be true in the case of the first version of Instagram and Twitter. It was probably far from trivial once they had significant traction. Why do you think no one copied them at the early stage?

You'd think that Twitter with all their resources could have copied Instagram in a snap. Instead, when he saw the product and the traction, the founder of Twitter invested in it. He then got upset when Facebook brought them and is only now copying them.

If they are so easy to copy, why are well all using Instagram and Twitter and not one of the many copies?

There's more to a business than the code of its products.

I always feel that the most difficult part of any project is its design, the implementation is rarely difficult. By design I mean both the conceptual design (data model, user flow), and user interface design. It takes a lot of time to come up with ideas how to tackle a problem. Then you implement them, realise it doesn't work, and start over with a different approach.

All this design work isn't necessary when you copy something. Someone else has already done the design work for you. You can lean back and say: "The solution is obvious." Then you only need to implement it. In my experience, the implementation always seems trivial in comparison to the design process.

But you are right, people who copy stuff often make poor copies. I think the problem is that they probably don't fully understand your design. They see how you solved something, but they don't understand why you solved it that way.

Finally, I don't think a rebuild is the same as a copy, because you generally only rebuild when something doesn't work. And then you actually need to put a lot of design work into the rebuild process -- that's why it's hard.

These are great points.

Most developers I know find that the most difficult part of product development is sales. Design is also difficult but I'd recommend treating it as a process rather than a project when it comes to new products in new businesses. Design will never be done and it can always be improved, copycats will always be two steps behind or they'll fork into a different direction.

I know of financially successful products where the teams behind them don't know why the design they have works. They've even had situations where they've improved the design in their view and it's been well received in user testing. But when they release it, it has a negative impact on sales, retention or some other core metric. Imagine trying to copy a counter intuitive system like that?

If you have something where the core value is obvious and can be copied with ease you've probably released too late. Even in that case it would be pretty impressive if your marketing was so good that it found someone who could copy it. After removing the design part there are still very few people in the world with the time and resources to focus on building a copy right now. I'd guess that most people who think about copying will more likely become very good customers of yours, they can then have more time to work on their own ideas.

> But the good part is that only successful projects are copied

Or products that are so brilliant that it's immediately apparent they'll be successful

Have you seen one of those products before? If so why did you not copy it?

I have seen numerous instances of such products, but whether and why I personally did or did not copy them will only tell you about my nature and my temporary circumstances - it is not a proof of whether good products are more often copied.

You're right, it is not a proof. But in my experience there are very few people who are both smart enough to spot opportunities to copy and have the time to do so when they see them. I'd go as far as to estimate that those people are 1 in a million. If even half a million people discover your early stage product someone copying you will be the least of your worries.

Agree with you for sure. But while it's certainly not a likely thing for any one individual to do, the number of people on the planet working in tech makes it something that happens quite often really. That's my experience, at least.

Compressing all the questions into one: "How dare you want to be a web developer instead of being a businessman?"

Well, being a businessman sometimes makes sense.

But usually I deliberately pick being an engineer and not a businessman. Doing business takes a different mindset and a lot of time; it's not easy to do both, and often not fun.

This is a great observation.

If the title of the post was longer it would have been "10 Things You Should Shout at Brilliant Web Developers Who Are Building a Product for Financial Independence"

Once you have financial independence or don't want a product of your own you don't need to be a business person.

The great thing is, once you successfully get past this ugly bit of doing business you can start ignoring this advice and making products that are better in your eyes.

Kudos. Very important distinction to make.

It took me a while to convince myself that this wasn't a joke. Obviously, nobody wants to ship a crappy product, and obviously if you insist on perfection your product will never ship. Deciding when a product is "good enough" is a judgement call.

Shouting "how dare you" at people who disagree on this judgement call is just stupid.

I probably failed to set the context. :)

I felt an extreme position was needed to respond to brilliant but highly principled people (who I wished were joking) but I felt were saying things like:

"How dare you suggest that I would ever ship a product that won't work with JavaScript turned off."

"How dare you suggest that I would charge for something that doesn't even have feature X."

"How dare you suggest that I would ever let a design loose that I hadn't spent 6 months refining."

"How dare you suggest that we shouldn't spend the last of our savings before we launch finishing the product."

"How dare you suggest that I would ever ship a product that wasn't web standards compliant and passing every accessibility standard."

Maybe I should write a joke post that uses some of these?

> "How dare you suggest that I would ever ship a product that wasn't web standards compliant and passing every accessibility standard."

As long as some web developers feel that accessibility is optional, even for a minimum viable product, they will continue to discriminate (howver inadvertently) against some users. In some cases, these users will then be barred from completing some task that is required, because they can't use a particular application, e.g. an application that's required by a particular job or course. Please don't contribute to this problem by suggesting that accessibility is an optional nice-to-have. For users with disabilities who need to use a particular application, it isn't.

It makes me very happy that I am never going to convince people like you that accessibility is optional. I can't convince myself of it either when it comes to profitable products.

We need more people like you running profitable businesses and ensuring that it is never optional in the (misguided) name of lower costs and more profits.

Unfortunately when you build an MVP for the 100% you build it for no one. If accessibility is the most important thing for you then make your product and therefore your MVP for with people with disabilities as your primary audience. I would suggest a much narrower focus than that as its sadly far too big a market to start with.

EDIT: improve phrasing in a couple of places; link to a better blog post to make my point

I'll try to be less confrontational in this reply.

It seems to me that you're setting up this false dichotomy: either developers working on MVPs can ignore accessibility because 90% of people have no significant disability, or they can try in vain to make an MVP for 100% of people. Of course it makes sense that one can't do the latter; when developing software in general, but an MVP in particular, one has to pick and choose which categories of users to target. One has to choose which features to implement and which to leave out or save for later. But it still seems wrong to suggest that one can ignore a set of potential users who might be a good fit for the application in every way, but happen to have a disability through no choice of their own. To get an idea of the consequences when accessibility is ignored, check out this blog post:

http://blindaccessjournal.com/2005/02/opportunity-lost-to-te...

Maybe I'm just too close to this particular issue. after all, I'm visually impaired myself, and my boss and most of my coworkers are totally blind. Nonetheless, I believe that accessibility shouldn't be a nice-to-have feature, but something one just expects to be there, like security. A commenter on another sub-thread pointed out the absurdity of suggesting that a developer can ignore security even for a prototype. I think the same holds for accessibility. Browsers, toolkits, and frameworks can do a lot to make it more likely that an application will be accessible by default, but I think that as with security, some level of consideration from the application developer will always be necessary.

Agreed about "people with disabilities" being too broad a market to focus on. Too many different disabilities. Where I work, we focus on making our software maximally usable for blind people.

No worries. I was confrontational in my post.

Let me clarify: I'm not saying MVP (or pre-profit product) developers should ignore accessibility. I'm saying they shouldn't spend too high a portion of their time worrying about it. If a product fails some measure of accessibility it has a bug which will need to be fixed at some point. Just because it's a bug that you are aware of and it's easier to detect than other bugs doesn't mean that it should stop you from trying to sell the product. A buggy product with some income is more likely to succeed than an apparently bug-free product and no income.

I've worked with blind coworkers in the past and have tried using screen readers myself so I have some appreciation of the challenges. Thank you for the link, it's always good to have a reminder. It sounds like the employer in question and Siebel should have had legal action taken against them. They're both clearly of a size where they can and should be doing better. This is another example of why we need brilliant web developers building businesses that can destroy backwards companies like those.

How do you get on with Hacker News? I just put it through a checker and it appears to be pretty appalling. Would it be better if pg shut down Hacker News completely until the issues it found are resolved?

Great post. I think a similar issue is when an engineer feels they need a certain set of infrastructure or algorithmic features before they can start building their program. If you end up finding out that most potential users have a different problem though it can all be for waste. I've met many programmers who seem to have forgotten (or never learned) how to prototype, and can't imagine building something with a fundamental security or scalability flaw.

There's also a far more difficult one to become aware of, which is building an overly complex solution when a simpler one exists for the problem.

Very true. It's not just in the name of 'design' and 'user experience' perfection that developers overly delay their first product.

I can see passing on scalability, but security? In what circumstances does it make sense to build something with a fundamental security flaw? Getting security right doesn't have to take significantly more time than getting it wrong.

>When you spend weeks or months perfecting your product in the name of 'user experience' or 'design' before selling it, you are doing more harm than good for your users and yourself on your quest to be financially independent

Some of us are serious about delivering quality. You are trivializing 2/3 of the web application right there. If it looks like shit and confuses people, no one is going to use it, unless it meets a serious pain point and has absolutely no competition yet, which, is not the case for most of us.

What if it turns out that most people are building the wrong products?

Sometimes the wrong product is a low quality product that does X and the right product might be a high quality product that does X.

Today there is a great market for aluminium and glass mobile phones. I wouldn't recommend going into that market if you have limited financial resources.

If the first, second or third developer of mobile phones made them out of aluminium and glass rather than plastic do you think they would have been more successful? How about if they gave them away for nothing, or with a total return less than cost price?

If you want quality to be your differentiator, you need to already have easy access to a proven market for your core product.

This applies if you are building a product which is so groundbreakingly new that nobody has any expectations for quality level yet.

These products are very rare compared to those which are an evolution of an existing concept. Even with other differentiating factors you are going to struggle to sell a product which has a perception of being below par in terms of quality.

It's your perception of them that they are evolutions of an existing concept.

If you speak to customers it's surprising how groundbreaking they feel very simple things are.

Competing on quality isn't yet as important on the web as many people in our industry seem to think. Just look at all the crapy project management, time tracking and build your own website tools out there. Many of the ones you think look bad and are poorly built have customers that love them and profitable businesses built on them them.

I want quality to be a more important factor in web products but the only way that's going to happen is for more brilliant web developers to be running them. Once they have profitable businesses they can switch to putting quality first.

The bar for time tracking/project management and website construction applications is very high. Many are launched but most fall into obscurity. Why would I want to buy a rushed out the door project management app when I can use basecamp?

Web products is not really a homogeneous category either and spans everything from social networks to specialized applications for industry.

You and I might choose Basecamp but it's amazing how many people refuse to use it for silly reasons like "It doesn't have gant charts".

Many of the competitors that have launched and have fallen into obscurity from your point of view are actually generating healthy profits from a few thousand customers in an industry you don't know.

There are huge opportunities for brilliant web developers to release a first product, or version of a product, in an obscure market and use the profits to build something amazing with wider appeal.

The opposite perfect is imperfect, not "looks like shit and confuses people". I daresay that even "quality" products are imperfect.

People who are serious about delivering quality are brilliant. I want people like you to have a proper chance at doing what you do sustainably. That way the world will have less bad products built by people who are only good at sales and marketing. Quality is very important and very hard, but it is not 2/3 of a web application. At best quality is 1/3 of a web application, with 1/3 core functionality and the final 1/3 sales and marketing.

When your product is not profitable you need to let your customers decide if it looks shit and confuses them. You'll know it's ready when they pay for it and keep paying. I want people to stop leaving it too long before measuring that by giving people the opportunity to buy. Too often developers leave it too long and don't have the time, money and energy to invest in all the things you also need to get right.

Isn't there a risk that releasing a product too early could cause a negative first impression and by the time you have gotten around to improving it, everyone has lost interest?

Also quality is something which is difficult to define and pin down, and will also vary depending on the product.

For example , a backup solution which blows away everything else in terms of innovation and usability but corrupts my data 1% of the time isn't going to get bought. And even if they fix the 1% corruption bug I'm going to remain skeptical for a very long time.

Yep,

The negative impact of releasing an unfinished project is almost always enough to make a developer wait until their product is finalized.

Most intelligent people realize that they are most likely not the MOST intelligent person in the world; therefore releasing an incomplete product, when they unsure of a final release date, only opens them up to the risk of being copied and outdone.

Yes there is a risk but it is very small, particularly for the sort of products that web developers build. This is why you should not do all singing all dancing PR launches too early, releases are different.

If you do a big PR launch too early at the very least you'll close down a channel (e.g. TechCrunch readers) at worst everyone in the web startup industry will have heard about you.

The most successful products have people that both love them and hate them, you can't make everyone happy and you will loose some customers to unfortunate experiences. Fortunately the if you've chosen a good market there are probably more customers than you can ever hope to find out about you.

  > Isn't there a risk that releasing a product too early 
  > could cause a negative first impression and by the time 
  > you have gotten around to improving it, everyone has 
  > lost interest?

Let's say that the per customer cost of your sales cycle doubles each time you engage that customer. This may not be a problem if:

  * you have a large market, and there are plenty of new 
    potential customers.
  * the cost of your sales cycle is really cheap, i.e. 
    low-touch, online sales.

So if you have a small market that's expensive to sell to, make sure you've got all the details worked out in advance.

Why is this specific to web developers? All ten things are applicable to anyone selling a product.

It doesn't have to be. That said if I made it more abstract the result would likely be less web developers reading it. I've met more web developers that need to hear these things (probably because I spend more time with them than other people building products).

Thanks. I just thought people other than web developers should read it too. It's a great list of thought-provoking questions we should all ask of ourselves.

Very happy to hear that. Please feel free to re-write/copy chunks of it for another audience, all I ask is that you link back to it :)

Someone shipping a physical product does not have the luxury to ship a half-baked, bare-bones first version and upgrade it in 6 months for every customer with a click of a button.

Great post, Jon. I real all these "How Dare You" statements as exhortations for developers to question perfection. That questioning is useful, maybe even necessary. Questioning default assumptions is powerful.

Reply on news.ycombinator.com