[memetherapy]

One thing that surprised me as a latecomer to software development coming from a visual arts background is how much choice of technology and working practices are purely fashion driven. The thing about fashion is that the way if develops is largely arbitrary. Changes in fashion resemble a drunken walk through possible design space with the drunkard receiving regular shoves from "influencers" who are usually trying to sell you something. Occasionally you have a fashion "revival" where someone takes an idea from the past, gives it a new spin, and then sells it back to newcomers as the next big thing.

This seems especially true in the types of startups and companies many HN readers work at or aspire to join / build - that is ones which are low stake / high reward.

I think when you combine the low stakes nature of the VC driven startup world with its cult of youth and the in group conformity of young people this is what you get.

[1] by low stakes I mean no one will die and you won't be prosecuted if your single page app startup goes tits up. Indeed you're supposed to "fail fast" precisely because the cost of failure is so low. Even if a VC or angel has invested a few million in you, to them that's still low stakes because they exist on an entirely different plane of wealth and you are just one of multiple bets.

[2] We're going to rebel by all dressing the same but not the same as our dad!

[qz2]

What I find frustrating is that if you are in a high stake environment it’s increasingly fashion driven too. I am in one of those environments where we can get prosecuted, big time. I tend to opt for a conservative engineering approach with maturity and security considerations being a key part of the design process.

But no, fuck that, someone went to a conference, bought everything shiny and started a death-march of throwing any old hacked up shit and containers from random joes in a limping kubernetes cluster that no one really understand and calling it a success.

That’s reality in 2020 unfortunately. I don’t sleep very well these days.

[bob1029]

I dont understand why business leaders cannot see this for what it is and take back some control. Investors need to start asking more probing questions about how organizations develop and deploy applications. Perhaps if the money becomes contingent, people will start to give a shit about the engineering quality.

At no point should "fun" be a line item when determining what technology to select in a high stake environment.

We are in finance and we picked the most boring technologies we could find. Most of our stuff doesn't even talk to the network stack. I can't imagine running our transactions, with their piping hot PII, through the labyrinthine monstrosity that is modern "best practices".

[qz2]

Problem with investors is that they pay third parties to do audits and third parties are filled with box tickers who ask a load of questions. You can strategically answer any question. So the game becomes how to answer the audit questions effectively rather than an honest appraisal of the situation.

Also it's not really fun. It's a frustration ridden shit show. You spend all day solving complex problems instead of building business value.

A fine example of where the tradeoff ends is spending three weeks solving fundamental networking issues due to stack complexity and immaturity.

[jacquesm]

> You can strategically answer any question.

Good luck with that.

We do exactly that for a living here, we're essentially 5 people who are all CTO grade and have run our own companies. If you can fool us for a whole day you've deserved your investment, but I highly doubt anybody ever got away with that.

[qz2]

There’s at least two layers of indirection and yes I probably could fool you or just blatantly lie.

[jacquesm]

Good for you, it's been tried but so far without success. Maybe you're the exception but I highly doubt that. Arrogance on my part, for sure, but the record on my end speaks for itself (170+ companies looked at to date) and you are an AC.

[tinco]

Because all the shiny new things make promises. From larger talent pools in node.js, to cheaper scaling with kubernetes. They all talk to business leaders in terms they understand.

Also, this is a fundamental property of innovation, innovation usually is made possible by the new and shiny things. I run the software side of a hardware startup, and I wouldn't have been able to run such a complex software system with such a small team if it wasn't for all the shiny stuff. Yes a lot of it is wobbly, but we're also comfortably a year ahead of the established players.

[Aeolun]

> From larger talent pools in node.js, to cheaper scaling with kubernetes.

Larger pools of people, and cheaper infrastructure.

Not necessarily talent and cheaper scaling in my opinion.

[59nadir]

> Yes a lot of it is wobbly, but we're also comfortably a year ahead of the established players.

It's likely that you would be ahead of established players with old, not shiny technology as well. Established players have an inherently harder time progressing in most circumstances and an entirely different maintenance burden in pretty much every layer of their product. Shiny, new technology accounts for much less than people think it does.

[TheColorYellow]

