Hacker News Reader

" I'd expect these devs to implement a feature quickly "

Isn't that basic sin of software development - weighing speed of implementation (which is just a tiny part of the lifetime cost of software) over anything else.

I'm not arguing against 'good enough', I just don't think this is a particularly strong argument for that.

It's like surgeon not washing his hands and sterilizing his equipment because that way implementing the surgery takes less effort.

"lifetime cost of software" means what? 99% of the software we write is obsolete within 2 years. We should not confuse big enterprise, long term support software with modern web development. IMHO, if you want to invest into software viable on the long term, rather spend your time writing functional tests and good documentation so the current implementation can easily be replaced with a new one that uses the then hip framework.

EDIT, to make my point clear: The surgeon comparison is not valid because a surgeon deals with a much longer lifetime than not only the average but most software projects.

> "lifetime cost of software" means what? 99% of the software we write is obsolete within 2 years

More like, developers change jobs that often. So it's no longer your problem.

Personally, I have terrible pangs of guilt if I know I leave a mess behind me. I've had to suffer fixing enough of someone elses messes to know what a timebomb of anger and frustration that is.

Sure, if the software gets totally junked in a couple years then lifetime costs of the implementation become less of an issue.

I work in an environment that's quite lean, but where deployment can take up to a year and lifetime is measured at the decade level so in my case the more traditional 'implementation is 10% of total costs' actually applies.

Given the cost of abandonment and lost sales due to slow page rendering (there's a lot that's been written about that), even a 3% loss of conversions due to slow frontend code over 2 years is a lot of money. For a million-dollars-a-year business, that's upwards 6 months worth of a developer's time.

[0] 3% based on how many people will abandon a page that takes more than 1 second to render: https://blog.kissmetrics.com/loading-time/?wide=1

>> The productivity gained by agreeing on a framework

This is a false dichotomy. This only applies once the developers have real experience with the framework. Throwing a brand new framework at the devs without at least a month to play with it - play, not work! - is doomed to failure. Expecting first-time use of a framework on an actual project to go well is a horrible mistake.

There is a lot to learn with any reasonably sized framework. Making devs use an unknown framework without time to learn it will result in a project that doesn't use that framework properly. Thousands of lines of code will be written... to duplicate functionality the framework already provides, but that the devs don't know exist. The rush of deadlines means that the devs skip reading documentation or researching the "right way" to do every task, and you wind up with a project that technically uses the framework... except that the entire project will be written in a way that someone with previous experience with that framework would never have allowed to happen.

Some frameworks have so much to learn that it's essentially equivalent to having to learn a new programming language. Would you ever expect someone to learn C in a week? Java? Python? No...? Then please don't expect devs to pick up a new framework on the spot with no time to self-train on it.

(I should point out that this isn't a direct counter-argument to the parent I replied to. Just a clarification on that single point. It doesn't apply to most of their comment.)

You are quoting me but I am not sure you are responding to my comment.

>> if they all want to use it - let them use it

>> they use the framework they are most comfortable with.

> Then please don't expect devs to pick up a new framework on the spot with no time to self-train on it.

I never said I did.

Haha. I thought of that and posted a sub-reply, according to timestamps, just 5 mins before you posted this. I read your whole comment, and just intended to clarify that the very act of choosing a framework does not necessarily mean increased productivity, if the devs don't know the framework in question. A tangent based solely off the quoted part, for something I've seen time and time again over the years (new framework, no time to learn it, rushed deadlines).

As an end user, I don't see that the framework craze has any positive impact. Many websites that were highly usable around 2004 have degraded into a bloated mess.

Amazon is an example, but there are many others.

You can build proper apps and not just websites with the help of frameworks.

> And if they all want to use it - let them use it. The productivity gained by agreeing on a framework usually outweighs the performance loss over the "best" solution.

I totally disagree, and not because of performance; choosing a framework based on its performance would be premature optimization. Your argument breaks down here:

> I'll be damned if I make them learn my way of doing things. I'd expect these devs to implement a feature quickly

But that's exactly what a lot of projects using a framework end up doing. Between Ember, Angular, React, Backbone, Dojo, Prototype, and GWT, there is a ton of competition in this space, and you would have a hard time finding a team of professionals who all know the same framework. So at least some of your team will be learning the framework, and that learning will not pay off compared to just using vanilla JS. You can't argue that familiarity outweighs the complication added by a framework because people aren't familiar with the same frameworks.

Vanilla JavaScript is the lowest common denominator: almost everyone is familiar with it.

Good point. Team unity and shared understanding of the methods, I'm all for that.

Personally I consider everything and don't rule anything out. I wouldn't rule out be-spoke is my main argument.

It's just that, you know, life can be more rewarding if you not only aim for perfection or near-perfection, but achieve it. There's a philosophical angle here that may be more suited to the start-ups thinking and dreaming big and original, vs the company who just wants "something that works/MVP".

> life can be more rewarding if you not only aim for perfection or near-perfection, but achieve it

I do that with my own software in my spare time, but from an economic point of view I cannot justify to spend that time when working for someone else. And since projects are always evolving also in requirements "perfection" is a moving target.