Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Developer inequality and the technical debt crisis

alarmingdevelopment.org

Post reply on HN
Print view View original

51–60 of 105 posts

Re: Developer inequality and the technical debt crisis

#51

Post by falcolas »

gloverkcn wrote: post #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 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 believe the point of the article is that you shouldn't have to be a developer, steeped in the arcane knowledge of the LAMP (LNPR, Docker, etc) stack, to create an application.

His example (and seemingly his rose tinted wonder from the past), Hypercard, didn't require any knowledge more than you would need to create a spreadsheet. If you could work a mouse, a keyboard, and had a vision, you could create an application. Certainly a primitive application by today's standards, but I saw interactive games, training applications, presentations, order entry screens... the whole gamut of development potential written by people who didn't know what a Gigabyte was.

Re: Developer inequality and the technical debt crisis

#52

Post by enraged_camel »

jrochkind1 wrote: post #36
michaelochurch wrote: post #18

Earlier quoted context omitted.

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 wou…

>>I do not think it's because most programmers just aren't trying hard enough, or don't know that it's junk.

Actually, that's exactly the reason.

Back in 2003 I was a sophomore in college and I took an intro-level CS class. It was taught in Java. Back then we didn't have sites like Stack Overflow, so if you ran into issues during projects you had to find someone who could tell you what you were doing wrong. Often times this person was the TA or the instructor, and those had limited availability in the form of office hours. So it was super easy to get demotivated and give up -- which is indeed what made a lot of wanna-be programmers (including me) switch majors.

Fast-forward ten years. We now have a plethora of resources you can use to teach yourself "programming." While this is good in the sense that more people are trying to enter the profession, it's not so good because when you teach yourself something complex like programming, it is often difficult to know whether you are learning the correct habits and skills. I've been learning Rails for the past five months and I spend a lot of time obsessing about whether the code I write is high quality, but that's only because I've been an engineer for six years and I'm well-aware of the risks of building something overly complex and unmaintainable. In contrast, most people build something, get it to work, and then call it a day. They don't go the extra distance and learn best practices. As a result, the code they produce is junk.

Re: Developer inequality and the technical debt crisis

#53

Post by narag »

cafard wrote: post #9

"Our goal was to allow regular people without extensive training to easily and quickly build useful software. This was the spirit of languages like COBOL, Visual Basic, and HyperCard." I think that this slightly overstates the matter. Having peered into the guts of some payroll code, I question whether it was easily built. Could we say "To allow application developers to concentrate on the complexities of the problem…

Nice phrasing.

Programmers swarm to tools that cut to the chase, even if they're quirky. We want instant gratification :-)

The right thing is simple and consistent.

Re: Developer inequality and the technical debt crisis

#54

Post by mr_doobey22 »

gloverkcn wrote: post #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 expensiv…

There is also the argument that in the old days, developers had to think carefully about their code and design. Spend time considering the data, structure and algorithms to be used. Resources were limited, maybe time at the computer was also limited. Inputing programs could have been labourious due to flicking switches or punch cards.

Basically, you had to stop and think a bit first.

Not such a bad thing - pausing to reflect before writing the first thing in the head, and releasing it as soon-to-be-abandoned-Ruby-Gem.

Also, developers of yesteryear may have had a more than passing understanding of the hardware, of how the OS worked, of how to work within the constraints.

Developers these days treat resources as infinite, as something to be allocated by someone else "mooooarr servers - page the devops!" - "but, if we just looked at how the code is performing?..." - "no, moooaarrr servers!".

Re: Developer inequality and the technical debt crisis

#55

Post by webmaven »

djur wrote: post #47
webmaven wrote: post #26

Earlier quoted context omitted.

"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.

The more generalized a tool is, the more special knowledge you need to use it for specific tasks. The advantage of stored-program computing is that we can take a general tool (a computer) and package it with a set of automated instructions (the stored program) to turn it into a specialized tool that you can use with general knowledge. That's pretty much the fundamental endeavor of the software profession. Compilers,…

I guess the question is, where are the equivalent partial solutions for the web?

Re: Developer inequality and the technical debt crisis

#57

Post by stouset »

jleader wrote: post #44
michaelochurch wrote: post #18

Earlier quoted context omitted.

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…

You say "So much of the code out there is "totaled": it would cost more to fix or maintain it than to rewrite it from scratch." If that's the case, why does such code still exist? If it's still running, then in some sense someone is "maintaining" it, at least to the extent of keeping the server it resides in powered on. In other words, someone obviously finds it cheaper to keep such code running as-is than to rewrite…

One example: I used to work for a company offering a security-related product with crippling, fundamental security problems. The flaws covered everything from improper use of cryptography to failure to validate external input, lack of proper authorization handling, and even "features" fundamentally at odds with any widely expected definition of security.

This company continues to survive, and has several large clients. But the liabilities of the current code base are massive. Worse is that the clients aren't aware of the deep technical problems, nor is there any easy way for then to be. In a very real sense, this company is making some money in the short term (I don't believe they are profitable yet) by risking their clients' valuable data.

In general, the concern by the grandparent is that there are projects out there that are producing some revenue, but are essentially zombies. Every incremental feature adds more and more cost, but there's no cost-effective way to remove sprawling complexity. The project will die, taking along with it significant investor money.

Re: Developer inequality and the technical debt crisis

#58

Post by arh68 »

angersock wrote: post #39
arh68 wrote: post #31

Earlier quoted context omitted.

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.

True, true. Hyperlinks are pretty big. Defining links with a new language is certainly one way to do it. But look here on HN, what do I do? I write plaintext. I certainly don't write . I write like this [1], and the hyperlink becomes an implementation detail. An HTML implementation detail, haha, sure, but nowadays it's not hard for hyperlinks to be emulated. Anyhow I honestly do think html5 is a great language. (but so is text! :)

[1] http://google.com/

Re: Developer inequality and the technical debt crisis

#59

Post by keithpeter »

nmrm wrote: post #15
jrochkind1 wrote: post #8

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:…

> written by non-programmers This is an interesting characterization of Jonathan Edwards... did you not do research on the author before writing this, or are you really claiming he's a "non-programmer"?

subtext looks interesting. Is it being developed in the open at all? Versions for download? The page looks like one of those shop windows covered in white putty to stop you looking in.

Re: Developer inequality and the technical debt crisis

#60

Post by michaelochurch »

jrochkind1 wrote: post #36
michaelochurch wrote: post #18

Earlier quoted context omitted.

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 wou…

As long as the job of a programmer is to be a business subordinate, it will not change and we'll see crappy code forever.

Mainstream business culture conceives of management as a greater-than relationship. You're a lesser being than your boss, who's a lesser being than his boss, and so on... It also is inhospitable to the sorts of people who are best at technology itself. Finally and related, it conceives of "working for" someone not as (a) working toward that person's benefit, as in a true profession, but (b) being on-call to be micromanaged. The result is that most programmers end up overmanaged, pigeonholed, disempowered, and disengaged. Shitty code results.

If you want to fix code, you have to fix the work environment for programmers. Open allocation is a big step in the right direction, and technical decisions should be made by technical people. Ultimately, we have to stop thinking of "working for" someone as subordination and, instead, as working toward that person's benefit. Otherwise, of course we're going to get shitty code as people desperately scramble (a) up the ladder, or (b) into a comfortable hiding place.

Post reply on HN