Developer inequality and the technical debt crisis

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 describing the art of programming as being able to break a large problem down into small, solvable ones, but there you are.

I frequently find myself having to rescope my tasks, say "I don't know the answer to that, but I don't -need- to yet" or "That could go either way; let me just create a common exposed interface and cut off this effort at that point" etc, rather than create a bloated mass of abstractions to handle all the possibilities. It's the problem agile was/is supposed to solve in terms of method, and what functional programming is supposed to solve in implementation.

To be fair, businessmen are short-tempered and flightly. They're like 15-year-olds who love one band one week and hate it the next. You have to make impressions-- flashy ones-- quickly because they have no ability to judge code quality, and can only tell who seems to be working fast.

In this light, isn't the "get it out quickly" strategy (maintenance be damned) exactly what they've asked for? In an industry where programmers are business subordinates, not true professionals, should anything else be done?

I am playing devil's advocate insofar as I agree with you. (I also think creators worth their salt want to see their work through, which means they're already doing "maintenance" work by the time they're finished.) However, I don't see how anything else can become the norm, given that The Business sees us as a cost center and a commodity.

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

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 to build simple things without much coding. Oh wait, people already can build simple things, but....that's not what you mean?

The Web is actually a phenomenally easy platform to learn how to write code for, compared to basically every platform I've ever seen that came before it. Yeah, it has a shitload of quirks and stupidities and kludges, but that's what happens when you're building a system that gets used by a very large percentage of the global human population.

The author writes as though he's never actually considered that doing anything at scale - not programming, anything; running a train system, or setting up a government, or selling falafels to people at lunchtime - inevitably involves hacks, compromises, kludges and half-measures. "Technical debt" is just another term for "doing things that involve humans".

I've been working on a startup that addresses this.

It is best described as "a front-end as a service": use our interface and API to build a cross-platform native mobile app, with a matching mobile-friendly web app.

Targeting companies who need a cross-platform whitelabel app to reach their customers or employees, but whose core competency is not flashy front-end software. Although I haven't done in-depth market research on the topic, I figure that most companies want some sort of custom app, but not every company wants to try and manage a team of web and mobile developers to do that.

Let me know if anyone wants to meet up around SF and chat about this; I've been casually looking for a co-founder while I prototype and look for first customers.