> Investors need to start asking more probing questions about how organizations develop and deploy applications.

Does this even matter though? Shitty technology choices don't always translate to poor business outcomes.

[jacquesm]

This is absolutely true. But shitty technology tends to have hard upper limits to scalability and shitty security tends to put hard upper limits on the company life span. It's interesting how established companies can have one security issue after another but the customers are so locked in they can't leave and so those companies are not nearly as affected as they should be (Equifax anybody?). But your run-of-the-mill start-up would be mortally wounded by such an affair because they still need to sign the bulk of their customers.

Of course it doesn't always play out like that (to every rule there are plenty of exceptions), but investors don't like to be associated with companies that fail or that blow up their reputations either because it makes their exit that much harder or even impossible.

I've seen investors that took the responsible route and made fixing major security issues or other undesirable elements of the target companies a condition to investment and typically these investments succeed in the longer term, not in the least because they cleaned up their act and could then turn that into a USP relative to the rest of the field.

Even so: better invest in a company with a mediocre product and a stellar sales team than to invest in a company with a fantastic product and a mediocre sales team. The first one will get you a better ROI, and tech can be fixed post deal.

[alisonkisk]

What company has been harmed by shitty security on any sort of worrying timescale?

[qz2]

I worked for an online gambling startup that got owned on launch day and the investors pulled out the day after.

Thank fuck I was just a contractor and not a founder or shareholder.

[htormey]

You are totally correct. Beyond a certain level of due diligence it doesn’t matter.

[htormey]

“ Investors need to start asking more probing questions about how organizations develop and deploy applications. Perhaps if the money becomes contingent, people will start to give a shit about the engineering quality”

Why? Most companies fail due to a lack of product market fit not because they picked the wrong software stack. Hence investors time is better spent on company outcomes and not micromanaging whether the backend team is building using Java or Rust or whatever’s trendy.

[nthj]

I see this idea often, and it feels somewhat shortsighted for me. Company outcomes are primarily determined by product-market fit, yes, and: the tighter your feature release feedback loop, the more product-market-fit experiments you can run before you’re out of runway.

Many technology and process choices are just style and preference, absolutely. Others have a material impact on the effort and time to ship a feature. (I’ll leave examples as an exercise to the reader; I imagine any example I used could turn into discussion of “ah you’re doing $FOO wrong.” I suspect this tendency entangles with why these choices seemingly frequently impact business outcomes, from my perspective.)

[htormey]

Well I imagine it’s a function of the stage of companies the VC’s are investing in.

If you are an early stage investor and you are writing lots of checks to cast a wide net do you really have the time to do that level of due diligence? Presumably a quality founding team and a decent demo is enough to tick that box.

If you are a series A or above investor, does it really do anything to provide this advise after the fact?

I image that the assumption is that if the company is successful you can afford to bring in more seasoned people to fix things. At least that’s what I’ve seen on my travels in the Bay Area.

[mjw1007]

As far as technology goes, I think what we describe as "fashion" is often mostly caused by a desire for safety in numbers, and to a large extent that's rational.

If I pick the same language or framework or whatever as everyone else, there's a better chance it won't be abandoned, and when I want to integrate with some other project, someone else will already have done a great deal of the work.

[hyperman1]

Too true. On my job we have frameworks from the Architects, and stuff that drips in from outside.

The Architects typically buy some Framework from a Trustworthy Enterprise, as approved by the Gods of Gartner. Quality varies wildly, but if you move half a mm from the beaten path you're on your own. I gain a thumbleweed badge on stackoverflow every time I deal with their stuff.

Compare it to outside world stuff. Quality also varies wildly, but 5 minutes on Google generally delivers someone who already suffered trough hell for me, and forged some unholy pact with the technology in question.

Unfortunately, neither camp can choose a boring, proven, working technology that exists already a few years and is in common usage.

[afarrell]

If you found yourself using a boring, proven, working technology ...how vividly would you remember that experience?

[hyperman1]

You would have a feeling of trust.

As an example: I click on a browser icon and I get a working browser with a predictable behaviour.

One day, chromium edge took over, messed up a ton of settings,and kept on blathering about my experience. 5 minutes of filling out a work sheet changed to 30 minutes of whack a browser.

