Hacker News Reader

Comment by deltarholamda | Hacker News Reader

You know how, during a big programming project, you have to keep the devs from going "this codebase has a lot of technical debt, let's rebuild the whole thing using Rust and Kubernetes and Deno and move the hosting to Azure and switch databases and use microservices and..."?

Designers are exactly the same way. Just as technical fiddling is fun and interesting, making new designs from scratch is just as fun and interesting. And, just as fixing bugs is tedious and boring, tweaking designs is tedious and boring.

I've been on both sides for a lot of years, and I have to keep a sharp eye on myself to keep from spinning my wheels on distractions.

Even the Pope had to keep Michelangelo focused on the Sistine Chapel and not wander off to work on his tomb.

View on HN

I was ready to fire the agency the moment the author mentioned they were going off script and building whatever they wanted. This was a huge, blinking red flag for me. Why would you keep paying someone when they're doing work you didn't ask for, doing work that doesn't align with your goals, and ignoring what you say?

I call this the being too nice mistake. It is like the customer that would watch an employee spit in their food and say thanks to them. Effective leaders do not fear confrontation.

In this case it might be a case of being intimidated by a big agency. Isaac telling him that he was their smallest client had a "you're lucky we are willing to work for you" feel.

> I thought I’d enjoy service normally reserved for large companies despite my limited budget.

Sounds like that's exactly what he got, tbh.

This feels even more dubious because if I figured out the correct company, they're fishing in the freelancer threads quite a lot. They know what they're offering to HN readers.

This would be first red flag for me. If someone from the getgo positions himself as doing you a favour, switch - it is not going to get better. At best its uncontrolled ego problem, at worst its a scheme to dry you up.

You are right But it's not always a clear cut. Sometimes trades have "artistic integrity" for a lack of better words. Carpenters, architects and also programmers - The client tells them what to do, but they usually want some freedom to leave their mark.

That seems to be the point where sunk cost fallacy strikes hard in the post to me. They had paid $X for "80% of the first milestone of work" and that sunk cost locks them in to everything else that happens. They seemed too fearful from that point onward that if they fired the agency and brought in a new agency or freelancer that they would start from square 1 and do all of the previous work (and spend) over again.

The sunk cost fallacy suggests that sometimes is better for you if you should just accept existing losses, accept you've already sunk those costs and won't get them back, and move on. I don't know what their contract looked like with the agency, but an 80% of a logo design sounds like a perfect deliverable that you can safely fire the existing team and take the 80% deliverable to a new designer, not start from scratch, and ask them to do a final polish step. I would have cut losses there, but of course it is much easier to armchair quarterback from hindsight and different perspectives than if you are in the middle of it fighting that gut feeling that you've already invested so much and can't "afford" to cut losses.

Which absolutely makes me think this was a well thought out con designed to prey on those types of fears and maximize the value extracted from the mark.

Those lottery phone scams out of Jamaica which target the elderly in the US are almost the exact same scam as what was described here.

Promise something, get them to send money, don’t deliver, tell them you need more time/more money. Keep repeating until the mark walks away.

Maybe "well thought out con" is a little strong here. I see it as more likely the consulting firm has learned this behavior over time and it has rewarded them well. I imagine that if they're normally dealing with large contracts, those companies footing the bill are probably easier to string along like this. Just do enough and promise enough that they keep you on and only budge when they get more serious about potentially terminating the contract.

I don’t buy this was some mistake in good faith. I think the author is a little naive which made him a good mark.

They started work on and subsequently billed for something that was explicitly out of scope.

My guess is that the founder of the agency knew early on that he could push this client around to extract $.

Also they finished the work in a brisk sprint-like pace towards the end, knocking out the pages in record time. I think that was more indicative of the actual effort required to finish the work, not all the hours they billed. There is a perverse incentive when the client has a retainer to bill hours and make up excuses to line their pockets. They finessed the author and preyed on his naivety

I agree, and it takes force to break them out of this behavior. I know of a guy, who forced the contractors to break down the wall they just built because they didn't let him inspect the place behind the wall before enclosing it, as promised in the contract. He knew that if he lets this slide, they'll keep doing it.

An analogy here would be forcing the agency designers to completely delete any speculative redesign work, without any backups, to force them to focus on the logo, and send a strong signal that I don't care about the redesign, and won't be paying that work.

Most of my career has been spent at agencies.

I think you're attributing malice to what was more than likely routine mismanagement.

Perhaps, but there is an incentive to continue that mismanagement, rather than fixing it.

