No such thing as “real programming” (2015)
brightball.com
brightball.com
I ended up jumping all the way to the other end of the "stack" -- web front-ends. Webdev has been a side-hobby of a sort for quite a while, and I pretty much expected it to be a lot simpler than the low level systems programming that I've been doing.
I've been doing web client and server programming for some time now, and I can without a doubt claim that it poses its own set of challenges that compare and oftentimes exceed in complexity to those encountered in the "lower level" programming fields.
I think the entire notion that one type of programming is more "real" than others comes from lack of perspective. Once you dive deep into more than one development layer, use case, architecture, language, or community, you realize that the challenges each one faces are as varied, unique, and interesting as the rest of them.
I'm a math major turned 'full stack' dev with an eye on embedded dev as my prize- I needed this comment.
Making a LED blink on a microcontroller is just about as difficult as showing an intermittent alert in a browser window. It may seem harder because you need to know a little more about the abstraction layers underneath, but those are things that you can pick up just as quickly as JavaScript.
Designing a high-throughput data interface system in FPGA (which I'm doing now) is at least as hard as doing a high-throughput back-end infrastructure for a web service. I can barely do the former -- I sure as fuck can't do the latter right now, regardless of how "real" my programming skills are. When I read through a paper on the latter topic, or watch a presentation, I can mostly understand what it's about and appreciate the technical prowess, but doing something like that myself would likely be a quick lesson in humility.
If you like what you're doing and you're creating programs that do useful, or at least spectacular things, you're a real programmer.
With web programming a lot of the difficulty is self-inflicted by the industry. To get a web page up you need to know at least two different abstractions (HTML and CSS) which aren't clean or well-designed and have more warts than a skin care clinic.
Then, to fix their limitations you need to use js.
Then, because there's a lot of repetition in web dev, you have to use a handful of js frameworks, which currently outnumber the stars in the universe, and each has a production half-life of around six months.
And then there's the server side.
And if you get all of that working you have to run at scale, with adequate security.
And can we have it in green and make the logo bigger?
So of course it's hard. It's like being trapped in a novel by Kafka written in XML.
No it's not. In real life, it's fairly rare to write 100% bare-metal applications, and even when you do, you're often writing against some "homegrown" abstraction layer. Sometimes you're expected to write such an abstraction layer, but writing only against the hardware-defined "API" is usually not strategically sound, unless you have a very good reason to assume that the underlying hardware will never change. This is sometimes true for very resource-constrained microcontrollers, and virtually always true for things that have ARM in their name and stronger. Not to mention for embedded, but relatively high-power devices (see e.g. the Linux kernel).
Sure, the drivers are hardware-specific, but the applications are usually programmed against their (unitary) interface.
I'm not arguing against the rest of what you mention -- I'm painfully disappointed by the neverending spaghetti of technologies that modern web is, and I also think it's largely self-inflicted. However, web dev is treated as much more of a commodity than other branches of programming; left to their own devices, there are a lot of web developers who would produce very good client-side code.
Shit like bootstrap isn't there because web developers are incompetent. It's there because much of their job involves churning out support code for products managed by people who know nothing about technology and the WWW, whose quality standards are dubious at best and who value product conformance over performance because they sell perception, not quality.
On the other hand, if someone has spent years feeling bad that they don't know lower-level programming, they need to get over themselves and spend a few weekends learning assembly or something. There's no reason to feel bad about this, take a bit of time to expel your ignorance.
Yes, as defined by most people.
Succeeding in life in the eyes of a select group of people including yourself, is something else entirely.
I grew up programming and had my BASIC, Pascal, C++, Delphi and C# phases, I like web development (generally, the tooling sometimes sucks but as a platform you have global reach), I'm also well past the point where I worry about "real" programming or whether I'm a "real" programmer - I can solve any problem I run into by research or buying a good book, there are domains I'm completely oblivious too (for example 3D programming and quite a lot of the machine learning stuff).
The systems I build solve problems and provide value, that value might be in making someones life easier (which is what my current side project will do) or automating a business process (my favourite was an engineer management system I built for a small company a few years ago, they've now grown to ~20 engineers and are still using it, they've filed 3 bugs in 3 years - literally the best work I ever did and at the time I thought it was average).
Programming is such a vast field and there is more out there than you could learn deeply in a life time so I try to stay abreast of what's going on by watching conferences online and not worry too much about measuring my e-peen. (latest one is Code Mesh https://www.youtube.com/playlist?list=PLWbHc_FXPo2jB6IZ887vL... which has some stunning stuff).
If I have a particular strength it's that I enjoy the process of meshing what the client thinks they need with what they actually need and finding the intersect, often clients don't realise what they can gain from software and the simple business suggestions can be huge, I wrote a system for a company that used NCR pads they had to get custom printed, this required the field engineers to keep the pads in stock, they where filling them out by hand for every job and it was expensive and error prone, I suggested instead that we generate the PDF's with everything prefilled in and duplicate pages which are sent to the engineers by email, they can get them printed wherever they are either on site at the clients or any place that does print from disk, this saved them a lot of money, it hadn't occurred to the client that this was possible - so now they assign jobs to an engineer, the system generates all the paperwork for that week and they just require a signature from the client who keeps one copy while they keep the other.
Given those requirements, your only choices are Java Sandboxed Apps, Flash and the Web. Which would you choose?
It evolved from a deliberately dumbed-down mechanism. Much more sane options existed back than, but for reasons unknown (laziness is quite likely) a choice of a technological foundation was very much random.
I do remember web from its very first days (used to work in an institute with some very tight connections with CERN), and even then I was wondering why such a good idea is going such a non-optimal way.
And, well, it was not quite "evolved", it followed the trends set exactly by this lot - by the web devs. So I cannot see who else should I blame for this mess.
> Which would you choose?
If I had a choice, it would have been Tcl/Tk in a sandbox.
- Inadequate or high-effort tools. This is half the challenge of the embedded world, and the cause of "I've destroyed my tools with my tools!" https://www.usenix.org/system/files/1311_05-08_mickens.pdf
- Complicated business requirements ("do this every second Tuesday if there is an R in the month, but not if the customer is using the US VAT system and not if the product is a type of cake")
- Critical system requirements (remember, using Java to control your nuclear reactor violates the license). People working in this environment can easily get elitist about it, until you look at their code and find Toyota spaghetti.
- Problems that require Actual Maths or Actual CS, with known solutions. Rare in the webdev world until someone remembers about ACID; more common in the embedded world if you need control systems.
- Problems with unknown solutions. Actually extremely rare; often the first line of attack involves Matlab or Excel or some other "not real programming" technique. Often the smart domain experts you need to solve the problem are not also very good at software engineering.
IME the first two take up 80-90% of the working day. The third is only applicable to some industries.
Different people are better at different types of challenge. This doesn't matter unless you're trying to construct some sort of total ordering over human beings in order to feel better about yourself.
And yes, most useful prototyping tools for me were far from C++ and alike - I used Maxima, Mathematica, various Lisps with tons of batteries. Also not a "real programming".
#1 Just because you're constantly tackling interesting problems doesn't mean they're super common. Most of us seem to be working on an application meeting some trivial business need.
#2 Just because you don't know the answer doesn't mean the answer doesn't exist. The world of development is filled with 20 somethings getting paid huge sums of money to learn and deliver something completely alike to all the other things they think are really different.
You probably fit into one of these categories, if it's the first then congrats, because that sounds like an interesting life.
I still cannot understand what justifies re-solving a solved problem over and over again? Solved once? Automate it.
> Most of us seem to be working on an application meeting some trivial business need.
OP says it's somehow "not trivial". For some weird reasons.
Anyway, if the workflow is trivial, if required components are standard, if no customisation is required - it does not need any engineering at all. List those initial requirements, infer the implementation automatically. It is hard to comprehend why the CRUD world is so reluctant to do such an easy thing.
> doesn't mean the answer doesn't exist
It may exist in some highly secretive labs, but in most cases it cannot be found in any of the papers or preprints.
It is odd, isn't it? I'm tempted to say if you think it's so easy, go forth and do it: automating away the production of CRUD would earn you billions. SAP is probably the nearest existing product. But every attempt so far just creates a different group of developers (e.g. SAP).
I cannot stop shaking every time I interact with pretty much anything designed by supposedly high profile specialists. There is no single day I do not run into an astonishing stupidity. Daily commute? London Oyster system is such a thoroughly shitty design that it is nearly unbelievable. Shopping? It never works as one would expect, and is always far too twisted - all that Amazons, Ebays and alike. Healthcare? Just super stupid, stupider than the trashier of the comedies. Yes, they "automate". They decided that a doctor should not type or write, to save a valuable time. They're expected to record everything on a voice recorder and pass it to an assistant for typing. Guess what? They type or write first, because it's easier, and then read it aloud. Shall I go on?
This world is a pile of stupid shit, throughout. And expecting that something that definitely should have been automated or eliminated altogether would have happened is just totally naive.
And if someone really do automate all the CRUD needs for 80% of the possible users, they'd never know anything about it. So why bother? They must grow up and automate it themselves, it's dead easy.
I largely actually prefer the code way, believing it's much more flexible, sane and safer. However, the problem is the average person who understands these rules is scared of the code, and the average coder is much more interested in solving a lot of inconsequential problems.
This makes it much harder to pay someone in who's just going to sit down and churn out your CRUD and when folks find these guys, they're either keeping them happy or think they're easily replaceable and will have a fall later on.
I'm doing devops at a big org at the moment. They have several dev teams working on bespoke low-traffic resource managment applications. Most of these have 5 developers, devops, delivery manager, user researcher, designer in addition of going view a technical review process, pen testing, performance review, and functional testing.
Basic math suggests that's going to come out at about £350,000 per project over 3 months. A million quid later, they've all passed reviews without any of these so called highly technical people realising they're dealing with a common problem and that they're developing 3 of them. Also they're all shit because they're done by MEAN stack tech hipsters who haven't quite realise they're leaking important data.
There are more options than just these two. The best way is to write your rules in a nice, readable, dense DSL, designed specifically for that domain experts who know the rules but are afraid of code. And such a DSL can be very much free form and forgiving, helping a lot along the way, so the experts won't need much assistance.
With such an approach, developers (i.e., those who are not afraid of code) are either not needed or only concerned with maintaining this DSL, while the experts can code their rules directly. It eliminates unnecessary elements of a chain, and cuts costs quite significantly.
And then you realise there's no consistent definition of "cake" in the system. And when people in the business say "US VAT system" they actually mean "Regulatory system XYZ", not actually anything to do with the US.
Sigh.
This makes sense for embedded: you want to save every penny since it's a high volume business, the chip manufacturer wants to save every penny , there's a huge amount of variety in chips - so in the end development is hard. Without all those requirements, heck maybe something like the arduino/mbed would have become popular among professionals.
But as for webdev ? not so much. The critical factors are time-to-market and development cost. And in the domain of web based business apps, we already have useful high-level tools[1], and it seems to be technically possible to improve the situation in consumer facing apps too.
So where are the tools ?
[1]http://ww2.mendix.com/rs/mendix/images/gartner-magic-quadran...
Of course, embedded programming has gotten a lot more complicated too. When I started, we had to fit our programs into 4K of ROM. These days an embedded program often includes a full Linux stack.
The author seems to engage in the same behavior, but conflates the "get things done fast" with the production solution.
If you're a good programmer and your preferred tool is PHP, then you're engaged in "real programming." If you insist on using PHP as a deployment solution because it's what you're familiar with rather than because it is an appropriate/optimal solution to the problem then you're engaged in laziness.
A good programmer can adapt their mental models and adopt the tools necessary for the problem domain. A bad one always has an excuse for why their comfort justifies tool choice.
However, if PHP is not appropriate, that in-house PHP talent does not change the fact that PHP is the wrong tool.
I've never worked at a company that used Delphi, but I have complete confidence in my ability to use the language. If a person doesn't feel confident in their ability to pick up C, they are missing something from their toolkit.
The nice thing about PHP is that it lets you play with these abstractions _even when you are starting out_. For eg, a redirect in ruby/sinatra would be `redirect https://google.com`, but stock PHP would want you to use the header("Location: https://google.com"); variant[0]. PHP doesn't abstract out the web, but lets you build on top of it. Its close enough to C so you know what is happening and how things are working (or atleast its easier to figure out), and still dynamic enough to get shit done.
There are problems with PHP's design, sure. But these are getting fewer and fewer with things like PHP7/Composer and the entire ecosystem still evolving. And believe it or not: there are problems with _every programming language_. Just pick the right tool for the job, will you.
[0]: I know comparing sinatra to PHP isn't ideal, but I am yet to see anyone code in pure CGI in Ruby.
1. Type Safety (string? int? boolean?)
2. The Runtime Engine (apache? nginx? linux? windows? what file system?)
It's not because of impostor syndrome, or any sort of psychological underdog complex. It's simply the awareness that there are gaps in what's often expected to be a hermetic seal. And knowing about that, would gnaw at the edges of just about anybody's confidence at a subliminal level.
e.g. Going from PHP to NodeJS, NodeJS is a lot more direct and less abstracted (handling the request directly, reading the request data incrementally and handling reader state, setting headers and then explicitly writing to the buffer, handling connection state, etc.) - note I do mean NodeJS here, not something like Express
another e.g. PSR-7 I find is, counterintuitively, actually much less abstracted than raw PHP built-ins as it goes out if it's way to map the interfaces to the stack as intended, rather than completely arbitrary weird abstractions. Like the retrieval of query parameters being entirely separate and unrelated to retrieval of the body payload, whereas PHP tends to sort of conflate these things in $_GET/$_POST/$_REQUEST and then doesn't really have obvious intuitive handling of non-x-form-url-encoded payloads. And don't get me started on query string array handling.
I do completely agree with the article though, and I still use PHP a lot. Voluntarily.
But I just found your specific observation surprising.
The PHP abstractions are not always clear as you rightly point out (REQUEST = GET+POST+COOKIE...), but they are vastly different "magic" that you see in the Ruby land, for eg where you would rarely be ever thinking about cookies at all.
Which is actually a broken abstraction, because in most PHP SAPIs that doesn't actually spit out a header line directly. Instead, it's parsed into its components, and PHP additionally sets the HTTP status code to a redirection one.
- talk to a datacentre, get servers, switches, power, network racked and ready to go.
- Do the devops to configure this infrastructure. - Understand data-layer requirements and generally host and manage a CP or AP system.
- Write the apps that'll live on these servers.
- Implement resonable caching to scale.
- Write the frontend code to implement a design to connect to these systems.
- Have enough knowledge to profile and debug the performance bottlenecks of such systems.
At about that point, you can start to consider yourselve "full stack". Now some could argue that you don't need rack the system or do the devops, but if you don't understand what you're hosting on, how are you ever going to debug an issue that outwith your application?
So a programmer actually wrote flowcharts. That was the high-level language used back then. These flowcharts would work on any computer, and what a coder was, was a human compiler for those flowcharts."
Alan Kay @ SAP: https://www.youtube.com/watch?v=vXjpA9gFX5c
The quote is from the last few minutes, before the video cuts off.
I diagram a lot of things. Mostly for my benefit. I have struggled over the years with what symbol do I use for X but now I just pick a rectangle or predefined process rectangle and label it well. Diagramming helps me get my internal thoughts out and makes the systems I write better and less error prone.
Personally, I can't even really think about complex business/application/system logic without drawing it out on a whiteboard.
The speaker, Mary Shaw, talks about Design Guidance, and how a decision chart is "a better organization of a body of design decision knowledge" [starts 27:40] and how we still, desperately, need something like that, and that there aren't any better ways to communicate such knowledge, that the speaker is aware of, than "this ancient chart."
(UML is mentioned later, but under the context that it is dying, which was probably a good thing.)
[1] Progress Toward an Engineering Discipline of Software https://www.youtube.com/watch?v=lLnsi522LS8
There's a recent talk [1] by Mary Shaw from Carnegie-Mellon University (CMU). It's about what has happened since the NATO conference in 1968 (dubbed the Software Crisis), and what engineering means in software engineering.
According to their survey, the American workplace consists of ~90 million "casual" programmers, and ~2.5 million highly trained software engineers, and there's a need to get more programmers into the engineering aspects.
[1] Progress Toward an Engineering Discipline of Software: https://www.youtube.com/watch?v=lLnsi522LS8 There's a link to the slides in the description of the video.
I don't believe that statistic for a second, unless we're using some convoluted definition of "programmers" which includes anyone who can open Microsoft Word.
That would mean half the labor force can program. Ludicrous.
Looking at the slides[1], I'm pretty sure you interpreted that wrong. There are 90M end users of software, not 90M "casual" programmers.
[1] http://gotocon.com/dl/goto-amsterdam-2015/slides/MaryShaw_KE...
Please see the relevant part at 49:50 [1], but I'll bring it in next.
The speaker pretty much defines "end users"/casual developers as people who do programming like things; "There are something like 90M people out there who are doing 'programming like things'; they are building databases, they are building spreadsheets, they are using scripting languages, they are building sophisticated websites--what are we doing to help them?"
It's a broad category, but I think the confusion is that programming is not simply about writing code, it also includes the overall architecture, and design of a system.
So what I get from this is that end users means anyone who didn't go through the academic channels to learn the engineering aspects, and that's who they need to reach. The speaker had a link to their software engineering programs at CMU [2] in an earlier slide.
Also, see the context in view of the stackoverlow survey--which doesn't add up if you look at the numbers, but the speaker explains it's because some people reported in more than once.--It sought to be an example of how "end users" end up doing "programming like things."
[1] Progress Toward an Engineering Discipline of Software https://www.youtube.com/watch?v=lLnsi522LS8
[2] Software Engineering Masters Programs http://mse.isri.cmu.edu/software-engineering/
http://www.brightball.com/business/what-exactly-happened-to-...
In gratitude, I'm going to be a nice guy that avoids the PHP vs "real" languages part of the discussion. :)
My post above is of course also tiresome and pretty uninteresting, but it doesn't pretend to be otherwise.
That you ignored the obvious compliment embedded in that... twice... was tiresome. I won't let it bother me, though. Just helping you follow along. :P
that it admits I could drop bombs on PHP, even while considering him a real programmer, but kindly and unusually don't due to a rare moment of respect given the story I read.
PHP is well worn territory, discussion of who is a real programmer or not is just dick measuring.
I agree on the dick measuring aspect. Far as the language, the critiques of it on a technical, semantic, whatever level are well-worn. Yet, they rarely counter PHP with alternatives and suggestions that align with PHP users' preferences and goals. Same for Visual Basic 6 and Excel macro communities. The bombs I'd drop on it would be from that perspective.
I rarely see people on HN and elsewhere doing that when the subject is PHP. Hard to tell where it would be on the spectrum between working my ego and my usual function of pushing people in directions that meet their goals while maintaining a better baseline in software quality, security, extensibility, and maintenance. Undoubtedly some of both but people steadily benefit from those kinds of recommendations. Often other readers rather than person I'm talking to.
I wrote that up mostly as an explanation for a lot of local people who'd asked me for the whole story over the years.
Another time, though. :)
In 2003, Rasmus who created PHP said: "I have absolutely no idea how to write a programming language, I just kept adding the next logical step on the way".
PHP has since been developed into a fully fledged programming language borrowing many of its traits from Perl, C, C++, Java, Tcl.
Now at PHP7, having two major versions since 2000, I can say with some confidence that PHP is a "real programming" language.
Edit: do downvoters really think the original PHP implementation was not a pile of crap?!? Amusing!
Web development is very transparent and in the spotlight these days, so it's exposed to a lot of criticism. I wonder how many cases of "smart programming" do we have in C code-bases around the world...
Selling software for my own companies for almost two decades, wait, exactly two decades, I've never had a SINGLE customer ask me "what language is this programmed in".
The closest you'd get is anyone running a non standard OS (anything besides Windows).
I mean sure, making a WordPress site with themes and plugins is not as complicated as coding a web app in Node.js or whatever, but the majority of business sites don't really need much in the way of complexity. Just a few pages that the client can add content to and maybe a blog on the site that might send the content to social media sites upon being posted. In those cases, why not use WordPress or another simple CMS system?
On another note, this is also kind of the reason I haven't really gotten the chance to use much in the way of the latest or fanciest technology. Because every idea I get turns out to be one that doesn't need it.
Thankfully, most of us don't spend a lot of time doing that sort of thing these days (even in the embedded world).
I also feel for anyone who ends up using an upside-down air can to debug shoddy solder joints on a BGA device ;)
"God is real, unless declared integer."
I've learned a lot about programming from a friend I worked on a startup with. But the business part suffered since the focus was on coding instead of the experience for the end user.
I have friends who are brilliant programmers who made excellent startup employees and friends who know little about programming who are excellent startup founders. I’m not even sure the best programmers make the best startup founders. A friend of mine was amazed when I showed him how to view source code on a website. His startup just raised a million dollars.
I think this has to do with the fact that people who don't program can't focus on the code. They focus on solving the problem.
Sometimes the right solution might be to build my own solutions but since thousands of people are constantly telling me that I'm not a real programmer I doubt my own ability to do it.
People complaining that web developers aren't real programmers keeps web developers from learning programming. The thought that web developers aren't programmers paradoxically keeps me from becoming "a real programmer".
Because my work doesn't count as real programming I have to start every new "real programming" challenge thinking that I don't really know what I'm doing. This creates doubt that limits my ability.
I feel confident in my ability to build what I want on the web but I'm actively doubting if I'm a real programmer.
Most of the web development work I do involves building interactive programs for helping people cope with mental health problems. My clients only care if I solve their problems. Previously we had a super advanced custom built system that was a mess to deal with. I recently switched back to Wordpress because it is way more effective.
I also think another reason developers don't like Wordpress is that it levels the playing field between people who can and can't program. Suddenly anyone can do what it took you years to learn.
People telling me I can't program because I work on the web makes me a shittier programmer because it makes me nervous when I write code that is logical. It is harder for me mentally to write javascript for my application then for writing the css or html and it's not because the logic is harder. It is because I mentally fear that I don't know how to program because the internet keeps telling me I can't. But every time I do it it turns out that I can.
I can feel it in my body when I switch to the js file in Atom. The feeling is fear.
I don't have it for: setting up a new ubuntu server, building a responsive website, styling with css or working with Wordpress because I know this is web development.
I can't mentally figure out what to think about building apps in swift. There is a lot of logic so that is technically "real programming" but there is a lot of styling so that is technically not programming. So I guess I have a moderate fear for it.
My point is that this isn't about the fact that it is harder to write logic then html or css. This is about my own fear. And the idea that web developers can't code makes it worse.
I actually wrote something related to this on my website. https://birgermoell.com/2016/01/30/solve-your-problems-throu...
Anything.
I am not sure about other countries, but in NL and DE, for big companies, I see the complex & inflexible (Java) Enterprise CMS software being replaced by WP. Often not openly and company wide, but departmentally for sure. We get asked to consume the content in the 'big corporate' CMS via a webservice or even scraping and when that's done and the WP site runs and can be used to run that part of the site, they ask corporate hosting to do some proxy passing and rewriting. To illustrate (I cannot name names ...), let's say you have an international online retailer and the ECMS contains a different site per country like:
https://retailer.com/nl/... https://retailer.com/de/... etc for all countries they are in.
Then the NL dep asks us to recreate their /nl/ site in WP with the content from the ECMS and then they proxypass/rewrite /nl/ to the new server which contains the WP installation.
Why? Because WP allows, for 'low cost' and 'no real programming' to add all the features they want and to allow workflow-free fast updates when they have a special or deals or contest or whatever specific to that country. Not to mention people understand how to use it right away; no courses needed. With the ECMS that all runs via the head office and that workflow is too hard to change so this is much cheaper/easier. Sometimes they don't even really notify the head office but just do it on their own servers. This same thing happens in many companies / institutions that have many 'sub-sites' managed by different regions/countries/verticals.
It works, it makes clients happy and the fact I don't like WP (at all) and the fact I find this kind of thing rather boring not to create code (like you would in Django or Ruby) is not really interesting; the average 'corporate' WP site we deliver has 1 custom WP file with functions the guys who set everything up and integrate the design reuse and (rarely) append.
I would say that if I was to name something real or not real programming, this would be it. And yet it makes a lot of money and, more importantly, it makes clients happy & productive without extremely long processes of implementation.
Edit: Other than that I agree with the article; it is a matter of taste though. Like said I would not call these things 'real or non-real (fake)' programming but I do choose to not do most of this work myself as I like embedded and native mobile work better. That keeps clients happy too anyway.
It's also one of the reasons WordPress (and quite a few other CMS systems that are sometimes looked down upon in the development world) caught on... because they were easy to modify and mess around with for people withot prior programming experience.
There's plenty of work for everyone. No need to call what other people do "trivial" or demean them for not "automating" something after having done it once.
FWIW, automating something can easily be a job orders of magnitude more difficult than doing the original job. It might require capabilities and resources which far exceed what is available at the organization.
Moreover, automation is a complicated continuum of solutions. If you're talking about REAL WORLD computing problems more complex than can be handled by a bash script, NO, you don't automate after solving a problem once.
And the only thing organisations are lacking is sanity. The rest is trivial, proven many times. I will regard all of them as lowly and stupid, because this is what they are.
See my rant elsewhere in this thread - this stupid world is full of examples of idiots in charge.
Are you trying to convince me that the morons who designed Oyster are not morons and I should not judge them? No way. They are scum. Should not I judge the deranged NHS bosses? No way! I'd be delighted to see them beheaded, no less. Their incompetence cost human lives.
And I hate it when people are trying to play down the stupidity of others. In my book there is no sin worse than stupidity and incompetence.
Won't you deny that most of the idiots out there cannot code at all, although they call themselves "developers"?
See even the high profile apps for Android for example. Say, "BBC News". Millions had been spent on it. And this shit locks when internet connection is lost. Don't the retards who wrote it commute on a tube? Don't they know how to code asynchronous UIs?
And don't let me even start ranting about the British Gas "Hive" thingy.
The spread of the ignorance and stupidity in this world is unforgivable. And I won't ever be polite to the stupid and ignorant. They're worthless and they deserve the most harsh criticism possible.
Those retards did not even think that ticket machines may be available beyond the oyster barriers, but this is very common on many suburban rail stations.
And if they were not such scumbags, they did not even have to think about all that at all. There are trivial formal methods to analyse all possible workflows. The fact they were oblivious of such methods is unforgivable. The incompetent uneducated retards should never be allower anywhere near any technology.
Actually, no, you specifically said "once".
But that's OK, this appears to be an emotional issue for you.
Attached to each of the letters in the acronym of C.R.U.D. may be arbitrarily complex rules and constraints that can take many man-years to implement, have mission-critical risks, and require maintenance for decades.
ERP's are "crud" applications, are they trivial? Perhaps in your view, admittedly they are shit for end-users and seem "unforgivably" stupid. Well, there's an opportunity for you to become a billionaire in short-order, implement ERP's and make Oracle your bitch. Not up to the challenge? Then perhaps refrain from calling the world stupid.
And yes, ERP is a pile of stupid shit. But you need an army of morally deprived Oracle-style salesmen to sell shit to the world. I know it well, worked a lot with the Oracle "partners" in the past. Oracle is a synonym for "overengineering".
By taking this discussion in an uncivil direction, you provoked a flamewar, which you then jumped into and made worse ("this appears to be an emotional issue for you"). This breaks the HN guidelines. Please don't do that.
On this site, if you can't address yourself respectfully to the person you're responding to, regardless of how wrong they are, it's best to wait until you can.
We detached this subthread from https://news.ycombinator.com/item?id=11048119 and marked it off-topic.
Most of the frightingly hard problems you're solving should have never existed in the first place. And yes, web devs, it is your fault, your collective responsibility. Web could have been nice. You screwed it.
I have to admit that I did not do any web development
...
I also know about it from interaction with frontend
developers themselves and from toying around it
So no, it is your astonishing ignorance here. You should stop pointless personal attacks and provide only rational, technical arguments. This thread is already such a code monkey circlejerk that there is no value in adding anything to it.
Know why? Because there is no place for democracy in science. It does not matter how many people believe in some crap. As long as objective criteria exist, as long as a formal proof is possible, any number of millions can believe in whatever they fancy, and nobody should care about their idiotic fantasies.
And it is dead easy to prove that something is overengineered. You may not know it, with such a background, but complexity is a well defined, objective, measurable thing. If you're curious, look up what an "Algorithmic information theory" is.
An existence of a formally simpler model with a more flexible functionality is a very clear evidence that the other, more complex system is overengineered. Just compare something like Tcl/Tk with your awful web stack.
And should I go into Javascript, the heart of your entire stack? This is pretty much my speciality, I am a PL specialist, so you cannot accuse me of an ignorance here. It is very easy to prove how bad Javascipt is, how horribly it is designed from all the PL-theoretic points of view.
Occasionally I do some paid blogging for Codeship too.