Live data from Hacker News

Developer inequality and the technical debt crisis

alarmingdevelopment.org

71–80 of 105 posts

Re: Developer inequality and the technical debt crisis

#71
"In the old days there was a respected profession of application programming. There was a minority of elite system programmers who built infrastructure and tools that empowered the majority of application programmers. Our goal was to allow regular people without extensive training to easily and quickly build useful software."

There are lots of people writing software today (probably the vast majority) who are not "elite programmers". Here are just a few examples:

1. All over the academic world, you'll find grad students in physics, biochemistry, etc. hacking together research software in Python (using numpy/scipy), R, and many other languages.

2. All over the business world, you'll find non-programmers writing programs in VBA and other end-user oriented languages to slice and dice data from databases.

3. The average CRUD code that powers today's web startups usually doesn't require anywhere near an elite programmer to create. Think of all the articles on HN written by a "non-technical founder who learned to program in two months and created a site that makes thousands of dollars".

Re: Developer inequality and the technical debt crisis

#72
post #47

Earlier quoted context omitted.

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?

I think there's not nearly as much agreement on how a "web app" might look or work today as there was for a desktop app even as early as the early '90s.

For "classic" (content-based) web apps (forums, CMSes, blogs), there's already fairly sophisticated, end user-targeted tools that fill that role. For a lot of people, WordPress is the Visual Basic of the web. Some wiki engines could be said to resemble Hypercard.

But the community is so split on what the "modern web app" should look like (thin client? thick client? standards-based or not? use the DOM or draw directly?) that I think it'd be much harder to gain much support for a "Hypercard for the Web" -- many web developers, possibly even a majority, would consider it to be "doing it wrong" and "teaching bad habits" _no matter what it looked like_.

Re: Developer inequality and the technical debt crisis

#73

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…

As a complete derail:

Floating point, as IEEE standard? Beautiful. Elegant. One of my favorite technical standards. Other than the +0/-0 thing, it's perfect.

Floating point, as implemented? Ugh. You've got processors which implement some subset of x87, MMX, SSE, SSE2, SSE4, and AVX, all of which handle floating point slightly differently. Different rounding modes, different precisions, different integer conversions. Calling conventions differ between x32 and x64. Using compiler flags alone on Linux x64, you can make 'printf("%g", 1.2);' print 0. Figuring out the intermediate precision of your computations takes a page-sized flowchart: http://randomascii.files.wordpress.com/2012/03/image6.png

It's a mess.

Re: Developer inequality and the technical debt crisis

#74
post #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.

NuGet/Chocolatey. Just sayin.

Though, I guess technically, they are more of a .NET package manager than Windows.

Re: Developer inequality and the technical debt crisis

#75
post #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.

That theory does not scale well to mobile.

Re: Developer inequality and the technical debt crisis

#76
The author is kind of all over the place, and it's hard to read it without thinking of counterexamples to a lot of his points.

If his general point is to bring computing to more people, I think a modern, web-based version of MS Access would be a huge step. Everyone needs databases. Everyone needs forms to access them in a way that makes sense for their business. Right now you have to actually program to make that happen.

Re: Developer inequality and the technical debt crisis

#77

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…

I agreed with the broad premise that web development is shockingly horrible by the standards of the past era of polished corporate tools. But otherwise, it was all contradictions, inaccuracies, and indefensible conclusions.

>>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?

Before that, he claimed that all of the big companies that had made packaged tools, like VB, had gone extinct. That might be a slight exaggeration.

Re: Developer inequality and the technical debt crisis

#78

One thing this article completely ignores (as do many of the comments on the site) is that expectations have also drastically changed. Yes, Hypercard was dead simple to get something useful actually working, but nobody would accept a web app that looked and behaved like a Hypercard app. I think the author is right: there is a none-to-healthy culture of increasing complexity surrounding web development. But there is a…

While people like (or love) products that look beautiful and delight them, what people love even more are products that do what they want/need. A Hypercard stack or spreadsheet could solve a real problem for a dozen people in a way that a slick commercial product targeting a large audience might not.

I do think there's value in enabling people to make applications that do something useful but aren't so pretty.

Re: Developer inequality and the technical debt crisis

#79
post #38

Earlier quoted context omitted.

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

That theory does not scale well to mobile.

Doesn't it? App stores share much of the virtues of package managers. And with the 90% comment being what it is it's fairly clear mobile is not the subject of the grandparents comment.

Also the discussion is rather pre-mobile. Mobile actually has nearly all of the positives, except os fragmentation, that were referred to in the root comment.

Re: Developer inequality and the technical debt crisis

#80

> Attempting to simplify and democratize programming will attract only scorn and derision (as did COBOL and Visual Basic). The reason COBOL and Visual Basic attracted scorn and derision is that they were awful. The problem with them is quite simple: You can use them to create something improperly in 1000 hours that you could create properly using other tools in 2000 hours. That thing will then work until you have eno…

The things I've seen built on COBOL, and Visual Basic are awe inspiring. The world is built on them - and for a reason: if you don't need a coder there's a whole new definition of "fail fast" that comes into play.

And maybe eventually some tiny percent of these these little things, succeeds beyond your wildest dreams, and is now critical your business, and you have to drop 10k hours slowly rebuilding it using professionals. That's what success looks like. It's also what not paying for 100 failed software projects looks like.

Post reply on HN