> I think you're attributing malice to what was more than likely routine mismanagement.

I wouldn't call it mismanagement. Many agencies thrive despite regularly delivering these types of experiences. It's a conscious choice they can easily rationalize because of the money.

This agency turned a one off $7k job into $46k by smooth talking and scope creeping an actual developer. I'm sure they're absolutely killing it doing the same to non-technical folks.

I'm sure some do have that attitude but I don't believe, for most, that they're choosing to operate that way.

TinyPilot is clearly successful and growing. Any smart agency would nurture that relationship, deliver a great product, and secure an ongoing relationship.

By contrast, there's a huge amount of reputational risk in allowing things to spiral. They've walked away with more today but imagine for a moment the damage that would have been done were they named in this article. It doesn't take much for a brand to turn toxic and things to implode.

But hey, they were not named :) And that lines up with my experience in agencies - there is always an “Isaac” who’s job is to cool the customer down.

Yes, I’m very confused why he did not make the agency.

My guess - contractual obligations or some other liability?

What benefit would the author get from naming the agency involved?

There’s a big legal risk involved in doing so and no upside that I can see.

I was disappointed the author didn’t have the guts to name them.

I would hope he could get some satisfaction in knowing that he might be able to stop them from taking advantage of clients in the future.

Easy for an outsider to say, though I’d imagine it’s a perfectly reasonable precaution to be cautious in the first post they make. Also he’d then not need to worry about what he exactly says in the post or mince his words/self-censor.

Yeah my read is they were having some internal issues and were overloaded. On top of that they hadn't done many projects like this.

Management threw it out to the floor and the floor ran with it like every other job. Feedback went to management but the people doing the work didn't really understand that this client was not like their other projects.

I've been on the other side of this where one bigger client changed the game and we didn't adapt as we were used to things at a different scale. We didn't clean up the mess we inherited fast enough. We didn't put enough resources on the projects and we failed to live up to expectations. We were used to smaller tasks with more limited scope.

The agency is incentivized to draw out the work to maximize billable hours

Such things can happen very easily even when everybody has good intentions especially if nobody keeps the entire team focused.

The sunk cost fallacy is perhaps the most useful thing you learn in business school. eg. Do I want to pay $9,600 to get the job finished. What would it cost if I hired someone else to finish it ?

The same thing if you are going to a concert and lost your tickets, do you want to pay $200 to go to the concert (not taking into account that you've already lost $100, you could have lost that $100 on whatever) eg. you are paying 200, not 200+100.

Yep. It's not a situation where they're an indeterminate way through building a custom app using a custom framework and you really do lose everything if you start again, it's a case where an agency has designed and handed over a logo and some very conventionally-designed mockups which any competent freelancer with knowledge of Vue should be able to implement on your platform, and revise as requested. And they're citing lack of availability, so it's not even rude to walk away with the deliverables you paid for.

Pretty sure the agency is well aware of this fallacy, which is no doubt why they treated this guy so well in the very beginning.

This is why I still like Agile and Scrum, as much as other devs might hate it. “Yeah I want REAL deliverables after the first or second week”.

Keeps me honest. And will keep me from working with architecture astronauts don’t really deliver anything but hot air and build ultra-extensible structures that are actually impossible to extend beyond the fantasy world of their maker. Or the equivalent for designers.

I'd bet you a large sum of money this agency used Agile.

Agile is not a guarantee of deliverables you care about. There is a lot of useless stuff you can deliver.

Well, if you are doing it correctly, you are supposed to make a sprint goal of a deliverable that has value.

Well, waterfall used to not deliver anything at all. Not delivering anything is pretty useless.

> Well, waterfall used to not deliver anything at all. Not delivering anything is pretty useless.

That's pretty much untrue; had this project been a waterfall project then:

a) The devs would not have gotten paid until they hit particular milestones,

b) The deliverables would have been scoped upfront,

c) The agency would have eaten the cost of developing useless things, not the customer.

Because this was obviously an agile/Agile project:

a) The payment milestones were not specified upfront,

b) The devliverables remained unscoped until feedback was needed (which was well into the development phase),

c) The client eats the cost of developers time, whether or not milestones are hit.

> I'd bet you a large sum of money this agency used Agile.

They probably said the word "agile" a lot and then continued doing something else, that seems to be the usual pattern.

> Agile is not a guarantee of deliverables you care about. There is a lot of useless stuff you can deliver.

Which is why it's the product owner's responsibility to prioritise.

> Which is why it's the product owner's responsibility to prioritise.