My amicable brotherly feelings of good that day did not extend to the average Microsoft employee.

[Aeolun]

My experience using PHP at my previous company stands out because it was so relatively glorious.

[mattgreenrocks]

By the same token, people should stop expecting exceptional results if they used the same tools and processes as everyone else.

[dragonwriter]

> One thing that surprised me as a latecomer to software development coming from a visual arts background is how much choice of technology and working practices are purely fashion driven.

It's not “purely fashion driven”, it's just that (1) as solutions radiate out from their point of origin understanding of the problem, how the solution addresses it, and what caveats the user should be aware of gets (on average) foggier, and definitely more unequally distributed, and (2) there are real network effects in software development where being popular genuinely makes things better, all other things being equal (from a business perspective, a technology for which you can get people that are proficient and comfortable is better than one you can't, other factors being equal.)

[ehnto]

> a technology for which you can get people that are proficient and comfortable is better than one you can't,

Hence why PHP is still the leading language for eCommerce, where fashion gives way to tight margins and hiring talent for a decade long lived piece of software is a major concern.

When cost is the driving factor for most decisions, and ROI is a very real and measured metric, convincing someome to rewrite their money making machine to keep up with the latest in tech is a hard sell.

[dragonwriter]

> Hence why PHP is still the leading language for eCommerce, where fashion gives way to tight margins and hiring talent for a decade long lived piece of software is a major concern.

I don't think the forces that resemble fashion are any less applicable to e-commerce.

> When cost is the driving factor for most decisions, and ROI is a very real and measured metric, convincing someome to rewrite their money making machine to keep up with the latest in tech is a hard sell.

Convincing people to rewrite systems without (and even often with) changing needs that the old system seems to brittle to accommodate is hard everywhere, even when ROI isn't clearly measurable; that's why so much established software in government (as well as other places) still runs on COBOL.

The shifting preferences in development that look like fashion are evident, even in those domains where there is lots of established software that is sticky, in greenfield development.

[ehnto]

> The shifting preferences in development that look like fashion are evident, even in those domains where there is lots of established software that is sticky, in greenfield development.

Definitely agree, greenfields projects are where you get an opportunity to suggest new technology.

What I find in eCommerce though is the people who make the decisions on this stuff move around from company to company like pollinating bees, and they always want what they had before, which is often WooCommerce. It's a matter of user interface and ecosystem. They don't care about the merits of the technology underneath, it's truly not a concern for them, what they want is to be able to load up the Yoast SEO plugin and check their copywriters work, or have their in house guy make popups with whatever popup maker they had last time.

I think that's why it's so hard to kill it off.

[ehnto]

I got some downvotes for this, but look at the numbers. I'm not saying it's the best language for eCommerce, but it is the workhorse. It's the old beige cash register in the corner bodega that's still the heart of thousands of businesses. These businesses don't have the margins to replace their Magento or WooCommerce shop, hence the need for pragmatism. If you're thinking about Shopify or AWS this or that you are already thinking about the wrong part of the industry.

[tannhaeuser]

For a latecomer, you've managed to see through a lot of bullshit, and the psychological/sociological nature of it. What you're maybe missing is that's not always been like that. Cloud, SaaS is only a thing since around 2006 when AWS hit the scene big time. Before that, we had a relatively conservative, standards-driven perspective on progress. Maybe it's also the time when the generation having learned computing from the ground up (assembler, C, hardware hacking) was starting to fade from the job market, or rather the then-new devs became eager to carve out their niche with arbitrary abstractions (but not entirely - I remember OOP bullshit from early 1990s and WS-* SOA crap from 2000s).

[wott]

The abstractionists, philosophers, theoreticists, had their days before too (60s-70s Lisp, 70s-80s Logo for teaching children). So in fact the practicalists would only have ruled in and around the 90s.

If we add all the "everything is a XXX" languages (XXX in [list, string, object, function ...]) and gather all simplificationists together, then they almost always were there, with fluctuant success at being prominent.

[p_l]

A lot of those "abstractionists" you mention were very heavily practical, too.

1980s and 1990s gave us "decision made by senior management reading shiny magazine during flight", we just look back with sentiment now combined with survivor bias.

[0x445442]

It's an astute observation, especially if you have not heard Alan Kay's thoughts on the subject. He calls our industry a Cargo Cult and explicitly compares it to fashion and pop culture.

Keeping with the anology I'm sure there are software engineering equivalents to Jeans and T-Shirts and it would be an interesting study to compare organizations that opt for these fashions to those that do not.

If you're reading PG, it seems like a great topic for an essay.

[grishka]

As a software developer since my early days, I wholeheartedly agree with you. It's honestly ridiculous to see how people invent "revolutionary new ways" of doing the exact same thing that could be done in a dozen ways already. And they invent those by piling more and more unnecessary complexity on top of existing technology stacks.

Electron is a revolutionary new way of making desktop apps. Except they look like they're something else and take up all the RAM you have and ask for more. But nah, you don't understand, it's the future, native desktop apps are dead.

Kotlin is a revolutionary new JVM language that will solve all the problems you had with Java... Except I haven't had any. Java is simple and predictable. Kotlin is not. To me, Kotlin feels like an abstraction layer that gets in the way. But people will be defending it relentlessly because that's what Google says is The Future™ for Android development.

Web development... That's just nasty. "Revolutions" happen every day, so now your news article takes 5 seconds to load on a 100-megabit connection just because someone absolutely had to make it a react app instead of a server-rendered page with just text and maybe some pictures.

This overall trend of abstracting the platform (the operating system, the web browser) away is abysmal. It does no good. And lowering the barrier to entry to programming? Honestly, I'd rather prefer it to remain high. Programming is meant to be an engineering job, not the kind where you throw stuff at the wall and see what sticks and just assume that browsers and operating systems are made of unicorn jizz.

[monsieurbanana]

Half the threads on hn mention that software engineering was never engineering, so which is it? Or maybe you're the exception to the rule?

Sarcasm aside, that ship has sailed You can't have internet as widespread as it is today while keeping programming in the hands of the very few "true engineers". So either you're arguing the past 20 years of internet progress was a mistake (fair enough point of view) or you're deluding yourself.

[grishka]

I'm not sure I want the internet to be as widespread as it is today. I certainly don't want it as commercialized and as centralized as it is today.

I also take issue with this whole dumbing down of technology that's been happening over at least the last 10 years and shows no signs of stopping. It's understandable that there are certain business entities that would prefer to be in possession of as much money as technically possible, and to achieve that, they need to give their products into as many hands as possible, which means said products have to be "easy to use", aka don't require reading manuals and understanding what the damn thing is actually doing.

Computers and other computer-like devices like smartphones are, ultimately, tools. As are the programs they run. And tools are meant to serve and empower their end user. 99% of the IT industry, unfortunately, would rather like them not, because that clashes with their own interests they for some reason are allowed by the society to have. That's all I have to say.

[deanCommie]

You made some bold statements without any details.

Kotlin to me solves most of my Java pain points. In what sense is it not predictable?

Electron allows a company with web developers to be able to build cross platform desktop clients without hiring desktop developers. That's incredibly compelling and powerful regardless of the compromises with the final product for the end user. (which are not guaranteed. Something like VSCode is indistinguishable from a rich desktop client)

[noir_lord]

I agree with pretty much your entire point.

In addition it sets up a situation of constant tension because many developers refuse to follow the fashion when they can (justifiably) say that the way they currently do things is perfectly fine.

The people on the edge of the fashion then regard them as absolute dinosaurs because they refuse to follow the trends.

Then there are people like me - I watch what is going on but I don't follow the fashions, I maintain a list of "that looks cool, check back in 18-24mths and see what they did" and then make a decision on whether it's worth spending more time actually looking at something.

https://i2.wp.com/www.business-to-you.com/wp-content/uploads... on that graph I'm a pragmatist.

Been bitten by the shiny a bit too much at this point in my career.

[1337shadow]

True story: last "AWS Solutions Architect" I met told me "AWS is a sect and I am part of it", I'm still not convinced it was meant as a joke!

[qz2]

There are a lot of religious followers of the one true AWS way of thinking. I dared bitch too loudly about SES delivery policy once and said to look elsewhere and earned the ire of the architectural elite.

This is insane because I'm certified too but a non believer, a concept which does not compute for a lot of people.

[Aeolun]

You don’t believe in AWS? Or not in SES, because I feel like they still win in general ‘want to recommend’.

[qz2]

I don't believe in anything past 100% portable IaaS platforms. Within those bounds, careful application of AWS is fine.

[blablabla123]

It's a fine line to use recent frameworks and at the same time to be productive and actually solve problems. That's ultimately why good frameworks are developed. When React came out many called it a fad but it solved really nasty problems in Web development, that's why it stayed. Also I'm quite sure K8S is here to stay because it removed this whole VM complexity layer and makes integration and testing of services a breeze. On the other hand there are fancy frameworks that don't solve such problems or the understanding is not good enough (yet) to solve them reliably. IMHO a lot of web frameworks that promised in the past to remove the boundary of frontend and backend suffered from that. Also the early NodeJS ecosystem to some degree.

It's fun to use a framework, get to it's boundary preventing you from getting things done and then discover a framework that actually crosses that boundary. Speaking of server-less, I never came into the situation where it would have made things easier for me so I never used it but YMMV...

[tatersolid]

> Also I'm quite sure K8S is here to stay because it removed this whole VM complexity layer and makes integration and testing of services a breeze.

Kubernetes does basically nothing to assist in integration or testing of services, and adds more complexity than the “VM complexity layer” ever had.

[blablabla123]

I don't think so. In the average company running VMs themselves, the person managing the VM is a different person that runs stuff on it. Even in < 5 people tech teams. And Enterprise-grade VM management software is completely out-of-scope for any dev person for that matter. Chances are I will never even know any details about the real hardware it runs on.

K8S is a different story, it can be managed by a devops team (or a really engaged dev ;)). VMs virtualize your network interface and can take care of some IP routing, K8S can route HTTP traffic and TLS-terminate it. It facilitates being aware of other services and multiple instances. Basically it's possible to get rid of nginx. And most importantly it runs the containerized applications basically on bare metal. Spinning up a test instance and destroying it 1 minute later is cheap, any dev can do it.

