Yes but the problem is that engineering projects tend to consist of two halves. There is the first 90% of the work and there is the second 90% of the work.
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...
Not exactly the definitions Brooks used, but memorable and in my experience surprisingly accurate.
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.
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.
"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."
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.
Now if 90/90 is accurate because of unknown unknowns, or just because we are all terrible at estimation and planning is debatable;)
While both come from religion, an evangelist is not the same thing as a theologian.
- 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...
Is there any logic to this exceptional world?
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.
This was instrumental in developing desktop publishing industry.
I agree the term is dated and should be retired.
And they buy things. But I agree that marketing would be a better term in many cases.
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.
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.
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.
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.