Live data from Hacker News

Developer inequality and the technical debt crisis

alarmingdevelopment.org

91–100 of 105 posts

Re: Developer inequality and the technical debt crisis

#91
post #29

Earlier quoted context omitted.

The software itself is usually no more complicated than it needs to be; the issue is that the things we want to do with the software are themselves very complicated. If you tried to do anything remotely complicated in HyperCard, you pretty quickly ended up with something approaching the complexity of a modern application. There is also the idea of "default" versus "custom" and how the definition of the two can change…

> The software itself is usually no more complicated than it needs to be; the issue is that the things we want to do with the software are themselves very complicated. Ok, take these requirements: I want a web app that counts the number of times users click a button. Users should be able to see the number of times they clicked and I should be able to see a top 10 of the highest click counts. To do this I must know HT…

This is almost exactly Meteor's "Leaderboard" example [https://www.meteor.com/examples/leaderboard]. Not much code goes into that, and I think it's pretty approachable for a non-programmer.

Re: Developer inequality and the technical debt crisis

#92
post #86

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

> The author is kind of all over the place, Yes. His article's intent is to describe a problem. He then tries to give examples of solutions, and they're bad suggestions. Still, he's right about the problem. We are in a kind of dark age at the moment, and the technology web stack is an unnecessary horror. Regarding databases, I think what you're proposing is a step in the wrong direction. Databases is one of the major…

"Databases is one of the major problems of our age, and cause of software being so difficult to get right."

Strange. I think of databases as one of the bright spots in computing. They are very closely related to real business needs, and do a good job for the most part.

MS Access was great because it also had a form builder and it could all work over a network[1]. That means you could get a small business organized around a database easily and incrementally.

Now, we have to actually program to make that happen (e.g. rails, django, etc.) and design the forms with text rather than graphically. That's a big step backward for the technical non-programmers (e.g. accountants, HR professionals, etc.).

Of course, I'm always willing to hear new ideas. If you think you have the answer, please share (and/or start a startup).

Disclaimer: I have been heavily involved with databases from many perspectives (user, application developer, DBA, internals hacker). So, it's not a surprise that I think databases are great.

[1] Yes, the networking was a disaster from a technical standpoint. But that's an implementation issue, not a fundamental problem.

Re: Developer inequality and the technical debt crisis

#93

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

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

Most real world MS Access databases needed all of tables, forms, and behavior that required code. Online graphical tools for building the tables and forms components might be useful, but its not going to stop you from needing code for behavior.

That being said, something like Access for the web would be great. I'm surprised it hasn't happened yet.

Re: Developer inequality and the technical debt crisis

#94

Earlier quoted context omitted.

I think it's important to distinguish up-front cost versus long-term cost. In more than just this discussion. For example: plenty of people in the Bay Area would, long-term, find it cost-advantageous to own rather than rent -- if they could get together a 20% down payment. But they can't. So it's kind of irrelevant whether they'd save money long term. The same principle can apply to software. Sure, you'd save money l…

That's the language of failure. Technical debt strangles many products before they even get to market. The status quo of software development is that management won't face the facts of what software will cost so they chronically underestimate what an efficient software development effort would cost by a factor of two or three. Instead of laying out a realistic plan that will succeed, they embark on a hopeful plan tha…

Could we admit some nuance here?

When we want to stigmatize people who plan too heavily for the future, we call it "overengineering." When we want to stigmatize people who plan not enough for the future, we do whatever you're doing above. The line between those two failure modes is relatively narrow and not at all obvious. There aren't simple heuristics that will infallibly put us onto the line, and acting like this is all black and white doesn't help anyone.

Re: Developer inequality and the technical debt crisis

#95
post #86

Earlier quoted context omitted.

> The author is kind of all over the place, Yes. His article's intent is to describe a problem. He then tries to give examples of solutions, and they're bad suggestions. Still, he's right about the problem. We are in a kind of dark age at the moment, and the technology web stack is an unnecessary horror. Regarding databases, I think what you're proposing is a step in the wrong direction. Databases is one of the major…

"Databases is one of the major problems of our age, and cause of software being so difficult to get right." Strange. I think of databases as one of the bright spots in computing. They are very closely related to real business needs, and do a good job for the most part. MS Access was great because it also had a form builder and it could all work over a network[1]. That means you could get a small business organized ar…

I had a think about it over the day, and decided that what you're proposing would bring power to users, and be an improvement. Focus on content rather than presentation, power to the users, less layers. Thanks for a considered reply.

Re: Developer inequality and the technical debt crisis

#96
post #87

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

My guess is that you have not written a line of COBOL code. I have seen great systems written in COBOL. My guess is why COBOL never caught on in the PC world is that COBOL is very much suited for batch programming. There were a few tries with a visual form of COBOL, but the tool set was very expensive and the alternatives were cheaper and more suited to events (for instance Turbo Pascal, Turbo C, the Microsoft produc…

> I have seen great systems written in COBOL.

That's not really the point. The problem is not that you can't do something great. Every Turing-complete language has the capacity to do that. You can write a great program in Brainfuck.

The problem is that they encourage you to do something terrible. I have seen COBOL programs that I did not wish to see. Good languages make it easier to do the right thing. They provide strong type checking even for user-defined types and well-tested abstractions (like templates/generics) so that you don't have twelve copies of the same function one for each expected input, each slowly diverging and multiplying under maintenance and developing their own subtly different bugs.

Re: Developer inequality and the technical debt crisis

#97
post #72

Earlier quoted context omitted.

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…

I think I'd be fine with an opinionated partial solution, even if it wasn't too popular. But I don't really see anything like that.

What about Macaw? http://macaw.co/

Re: Developer inequality and the technical debt crisis

#98
post #91

Earlier quoted context omitted.

> The software itself is usually no more complicated than it needs to be; the issue is that the things we want to do with the software are themselves very complicated. Ok, take these requirements: I want a web app that counts the number of times users click a button. Users should be able to see the number of times they clicked and I should be able to see a top 10 of the highest click counts. To do this I must know HT…

This is almost exactly Meteor's "Leaderboard" example [ https://www.meteor.com/examples/leaderboard ]. Not much code goes into that, and I think it's pretty approachable for a non-programmer.

Until something doesn't work. And it's not their code that's at fault.

How many frameworks is this sitting upon in the 'cloud' ?

Re: Developer inequality and the technical debt crisis

#99

Earlier quoted context omitted.

I think I'd be fine with an opinionated partial solution, even if it wasn't too popular. But I don't really see anything like that.

What about Macaw? http://macaw.co/

General purpose design tools are again the equivalent of DTP (and very welcome), but not an app solution (unless I have completely misunderstood the audience Macaw is for).

Re: Developer inequality and the technical debt crisis

#100
post #65

Earlier quoted context omitted.

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…

"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." Well of course that's the job of the programmer. The programmer is supposed to build something that does something useful. Most of the time, the primary value of the code isn't that it's GOOD, it's that it DOES THE THING. Oh, sure, at the level of (say) the Linux kernel you can almost think of i…

Purpose and status aren't linked.

There are programmers who without direct day-to-day management produce code that is valuable to the business, and programmers who receive comprehensive managerial attention and produce code that costs the business.

Post reply on HN