Hacker News Reader

Comment by mo1ok | Hacker News Reader

I agree and both disagree. I'm working right now for a client that is a large corporation that didn't do any of those "fad" things - and it is _tremendously_ costly.

For example, one team has spent several weeks and thousands of dollars to get another team's SOAP integration working correctly, when it would have taken five minutes in REST.

The codebase did not follow a "elegant" practice and is an absolute spaghetti mess. Things that should take 30 minutes take one week and this add tremendously to personnel cost.

I agree though that working together is tremendously undervalued. A decently smart person can be taught anything (which is part of the replacability problem you mentioned), but how to not be an entitled ass is nearly impossible to teach in a workplace environment.

View on HN

SOAP was the fad before REST. And spaghetti code is usually the result of fulfilling customer's requests without taking (/wasting, depending on your perspective) the time to rewrite & refactor.

This'll probably come across as depressing to most of the engineers in the audience, but I don't see this as an example of a company that did anything wrong. Rather, it's a company that did everything right but did it too early. They followed the fad of the early 2000s; there was no way to know then that a better fad would come out in the mid 2000s. And they're still around (and a "large corporation") now, which indicates that from a customer & business POV, they've actually been more successful than ~99% of other technology companies founded in that era.

If you're successful, you too can get to have the kindergartners of today complain about what an idiot you are. That's the best-case outcome, though: more likely, nobody will use your code or it will be thrown away a year later for the newer, shinier fad.

(The more positive spin on this is that our industry actually is making progress, and quite rapidly. What other industry can you look at the best practices of 15 years ago and say "What idiots we all were back then!"?)

Spaghetti code and cumbersome integration methods are just forms of tech debt. Tech debt in any form isn't inherently good or bad. Just like financial debt it's a tool that can be used to achieve a desired business goal. When misused it often harms the company but won't be fully realized for several months or years.

Things taking a week when they could take 30m is your company paying interest on that debt. To determine if taking on that debt was a good idea you need a lot more context. e.g. the Cobol mainframes that run the financial system are difficult and expensive to maintain, but it's still cheaper than the alternative: rewriting those systems.

Most startups take on massive amounts of tech debt because it helps them move faster and the company not failing is way more important. Once a company is out of startup mode it should balance goals a bit more thoughtfully.

"Tech debt in any form isn't inherently good or bad. Just like financial debt it's a tool that can be used to achieve a desired business goal."

We should print this and hang it on every wall of every room in which a piece of code is written. It is the most misunderstood and misused concept of Software Engineering.

Regardless of how long it REST or how much you pump it full of SOAP, a spaghetti mess will still be a giant bowl of indigestible pasta.

I mean, a bad interface is a bad interface. There were a lot of issues with SOAP, but time to get a client going wasn't really one of them(the clients wrote themselves!). REST is generally a huge step backwards in that regard IMHO; I have the rise of proto bufs and gRPC to keep that opinion company though :)

> I agree though that working together is tremendously overvalued.

I think you mean undervalued.

Oopsie. Fixed.

Reply on news.ycombinator.com