Hacker News new | past | comments | ask | show | jobs | submit login

>allows fairly non-technical people to build fairly robust applications with very limited CS training

Ok. BUT... when those limited CS training people want it done right, they hire any one of the huge middlemen do make SalesForce integrations and modules.

ATG is one I know of first hand. Hiring tons of people to make SalesForce suck less. Mostly sales people themselves, then some programmers to do the real work.

This cottage industry would vanish overnight is SF just sucked less. That's a weak foundation to build anything on.

Think of the other tech companies over the years that have seemed like behemoths to be utterly knocked out by someone that came in and sucked less. What do you think happened to the industry of Certified IBM Professionals that relied on IBM being market leader in PCs?




> This cottage industry would vanish overnight is SF just sucked less. That's a weak foundation to build anything on.

It's worked for hundreds of thousands of people who make a living from turning raw Access/Excel/Wordpress/Microsoft CRM/Dozens of other products/etc into custom applications that solve the needs of particular business processes.

Every business has its own warts, that no one-size solution is going to solve well, and that will require someone to write a plugin for an off-the-shelf business product.

Outside of the Silicon Valley bubble, most software engineers make a living doing just that.


My first job was writing simple glue scripts that talk to a database for a small biology lab, to help them keep track of their samples and orders. It was ancient. I was so grateful to have the job. Man, I was happy.

This is the 99% of programmers who are a lot more grateful to have a stable API that reliably works than they are worrying about "obsolete languages".

The more time I spend in this industry, the more I begin to think that developers are really not the friends of users or even of their employers. Developers hate maintaining code they didn't write, which is the most important need most businesses have, as well as the most important need customers have. This creates a real tension where companies, especially as they become a monopoly, tend to lose the customer focus and start focusing on internal constituencies. And in a tight labor market for devs, that usually means mass rewrites, rolling out complicated ambitious new frameworks and models, rather than, you know, adding features that customers use to existing code.

The result of these rewrites is generally something with fewer features, an unfamiliar interface, and more bugs than what preceded it. Joel Spolsky has a nice article about this: https://www.joelonsoftware.com/2000/04/06/things-you-should-...


Well I mostly agree but you have to consider technical debt


What makes you think the hypothetical rewrite on a new technology is going to have any less technical debt?

By the time you get to feature parity with the old shitty system, your new system is also going to be shitty. In my experience, technical debt comes from three places.

1. The people who built the system didn't know how to do things right the first time.

Solution: Employ experienced people when you're building the system, the first time. If you didn't do that right the first time around, have experienced people rewrite the bad parts.

Non-solution: Rewrite the whole thing in a new technology that nobody is experienced with. (On average, your new team isn't any more skilled than the team that built the original system.) Waste time rewriting the parts that aren't bad.

2. The problem is actually incredibly complicated, and has no clean solution.

Solution: Don't do anything.

Non-solution: Rewrite the system, re-discovering all the reasons for why it was built the way it was.

3. Most of the system is actually fine, there's just a few bad parts.

Solution: Refactor the bad parts.

Non-solution: Rewrite the whole thing, even the parts that are maintainable.

--

I have seen a lot of painful rewrites, but I've never actually seen any featurefull software project that did not have a lot of technical debt.


Technical debt is always a problem. But generally I prefer refactoring existing code rather then rewriting to address technical debt, because I think the old system is well understood, and the deficiencies are known. When you blow it away, you are also creating more technical debt, but you just haven't discovered it yet.

This isn't to say "never rewrite". I am saying we rewrite way too much now.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: