Comment The problem with amateur software isn't the tools (Score 1) 283
I disagree with this guy that HTML is real programming (it's formatting, not programming, and if formatting work is programming then Wikipedia's editors are some of the world's most prolific coders!).
However, I do agree with him that spreadsheet programming is real programming (as well as other programming done using similar tools), and that programming done by an amateur is still real programming/coding, even if no "code" is involved (and frankly, there usually is some code involved even if it's dressed up as something else).
After all, I was programming at age 14, long before I was a professional, and while my old work is terrible it was still real programming. We don't want to make programming even harder for new people to learn with an unwelcome attitude towards learners and people who are not as serious. Having more technical people in the world makes it a better place.
I once had a professional task that was most easily solved by a spreadsheet, so that's the tool I used. We then spent the next few years properly developing the software that replaced said spreadsheet, but in the meantime it was able to shamble along and get the work done, and it served as a template for the final system which has endured. It was also critical at freeing up time to work on the real system. There's nothing wrong with getting a prototype out there that can solve a business problem now, even if the limitations keep it from being more than a temporary solution.
Plus, sometimes that really is all you need, as what really matters in the end is getting the work done. Our profession's typical obsession over long-term maintenance has grown out of the fact that we spend most of our professional time on maintenance, and having software built on solid foundations reduces that burden dramatically. Plus, you never know what "temporary" thing might become permanent ahead of time. However, this general rule of thumb about what's important isn't always applicable, such as when we need software that solves a temporary problem.
Anyway, the "problem" with amateur software isn't the tools being used. A good developer can make clean and effective software even using spreadsheets, while someone who doesn't know what they're doing will make a mess of software even with the best tools and languages.
This is one of the key areas where rules systems messed up, they put a big emphasis on getting domain experts to develop the rules, since it was tempting to the people paying for these systems to only have to pay wages for the domain expert, and it seemed plausible. However, what really happened is that you had people who didn't know how to write logical rules about their domain making a huge mess of amateur code, even when they had domain-specific languages and rule systems to help them out. Once these complex systems of rules got too large and unruly, they simply couldn't be maintained anymore and evolving domains rapidly made these rules systems obsolete.
While rules systems do have other issues, especially for sufficiently complex domians, having the domain experts working with professional programmers leads to a far better outcome, because the programmers know how to keep the system from getting cancerous. They can see when decisions are going to lead to maintenance problems and bring them under control by abstracting them or phrasing the problem in terms of easier to maintain data (or bringing in some relevant hardcore math that a non-expert wouldn't even know about).
The problems this article talks about have the same kind of "professional amateur" problems that rules systems faced. Domain experts are having to write their own software to solve immediate and real domain problems, and since they don't know how to develop software their solutions are hot messes that barely shamble along for now. You know what though, that's okay, the problems they are throwing together this software to solve are not going to go on forever and ever. Even if we continue to face the underlying problems for years, eventually some professional developers will develop tools to solve these very specific problems. So, it's not really a problem at all.
Go domain experts!
Just don't forget the value of the professional software developer! This writer can get off his high horse, tarring our whole profession as something simple that we're somehow complicating so we can make more money...