
Things You Should Shout at Brilliant Web Developers - jot
http://blog.jonathanmarkwell.com/587493
======
jakobe
> 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.

~~~
jot
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. :)

~~~
hnriot
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.

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

~~~
mikeash
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.

~~~
ZoF
Relevant[1] front-page discussion.

[1][http://highscalability.com/blog/2013/7/8/the-architecture-
tw...](http://highscalability.com/blog/2013/7/8/the-architecture-twitter-uses-
to-deal-with-150m-active-users.html)

------
nine_k
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.

~~~
jot
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.

------
gweinberg
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.

~~~
jot
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?

~~~
mwcampbell
> "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.

~~~
jot
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.

~~~
mwcampbell
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...](http://blindaccessjournal.com/2005/02/opportunity-lost-to-technology-
inaccessibility/)

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.

~~~
jot
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?

------
casual_slacker
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.

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

------
readme
>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.

~~~
jot
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.

~~~
jiggy2011
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.

~~~
ZoF
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.

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

~~~
jot
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).

~~~
pdog
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.

~~~
jot
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 :)

------
grasuth
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.

