Live data from Hacker News

Developer inequality and the technical debt crisis

alarmingdevelopment.org

31–40 of 105 posts

Re: Developer inequality and the technical debt crisis

#31

I'll go ahead and say it: this is a strawman. A simple web page is as simple as it ever was: Hi Hello, world! The problem is that everybody wants something so flashy and pretty that they can't settle for the functional-but-ugly barebones interfaces app programmers used to make. The problem is that we've trained users that if a product isn't pretty it's useless, and in pursuit of that all these other things happen. Yo…

Yes. But isn't HTML itself the flashy & pretty (and often non-value-added) alternative to plaintext, the functional & ugly interface? Why not just use plaintext, wrap everything in
, and call the Web a fad?

I'm all for simplicity, I just wonder what's considered taking it too far.

Re: Developer inequality and the technical debt crisis

#32
The web won because it has the least barriers to entry for a new developer and solves a lot of difficult problems that the old-school application stack had. This is all from my history and point of view so I'm sure a lot of people will disagree.

Cost:

The days when big companies developed tooling and platforms cfor developers where great IF you worked at a company that could afford to pay for them. They were expensive. When I first started these suites were tens of thousands of dollars expensive, and later just thousands of dollars. Sure they did a lot of stuff, but man there was also A LOT of overhead in managing the suite. For young people and very small companies these things were unaffordable, and frankly unmaintainable. A lot of times you would here about companies who paid 10-20K for a suite only to not use it due to the training required for everyone, the installation cost, and the need to change your development process to fit the platform's model. So anyone starting out as a developer or starting up as company would find the cheapest/easiest options available. And since there are far more small development teams than big companies there was far more demand and community support for free/cheap systems that while not great could get the job done. Linux was free, mysql was free,Php was free, Perl was free, Javascript was free, and there were communities that would support a new developer through getting these up and running (no 2500 training class required). The reason the LAMP stack became so popular was because it was free, could be installed on cheap hardware, and every element had a community that would support it.

Cross Platform Support and Application Distribution:

With C++/C you had to compile for every target machine. What a nightmare, library flags, macros, ugh. Testing had to have special labs so they could find bugs that would popup in one OS, but not another. Then it had to be cloned on disks and shipped out. Java came around with write once run everywhere which was better (MS came out with CLI and .net). The problem with these was making sure your customers had the base platform installed (the JRE or .net). B2B companies was a little easier because they had standardized equipment and IT departments that knew what to do, but if you were targeting B2C or small business then getting them to install the base software (again JRE/.NEt) was a pain because they would more than likely mess it up or just not know what to do so it required manual intervention. As soon as this got easier you wound up with the conflict of people having TOO much installed on their computer and just not wanting to install anything else unless they HAD to. Fast forward to now and we've got a built in client that adhere's to common standards. If they want to use your app they bookmark it, and when they are sick of it they just delete the book mark. Sure there's cross browser issues, but they are far easier to deal with than both having the customer install some platform and dealing with cross OS issues (plus you dealing with them doesn't require the customer to do anything but hit the refresh button).

Developer Inequality:

I don't know how you can say there's a higher barrier to entry now than previous. In the 90's almost everyone you met who was a developer was a CS/EE major or started on computers at the age of 12. The arcane level of knowledge required for using platform to build an application in the 90's dwarfs what's required now. I still remember struggling with bugs where you'd go hunting for "the guy" who new everything, and then you'd spend a couple of days trying to figure where the issue was only to find some undocumented outcome to a flag passed to a lib. To the developer who was working for XXXX who wrote the library it this was a completely obvious and logical result. Compare that to now. StackExchange. Free Video tutorials, Websites dedicated to teaching you. I constantly meet graphic designers, marketers, accountants, etc. who decided to become developers. I know who guy who has built a decent business with no official development education at all. He learned rails and shoved up to heroku. He learned javascript to improve the client side, and now he makes a decent living.

You can start from NOTHING and in a few weeks have a base product built and being used by an alpha customer. That never would have happened 20 years ago. I feel freer and more productive now as a developer than anytime in my career.

Re: Developer inequality and the technical debt crisis

#33

This feels astonishingly wrongheaded to me. "Imagine an Internet HyperCard that allowed regular people to easily build web apps, as easily as using a spreadsheet." and then JUST TWO SENTENCES LATER, "There are many app-in-a-can tools that generate highly stereotypical apps but to be truly disruptive we need to match the broad generality of frameworks like Rails." In other words, we need to make it possible for people…

"In other words, we need to make it possible for people to build simple things without much coding. Oh wait, people already can build simple things, but....that's not what you mean?" I think that the problem the OP has with most current app-in-a-can tools is that they don't allow users to create arbitrary simple things, but only fairly specific types of simple things.

I think you're right. My problem with that problem is that it's some combination of naive, impractical and pie-in-the-sky. It'd be great for humanity if you didn't need any skills or training to make any kind of computing application you wanted.