[jjav]

Sadly yes, it's become a very fashion-driven industry.

Much of it is driven by the near-complete lack of historical knowledge of the field. I advocate that a computer science or software eng curriculum strongly needs a semester or two of the history of the practice. What roads have been taken in the most important areas and examine all the dead ends and why they were abandoned.

So much of the new-shiny is just a badly implemented rehash of ideas that we already know didn't work out in the past, if we only knew. Because we mostly don't, as an industry, it seems like an exciting new idea.

[mattgreenrocks]

We don’t teach people a technical aesthetic. So, lacking a strong internal sense of taste, they cargo cult it from the latest FAANG scraps thrown at them. This compounds with the conceptual disaster that is web apps.

The good news is there’s a lot more to software dev than webdev.

[agumonkey]

This is something that annoys me, exhausts or worse. The amount of time wasted on bikeshedding and chapel wars is draining. I appreciate craft a little more because tooling and practices are more stable. You focus on work and not how to work.

[sjg007]

Keen observation. I enjoyed Halt and Catch Fire because of its parallels to today. A lot of previous startups had good ideas just the tech wasn’t quite right or v1 at the time.

[AlexandrB]

And just like fashion, what's "in" is driven by marketing.

[jacquesm]

It's not the cost of failure that is so low, it is the cost of hanging on but not ever taking off that is so high.

[ketamine__]

I'm going to play devil's advocate here. A sleepy engineer wakes from their slumber when a new technology takes hold their mind. They find new ideas exciting and intoxicating. And sometimes that energy can be infectious and makes the entire development process more enjoyable for product owners and QA.

There needs to be a balance. For example, upgrade to the latest version of Rails. Upgrade previous file storage gems to active storage. Upgrade the deployment process.

There are many exciting things to improve in a monolith.

[gabordemooij]

This. Devs nowadays seem to be just NPCs, they jump on every bandwagon, it's very depressing. But this is the same with rest of society, groupthink is becoming a real problem. Unwanted opinions, thoughts are scrubbed everywhere.