Can we start calling "evangelism" "sales" again, by the way? Someone who calls themselves an "evangelist" is a salesperson, or someone who studied theology.

> Someone who calls themselves an "evangelist" is a salesperson, or someone who studied theology.

While both come from religion, an evangelist is not the same thing as a theologian.

> evangelist

- religion: a person who tries to persuade people to become Christians, often by travelling around and organizing religious meetings

- opinions: someone who often talks about how good they think something is, and tries to persuade you to have the same opinion

- religion: one of the writers of the four books in the Bible about Jesus Christ

https://dictionary.cambridge.org/de/worterbuch/englisch/evan...

And yet they omit Lawyers in front of juries and Lexicographers writing the next edition of a dictionary.

Is there any logic to this exceptional world?

Yes, but it's fuzzy.

That asserts that the degrees of truth in fuzzy logic relates to paths and that asserts paths are fixed. A form of lazy computing when resources are finite for a reason, and nullifies the existence of quantum physics.

People who are paid to have an opinion don't count.

For me, at least, sales implies a commercial offering.

You could argue that "sales" just means "I'm trying to sell you on (using|supporting|believing in) this thing", but I think evangelism is a more suitable term in a non-commercial context.

Evangelists are selling themselves while promoting something.

My perspective Guy Kawasaki was the first tech exec. with that title at Apple. His job was to figure out what different groups of users were doing and what they needed.

This was instrumental in developing desktop publishing industry.

I agree the term is dated and should be retired.

Not the same things : Sales goal is to get listener's money. Evangelism goal is to convert listeners into new supporters / enthusiasts.

"Evangelism goal is to convert listeners into new supporters / enthusiasts."

And they buy things. But I agree that marketing would be a better term in many cases.

I evangelize the concepts of open source and avoiding giving up your data. Meaning any time I think it's topical and not annoying, I spout the opinions and the reasons for them.

As far as I can tell I have no "buy things" motivation. I am not trying to get my sister in law to hire me to install and maintain an asterisk phone system or an instance of nextcloud or add a custom feature to vlc etc. Nor do I do those things in general where I would benefit indirectly if more people wanted those services generally.

There's a difference between someone who genuinely believes what they are evangelizing, and paying marketing people to spread some corporate opinion.

The OP is referring to the second type I think.

Of course the two are not mutually exclusive, you could have an evangelist job for an open source company selling data protection software/services for example.

Its the same things, they are just selling the concept and the product, not just the product.

Software theologians are called “architects”.

What, you don’t want to spread the good word of our lord and saviour… software???

From the title I thought this article was going to be advocating for stopping at 90%. I was thinking to myself that makes pretty good sense, I could get through twice the amount of projects .

Agree. If projects regularly achieved 90% of what they set out to achieve, that would be fantastic. My experience is that 40% is more typical, for the ones that aren't canceled before they deliver anything.

worse, it's not a cohesive 40%, but a long tail percentage complete of numerous features: 90% of feature A, 67% of B, 1-30% of countless more...

I think we can all agree on the fundamental truth that taking out the 90% of the software system leaves you with the 90% of the software system.

It's a bit like the Pareto principle. 20% of the work takes 80% of the time.

Yes, it's the 90-90 rule. It has its own Wikipedia entry: https://en.wikipedia.org/wiki/Ninety–ninety_rule

"The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time."

I always knew it as the 80/20 rule :D

That’s the Pareto Principle.

https://en.m.wikipedia.org/wiki/Pareto_principle

So is 90/10.

read the thread again; it's the 90/90 rule.

The wikipedia page for the 90/90 rule quite literally says “not to be confused with the 90/10 rule”.

Strange, I knew a less humorous (and, I think, more useful and realistic) rule:

80% of the work is completed in 20% of the total development time; while the remaining 20% of work consumes 80% of the time.

And this is something I've seen again and again: the large, most impactful features and architecture of a system are designed and implemented fairly quickly; it's the many small details get forever to be defined and implemented accurately.

The 90/90 rule captures the notion that (programming project) estimates are wrong, in addition to the Pareto principle.

Now if 90/90 is accurate because of unknown unknowns, or just because we are all terrible at estimation and planning is debatable;)

Indeed.