While we're at it, let's also have a replicator to make any kind of food we want, instantly and deliciously, without any culinary training whatsoever, beyond being able to press the "pasta carbonara" setting (oh but I don't want there to be eggs in the carbonara, and can it have tuna instead of ham, and can it use a different kind of noodle, but I still want it to taste like carbonara and be delicious...)

Re: Developer inequality and the technical debt crisis

#34

I'll go ahead and say it: this is a strawman. A simple web page is as simple as it ever was: Hi Hello, world! The problem is that everybody wants something so flashy and pretty that they can't settle for the functional-but-ugly barebones interfaces app programmers used to make. The problem is that we've trained users that if a product isn't pretty it's useless, and in pursuit of that all these other things happen. Yo…

Software that ran on the mainframe on a green screen was generally rock solid reliable, and still is. Systems built in the 60s and 70s, still doing real work and making real money. But we ate the apple (pun not intended) and threw ourselves out of Eden.

Re: Developer inequality and the technical debt crisis

#35
post #3

I often watch other developers look to make their lives more complex by trying to solve problems which aren't there. Why? Because the obvious solution is simple and boring. In any other culture that would be crazy. In programming culture, it seems to be the norm.

This is a constant battle for any developer. It's not merely that the obvious solution is boring, but that oftentimes the programmer is juggling so many problems that an obvious solution to one doesn't seem sufficient because it doesn't address the others. That is, yes, devoid of all context the simple solution solves the small problem, but it doesn't address the larger. It's funny that we get back to that after desc…

[deleted]

Re: Developer inequality and the technical debt crisis

#36

I think the reason there's so much technical debt is largely because the amount it would cost to actually build quality software... is too high. We could not afford it. Like, as a society. Our society is built on crappy software. I think it's just a utopian fantasy to think that if only the right hypercard-like tool could be created, then the cost of building quality software would go down. Or at any rate, actually:…

I think the reason there's so much technical debt is largely because the amount it would cost to actually build quality software... is too high. We could not afford it. Like, as a society. Our society is built on crappy software. I'm not sure that I agree. If by crappy you mean "not formally proven", then sure. Or if you consider floating point crappy, then we disagree on terms. I think our industry is in a state whe…

Okay, me and you agree that most of the code produced is junk (not everyone in this thread does I think!).

I agree that the junky code is going to bite us eventually.

But what do you think it would take to change things so most of the code produced is not junk? Would it take more programmer hours? More highly skilled programmers? Whatever it would take... would it cost more? A lot more? A lot lot more? I think it would. And I think if this is so, it's got to be taken account in talking about why most code produced is crap.

I do not think it's because most programmers just aren't trying hard enough, or don't know that it's junk. I think it's because most places paying programmers do not give them enough time to produce quality (both in terms of time spent coding and time spent developing their skills). And if say 98% of code produced is junk, and it's because not enough programmer time was spent on them... that's a lot of extra programmer time needed, which is a lot of expense.

The utopian theory of the OP is that with the right tooling, it would not take any more time, or would even take less time, to develop quality software. I think it's a pipe dream.

Re: Developer inequality and the technical debt crisis

#37

I think the reason there's so much technical debt is largely because the amount it would cost to actually build quality software... is too high. We could not afford it. Like, as a society. Our society is built on crappy software. I think it's just a utopian fantasy to think that if only the right hypercard-like tool could be created, then the cost of building quality software would go down. Or at any rate, actually:…

>>We see posts like this come up here from time to time, written by non-programmers who have some kind of belief that programmers _like_ complexity, that programmers are _opposed_ to making things easy and simple. I totally don't see "modern programmer culture fetish[izing] complexity" -- rather, on HN, I think it's pretty clear that modern programmer culture fetishizes simplicity.

Programmers are people. And like most people, they are resistant to any change that will devalue their well-paying jobs and endanger their relatively luxurious lifestyle.

Let's say that you're a developer who makes pretty decent money writing CRUD applications. A new tool comes out that automates the process and it becomes very popular. What will be your first reaction? Are you going to say, "wow, this is such a cool thing, I'm going to tell all my friends and clients about it and even start contributing to it on GitHub"? Or will you have a knee-jerk reaction, based on fear, and criticize the hell out of it?

Re: Developer inequality and the technical debt crisis

#38

The web won because it has the least barriers to entry for a new developer and solves a lot of difficult problems that the old-school application stack had. This is all from my history and point of view so I'm sure a lot of people will disagree. Cost: The days when big companies developed tooling and platforms cfor developers where great IF you worked at a company that could afford to pay for them. They were expensiv…

>The web won because it has the least barriers to entry for a new developer and solves a lot of difficult problems that the old-school application stack had.

I think the web won because the users prefer it over downloading applications. That's not surprising, as 90%+ of users don't even use an operating system with a package manager.

Re: Developer inequality and the technical debt crisis

#39
post #31

I'll go ahead and say it: this is a strawman. A simple web page is as simple as it ever was: Hi Hello, world! The problem is that everybody wants something so flashy and pretty that they can't settle for the functional-but-ugly barebones interfaces app programmers used to make. The problem is that we've trained users that if a product isn't pretty it's useless, and in pursuit of that all these other things happen. Yo…

Yes. But isn't HTML itself the flashy & pretty (and often non-value-added) alternative to plaintext, the functional & ugly interface? Why not just use plaintext, wrap everything in , and call the Web a fad? I'm all for simplicity, I just wonder what's considered taking it too far.

HTML allows for creating hypermedia documents, which plain text does not. In small, reasonable amounts, it provides functionality not easily reproducable with a plain-text interface while still being reasonable.

Stacking on lots and lots of other stuff, though, is when it becomes silly.

Re: Developer inequality and the technical debt crisis

#40
Because it's there. The only reason people use all these web tools is because they are there, documented and ready. The classic example is the Apache web server - it was there and worked. It was written when the web was small and the number of users to a site was low. Competing web servers are here now with performance way higher, so people are switching. Nobody wanted to write a better web server so nobody did for a long time - and better in that case was easily measured. Programming paradigms? How do you evaluate them? I agree there are fads (FP anyone?) but what objective criteria do we have to evaluate them, or design something from scratch to meet those criteria?
Post reply on HN