The company didn't seem to have issues prioritizing the authors tasks into no mans land. So they seem to have that part down great already. However I find the consistent two week deliveries early on a bit disturbing, in my experience two weeks is exactly one sprint and fixing deliverables to that time window means that you can't really do any agile planing with it, your team just has to accept that this work has to be done and can't give random work that seems to pop up every now and then the attention it deserves. To be really agile and allow your sprint planing to reflect that you shouldn't promise anything in time spans less than two months.

The whole point of agile is that you deliver something every two weeks. Whatever it is you're suggesting, it's not agile.

Delivering "something" and delivering specific items at a fixed rate are different things.

Agile never promised to do the latter (and I've never seen a methodology that succeded at it in a way that was useful in practice).

> I'd bet you a large sum of money this agency used Agile.

Probably not. Larger relatively successful design / marketing agencies are - based on my experience - poorly run, poorly managed, and poorly led. This gets exasperated by high turn-over (read: good people leave, dead weight stays behind).

Training, etc.? Not a priority. Revenue, it's all about revenue. They're "creatives", not business problem-solver types and presume mess and excessive friction are unavoidable.

Even if they're using agile, it's up to the customer to ask for deliverables that they care about if they want them.

Of course it would be much better if the agency were honest, but if for seven months the deliverables were only "promises", then it's definitely not agile...

Agile and scrum are in practice such nebulous terms that while I don’t doubt that you have had good experience with the particular version of these concepts that you yourself use, the agency could well consider itself to be using the same concepts - yet here we are.

The older I get, the more I come to understand that the problem with projects is people, not methodology. 30% of IT projects still fail, despite “agile” now being widespread.

The first value of the agile manifesto is “Individuals and interactions over processes and tools”. Unfortunately, most implementations throw this one out first.

only 30%? I'd have guessed that most IT projects at least fail to achieve goals if they don't crater completely. the bigger the projects, the more they resemble interplanetary collisions.

Well, that’s according to the PMI. Finding the link will simply lower my level of happiness for the day, but you should be able to Google it (sorry).

The thing is that as far as I can tell, “success” is measured post-hoc, so all sorts of shenanigans might have taken place in order to determine that a project was “successful”. Having worked with my fair share of corporate project leaders, I’m quite certain that the actual number of failed projects would be much higher if measured by the original criteria used to justify the project in the first place.

Helmuth van Moltke (1880): "No plan of operations reaches with any certainty beyond the first encounter with the enemy's main force." It applies to software projects too, especially large ones. The enemy is the real world (or our lack of understanding of the real world.)

If we look at the original requirements every single project is a failure. If we look at the strategic goals and keep track of all trade offs maybe 30% is a fair guesstimate.

> 30% of IT projects still fail, despite “agile” now being widespread.

That's a very optimistic statistic, unless "fail" is defined to be something other than "the opposite of success".

IOW, a fail is any project that goes over time, over budget or delivers under scope.

If you're defining success as "well, we delivered eventually, and we delivered 80% of the requirements, and it only went over budget by 20%", then, sure, only 30% of IT projects "fail".

Ok, by that measure I guess over 90% of projects would fail. Which would probably be unfair in most cases, because unlike this project, where the scope as defined by the client was 100% clear from the start, most clients when starting out with a project can't really say exactly what they want, so the scope creep is not only driven by the agency, but also (sometimes mostly) by the client.

The problem as I see it is that projects often start without a vision, or even clear goals; even if there is a vision, it ends up getting lost and forgotten in a sea of feature requests.

Not only should we be asking if a project has achieved its original goals once it’s finished, we should be continually assessing progress against those goals throughout the life of the project - yet few projects I’ve worked on actually do this, even when I’ve explicitly requested it.

> most clients when starting out with a project can't really say exactly what they want, so the scope creep is not only driven by the agency, but also (sometimes mostly) by the client.

Most clients know exactly what their goal is ("To increase market recognition", "to increase conversion rate", etc). The scope creep can only happen in a requirements phase[1]. Once a client has signed off on exactly what will be delivered, and what the payments milestones are there's no wiggle room for the agency to continue experimenting.

If you're skipping the requirements phase because "agile"[1], then the work will be over budget, over time and under the scope.

There's very few projects that actually require the exploratory-driven process that agile uses. If you have one of those projects then farming the management of it out to an agency is exactly the wrong thing to do.

[1] There may be multiple requirements phases. For example a large "need to revamp our website" project can be split into multiple serial projects, each with their own requirements phase.

[2] I.e. We'll figure out what is acceptable to the client with constant feedback.

I think the goal is not to eliminate "failure", but reduce it. Failure will always exist but it always requires interpretation. Thus the credos of "failure is learning experience", "don't be afraid to fail" etc.

It's a very abstract term. To put in simpler terms you will always have some outcome mismatch and generally your goal should be to reduce it. But if you do not have outcome mismatch, then you should push the line so that you can look ahead and understand future areas for improvement. Or you can just stay content if "market" is not chasing you.

I've had someone tell me, with a straight face and serious voice, to "stick to the agile process from now on"

I agree that there's a lot of wiggle room, but there's still some ground rules, like being iterative, not having to plan for everything beforehand, deliver smaller things little by little, not being a perfectionist and turning the review process into a living hell.

But you are 100% right about the problem being people. The problems I see with agile are always because people try to find escape hatches in the process. Designers want to prepare every single detail before developers start working and hate iterating because fear of the "original vision" being a mistake, product owners don't want partial stuff in the beta channel so everything has to be in its final state, product owners don't know or don't want to reduce scope so developers end up with impossible sprints, developers want a perfect definition finished before starting work, so zero chance to iterate...

I also agree with people throwing out individual/interactions and picking a heavy-handed process instead :(

Scrum is really for low-trust environments where management fundamentally don't trust the developers to deliver - whether because the developers aren't experienced, not very good at self-management, or too easily distracted by shiny things, or because you're an archetypal MBA type who distrusts any underling who might be smarter than you.

If you trust your developers (whether in-house or contractors) to do the job you can pretty much let them manage themselves with whatever kanban-ish system that works for them. If you don't, you have a ready methodology that gives you meetings upon meetings and two week deliverables and every little thing broken down to the smallest unit under the guise of "empowerment".

While this is definitely true (I've worked in both kinds of environments), I think the scrum process isn't for low-trust per se, but for managing expectations, especially if you have a larger IT organization. Your direct product owner needs a way to determine how long the development of features can be done, so that they can coordinate and manage expectations with other product owners and other stakeholders (management, customers, etc). I see it as a way to abstract away the individual developers and dev work.

And you probably know that there's a BIG portion of developers who aren't as self-organized or disciplined. You mentioned the shiny things distractions, I think that was a factor in the original post. The other being mismanagement on the agency's side, where they allowed their designers to go out of scope. And I'm not even convinced it's mismanagement, because they turned a $7K project into a $46K project, a 6.5x increase in their revenue off of some small side project.

That's not entirely wrong, but Scrum is also great for high-trust environments where you want to have deliverables from sprint one.

And it is actually more useful when things are flipped, and the team doesn't really trust the client/customer/manager. Which is often what happens more frequently.

But you're totally right that Scrum can get kinda heavy on the meetings side. Which tends to be the rule, not the exception. The only times I had this exception it was when we had a technical person working on the requirements, though. No designer or product owner making nebulous Jira tickets.

You're correct, and I expect the real issue is that working that was was completely foreign to WebAgency.

They typically are employed by businesses who are looking for a very specific result: a good website that works well.

Their team wasn't setup to, and didn't know how to just deliver a simple logo.

The correct answer would have been for WebAgency's CEO to say, "We'd love to work with you, but we're not really setup for this type of project. If you'd like to have us take on your whole website, here's what that would look like. Otherwise, I don't think we're a good fit."

I think that at the time, the agency upsold the author and they went along with it; after that, sunk cost became a factor. I do believe this is what most agencies will try, upselling I mean.

That said, clients can also be problematic; I recall one where the client paid a fixed amount per two-week sprint, but then really started to stretch out how much work was done within that sprint by basically not signing off on tasks and reporting new features to be added as bugs. It's another case I think of a party not being firm enough about scope.

If it's not part of the agreed upon scope and they didn't ask for permission, I see no obligation to pay them. They can put the logo in context, sure, but if they end up spending more time on the sketches for that context than the logo itself, that isn't what you ordered.

> Designers are exactly the same way. Just as technical fiddling is fun and interesting, making new designs from scratch is just as fun and interesting. And, just as fixing bugs is tedious and boring, tweaking designs is tedious and boring.

My god, that explains why modern designs and user interfaces suck so much. That, and the fact that many designers work off their gut feelings and personal subjective preferences, rather than systematic and evidence-based study.

Remembered me of a rumor (or fact?) that almost all Windows 10/11 designers use Mac. And it shows: the end results broke all the UX Windows users were used to.

Graphic design has been a Mac stronghold for basically forever. I remember them being the only exception to the Windows only” rules most companies had for a very long time.

Also as a Windows->Mac switcher myself, I’m not sure breaking Windows UX is a bad thing.

It is. If I didn't like Windows UX, I'd switch to something else on my own, thank you very much.

Don't you wish there was a vibrant ecosystem of commercial OSes, each providing a different choice regarding the UX or other aspect you want to prioritize, each being financially viable based on their merits and not getting crushed by a monopolistic gorilla ?

You'd have options to go to when Microsoft makes choices you don't agree with.

I sure wish we were in that world.

Google has decided that the clock on my phone must be HH\nMM and there is nothing I can do about it :(

There's LineageOS. Not sure it is worth the effort to switch just for this though.

Which is also the solution for "OS gorilla". Use Linux. You have a vibrant ecosystem of distros, they work (as much as any OS), and you are free to mix and match. No need to stick to OS that changes under your feet with no recourse.

I'm fine with there being a vibrant ecosystem of open source OSes, each providing a different choice regarding the UX or other aspect I want to prioritize. The monopolistic gorilla is there but the only really effect it has is that other commercial developers like to only support the monopolistic gorilla.

My interest in commercial OS es is on the support/ contracting parts. For instance if tomorrow Sony wants to make a non Windows VAIO machine and look for a partner with an OEM program, open source OSes are out of the picture.

They could take a LTS somewhere, pay another specialized company for additional expertise, but the would be no way to have an actual contract with the leading entity, and have any weight on the direction the OS will be developped (MS is also bigger than any single OEM, but they will still try to keep the majority of OEMs happy and not pull the rug under their feet. Ubuntu for instance doesn’t have such strong incentives)

We’ve had that. Turns out it just shifts the battleground from “I want my company to control the world” to “I want my ideas to proliferate through the whole world”.

Not only do we end up with https://xkcd.com/927/ (15 standards), but we end up with massive amounts of work being essentially trashed because it’s in one of the tiny tiny fragments that gets passed over.

Maybe I’ve just gotten old, but I’d even compromise by making the “power user” the most targeted demographic again. Power users want things to work well, they want the ability to use hardware and software on their terms and for all sorts of things the creators may have never intended, and they want to customize anything that they choose to.

Remember how XP’s theming engine was trying to win users back from all the replacement “shells” like litestep? Or how macs had wild extensions like one that could rotate the mouse cursor as it followed the point? Or mouse-based gesture applications? Or generative art screensavers? Or websites dedicated to showing of the beautiful artistry of user-created desktop UIs where each was entirely distinct from the other (even on Windows!)?

Even the Pope had to keep Michelangelo focused on the Sistine Chapel and not wander off to work on his tomb.

Not that it matters in this context but wasn't it the other way around? Didn't Donato Bramante try to sabotage Michelangelo by convincing Pope Julius II to give him the Sistine Chapel comission, assuming that Michelangelo would fail (due to his lack of experience in fresco painting) and ruin his reputation in the process?

So Donato Bramante was more a consultant recommending an overpaid design agency hoping to benefit from their failure.

I was actually thinking of "The Agony and the Ecstasy," which is on somewhat shaky historical accuracy footing.

Rex Harrison whacking Charlton Heston with a stick because he's slacking on the ceiling is how all project managers should handle both devs and creatives. I hear that's how Larry Ellison does it.

We’ve heard of Scrum. Now comes Stick

Yeah I sort of rolled my eyes at all the logo redesigns (especially as these seem to have come first in the process) but it seems Author was fine with it. It’s an impressive read because Author (and Isaac to some degree) seem quite even keeled in dealing with everything.

> seem quite even keeled in dealing with everything

I'm guessing the money they lost in this endeavor didn't materially impact them.

I know we don't know costs, but per the article it's about a month's revenue, and I assume it's pretty profitable. Not the first hire either, so the difference between 7k and 46k total over several months is not a lot in a way.

I think we do know costs in this case! The author is very open about the finances of his products. And in this case, while he did start generating profits from tinypilot in 2021, those were only around 17-18k$ IIRC. So this is still a massive expense for the business I'd guess!

I used to think this whole pattern was just Chasing the Shiny with a heavy dose of aversion, but something I noticed was that on a redesign, the management tends to give you the benefit of the doubt for a while. There’s a brief period where everything is easier socially before the ugliness starts up again.

Getting a redesign approved can be the difference between having a long project on your resume and people asking you why you job hopped so much.

I love fixing bugs. Sometimes more than writing new things. Seeing the system health increase as I delete old code, add new tests, and increase performance is very satisfying.

I hate fixing bugs, but I love having fixed them more. It's the same sort of relationship I have with playing hard games, like Elden Ring, or whatever.

The actual search for the problem, and sometimes even the implementation of the fix, can be really frustrating, but that is a vital part in the absolutely ecstatic feeling I get from having actually Fixed The Thing.

You are a blessed, holy person. Not even joking a little bit. It's people like you that keep the world ticking over.

This makes a lot of sense, I feel like this is more of a management issue, it should be the responsibility of the manager to keep everyone working on what is initially planned.

They kind of addressed this by saying that they try to keep management billing hours quite low. Perhaps this low percentage would have been "enough" had the size of the project been bigger? Although, I think it'd be fair to argue that the designers should have been "trained" (i.e., with time not billed as "management" for a client's project) to stick to the project scope a bit better.

I get it though: my only experience has been with internal, full-time employees, and I see is given a fair amount of latitude to do exciting things and to experience small failures. It's a different mindset for external contractors, it seems.

The agency would normally allocate 5% of the budget to management, but Isaac made the decision (since the budget was so small) to completely eliminate that. The budget ballooned to 6x its planned size and the management allocation was the same percentage of that as of the original budget: 0%.

Rather ironic, since that latter budget probably is sufficiently large not to eliminate management completely. (~$350 vs ~$2000 for mgmt)

> a lot of technical debt ... let's rebuild the whole thing using Rust and Kubernetes and Deno and move the hosting to Azure etc.

For me, I'm the dev who says: "This codebase has a lot of technical debt. Let's get rid of all of the containers and VMs and kubernetes and artificial servicification, take it off the cloud, and refactor it into smaller programs which do the work efficiently and which can be built and run on basically any machine(s) and cooperate peacefully."

I wish I knew more devs like you. My life would be so much easier if we could all think like this.

But definitely rewrite it in rust ;)

Oh not only a rewrite, but also a re-architecture. What could go wrong?

1. Things have already gone wrong...

2. I guess I would add "slowly and carefully".

Probably a lot less than when making the move in the other direction.

Well considering theyre removing tools like kubernetes but keeping the micro service architecture, probably a ton.

All the problems Kubernetes and the like solve they’d have to rediscover one by one

> which can be built and run on basically any machine(s)

So like containers?

Uh... no. Try: Build configuration and dependency management tools.

I think it's important to establish clear goals before reaching out to freelancers and agencies. The agenda from each one is different than yours.

I learned to get the team focus by writing a brief (commonly used for Brand Managers in big companies) to keep focus on the deliverables. That helps to avoid these type of issues.

The agency was a JS abusing their client so idk why you would just lash out at new great technologies when they weren't part of this.

It's a pet peeve and a common problem in software development, where developers don't want to do the work that is asked of them because it's not challenging enough (yay another REST API in front of a database), so they add complexity themselves - new, more difficult languages like Rust or Scala (not as much of an issue anymore I think), excessively complex architectures like microservices, DIY infrastructure configuration like k8s, etc.

See also magpie developers. It's not that the new technologies are not great, it's just that in most cases it's not what a client needs, but what the developers want to do. They will have a solution and look for a problem to match.

I mean I'm not innocent of that, I'm looking left and right for problems where I could use Go to solve them with because I enjoy it. But I am aware of the risks.

Anyway the comparison is apt because it happens with developers; I've seen it happen firsthand at multiple projects, and in almost ALL of those, after the consultants left, the company moved back to their own technology, picked something off-the-shelf, or did yet another rebuild.

I think the comment was fair; Too often have I witnessed clueless and/or conniving salespeople recommend businesses to move onto Azure or other cloud services when there was very little to gain from it, yet it meant that the cost compared to hosting their very simple ERP software on metal would bankrupt them in the first bad month.

> have to keep the devs from going "this codebase has a lot of technical debt, let's rebuild the whole thing using Rust and Kubernetes and Deno and move the hosting to Azure and switch databases and use microservices and..."?

Also known as the "oh look, a shiny thing" development paradigm.

I wonder how you judge the tipping point?

"Why do it in C when assembly language has been working so well for years?"

Following through the example, if assembly language works well, then there's no justification to do it in C. One needs to find (valid) reasons to justify such decisions.

The tipping point would be when you can come up with a compelling answer for the question you laid out. You don't just rewrite it in C as a reflex to that question.

Reply on news.ycombinator.com