It's the curse of open source projects. So many projects get to the point where it sort of works, and then the authors, having done all the fun stuff, get bored and quit. So the project never reaches the Just Works stage.

If the software endures long enough, there is no 100%. The Just Works stage is not stable. The ground keeps shifting beneath your feet.

Many open source projects go directly from Sort of Works to Abandonware, never having reached Just Works.

I remember reading an essay by Brookes, where he makes the distinction between a "program", which can basically only be used by the one who wrote it (or with their help); a "product", which can be used by anyone; and a "system", which is more general-purpose and reliable. His point was that the first is fairly easy for one person to do in their spare time; the last often takes years of polish, debugging, extensions, and so on.

And for academic work in particular, going from "prototype good enough to get numbers out of" to "product someone can reliably use" is a huge amount of effort, along which there are zero papers.

EDIT: Here's a summary:

A program is just a set of instructions that seems to do what you want. All programmers say "Oh, I can easily beat the 10 lines / day cited by industrial programmers." They are talking about just coding something, not building a product.

A product (more useful than a program):

* can be run, tested, repaired by anyone

* usable in many environments on many sets of data.

* must be tested

* documentation

Brooks estimates a 3x cost increase for this.

To be a component in a programming system (collection of interacting programs like an OS):

* input and output must conform in syntax, semantics to defined interfaces

* must operate within resource budget

* must be tested with other components to check integration (very expensive since interactions grows exponentially in n).

Brooks estimates that this too costs 3x.

A combined programming system product is 9x more costly than a program.

https://www.cs.usfca.edu/~parrt/course/601/lectures/man.mont...

The way I've explained this to coworkers and stakeholders is, "A prototype costs 1x, a product costs 3x, and a platform costs 9x."

Not exactly the definitions Brooks used, but memorable and in my experience surprisingly accurate.

3 is far too small.

Agree. 10x at each stage is more realistic.

I've built a few products from idea to commercial software, and IME Brooks was being generous, as anecdotally I always pegged it at closer to 4x, but then I'm slow. It's actually really surprising how few product managers (forget about developers!) don't seem to know this, yet they also tend to push out the initial release way too far, so you get half a product late, then move on to the next thing.

IME 10 lines of code can easily take 1-2 weeks, if you include all that. I agree that's a bad average time, but I'm assuming other work responsibilities, and perhaps more red tape than HN is used to.

I've found it to be 100x

What I can get running in a weekend for my personal use would:

- take 20 days (10x) to turn into something that other teams in the same company can easily consume without much effort on their part

- take 200 days to turn into a public facing product that people would actually use instead of their current thing

IMO, this is why engineers so often look at products and think "Oh, I can build that in a weekend"

I've created plenty of toy languages and reactive UI libraries in a weekend. People may find inspiration and take some ideas from my 2 days of work but nobody is going to use those as a replacement for their current thing without the next 198 days of effort.

A small example: if you can create a "spreadsheet to website generator" in a few hours, it'll be a month before you've built it out enough to launch a product around it that will attract users.

I think this tracks very close to my experience.

In 10 hours, I can make something that looks starts to look valuable to my wizened eyes. This is the happy path.

In 100 hours, I can build something that the rest of my team can begin to see the value in. This is the MVP.

In 1000 hours, I can make something that I can actually sell to a customer - but only with clear expectations that there may be months or years of on-going polishing required. The is the beta.

In 10000 hours, I was able to learn this perspective. No product is ever done. You only ever get to that tenuous beta phase and then becomes almost entirely about dealing with customer feedback.

For me personally, I start to check out after the 100 hour stage of development. Tedium and repetitive concerns begin to leak in and tempt the strategic nuclear problem solving facilities with insane overkill solutions (aka abstraction hell). I now try very hard to find reasonable handoff strategies before I get to that point. There are other team members who cannot stand the indeterminism of the 0-100 hour range of development, so this works out really well in our shop. Setup the pattern, let the tool operator zone out for the duration of their shift. Not everyone wants to be ivory tower architect and can find far more joy in the simpler tasks.

Thank you for saying this. I'm currently in the 100h phase and I'm struggling to explain it and you said it beautifully.

You can use divide and conquer on that!

The first 90% is work that is composed of 90%+90%. And the second 90% too.

So you end up with .9*(90%+90%)+.9*(90%+90%).

Oh wait.