Companies Are Developing More Apps With Fewer Developers (fortune.com) 163
Fortune reports that the "yawning gap in tech skills" has resulted in a surprising shift in supply and demand in the software industry. And in many companies now, a growing trend of developer jobs being given to non-developers can be seen. From the article: That's because a relatively new technology, known as low-code or no-code platforms, is now doing a big chunk of the work that high-priced human talent used to do. Low-code platforms are designed so that people with little or no coding or software engineering background -- known in the business as "citizen developers" -- can create apps, both for use in-house and for clients. Not surprisingly, the low-code platform industry, made up of about 40 small companies (so far), is growing like crazy. A recent Forrester Research report put its total revenues at about $1.7 billion in 2015, a figure that's projected to balloon to $15 billion in the next four years. Low-code-platform providers, notes Forrester, are typically seeing sales increases in excess of 50% a year.The report cites QuickBase, a company whose low-code platforms are used by half of the Fortune 500 companies, as an example. Its CEO Allison Mnookin says that almost any employee can now do most or all of the same work that developers used to do. Mnookin adds that there's a big advantage in this. "Opening an app's development to the non-techies who need the app removes misunderstandings between the IT department and other employees about what the end user needs."
fill in the blanks (Score:5, Insightful)
Re:fill in the blanks (Score:5, Funny)
Companies Are ______ With Fewer ______.
Cards against Humanity: Developer Edition?
Re: (Score:1, Insightful)
Apps!
Re: (Score:1)
Companies Are making more money With Fewer employees.
What did i win?
Re:fill in the blanks (Score:5, Insightful)
Companies Are making more money With Fewer employees.
What did i win?
You won the layoff, your CEO won a $15M bonus. Congratulations.
Re: (Score:2)
As long as the remaining employees include the proper quotas of ethnic minorities, females and those self-identifying as non-traditional genders I don't see the problem.
(AmiMoJo is busy today).
Re: (Score:3)
Companies Are ______ With Fewer ______.
Put me down for "wasting time and money" and "people who know what they're talking about to catch mistakes early", please.
The best example of this I've seen so far was an exercise in futility developing a simple in-house process automation system, essentially a glorified database with a bit of e-mail integration and a pretty browser-based interface.
There were literally months of discussions among a team dominated by middle managers. Along the way, they spent approximately a mid-level developer's annual sala
Re: (Score:2)
Like that delivery routing system that the ex-ex-ex-ex-CFO's nephew wrote in the school holidays, which doesn't work for the third of the city that was built after 1987 and nobody knows how to extend it because it's all hard-coded spaghetti?
Re: (Score:2)
This will drive pay down (Score:1)
Re: (Score:3)
Re:This will drive pay down (Score:5, Informative)
Excellent point. As more tools like this appear from the aether, the value of developers will decline.
History says otherwise. Tools that make people more productive cause those people to be more valuable, not less. A developer that produces 10 apps per year is going to bring in more profit than a developer that produces one app per year, and can thus command a higher salary.
Rising productivity does not cause poverty. It causes prosperity. If your brain is too dysfunctional to realize that through logic, then just open your eyes and look at the world: Countries/regions with high productivity: America, Western Europe, East Asia. Countries with low productivity: Ethiopia, Niger, Pakistan, North Korea. Do you really think the latter group have benefited by avoiding "job killing" productivity improvements?
Re: (Score:2)
Re: (Score:3, Insightful)
Yet another case of someone attempting to apply an absolute to a real-world problem. The historical trends you cited only apply to a situation where a significant number of human beings in the "world market" (such as it was) were in need of goods/services and could be counted on as customers; in other words, an anomaly. Do not expect the trend to continue.
Once productivity outstrips demand (or rather, quantity demanded at any given point in time), continued increases in productivity only devalue labor, si
Re: This will drive pay down (Score:2)
Your logic only holds true if the consumer part of the equation was a robot instead of a human. What you state has been historically repeated many times. Yes _some_ jobs will go extinct or pay far less. It's called "change". Has happened many times in the past at smaller and larger scales than what you describe. But the economy overall truly benefitted from all sorts of productivity increases... Some of which society forwent and banned (child labor) and was perfectly fine.
Anyway back to humans. Human dem
Re: Demand (Score:3, Insightful)
Oh, wait... I wouldn't. I'm tired of that old chestnut of infinite wants, limited resources going unchallenged. The first is only true over time and the latter is generally true over a fixed period of time.
Re: Demand (Score:2)
I guess you, your siblings, and your cousins also share one car because your grandfather only had one. How about one house? How about the number of phone lines or TVs or PCs?
Maybe it isn't true for you but most of today's generation owns more cars, buys more than one car, and even more than one house compared to their forefathers. The number of TVs, PCs, cellphones, airline trips, etc have all increased per household. Demand has most certainly increased and more so than a static curve to population grow
Re: (Score:2, Insightful)
Productivity gains almost always boil down to a transfer of wealth from labour to capital. The economy as a whole might benefit in an abstract sense but that hasn't helped actual people much in the last 30 years. We now work longer hours for less buying power.
Re: (Score:2)
It tends to balance out if there is meaningful competition. At least for those goods where there is no bottleneck for production and competition can drive down prices.
For instance, my own salary has seen only minor increases over the last ten years, but there are also a lot of cheap offers for technology stuff. Food and housing have seen more price hikes, but I can still live with those.
And if it wasn't for politics supporting capital over labour, things would look even better for the "working class". A lot
Re: (Score:3)
If your brain is too dysfunctional ...
I think your reasoning is too simplistic - throughout history we have seen many times, how increased automation means job-losses for the people whose skills are being automated; I can't see how anybody can explain that away. Automation quite often also leads to loss of variation - products become more uniform, because a machine always makes it in the same way, and is able to produce in huge quantities; some would argue that this is another downside. However, it is true that over time the increased productiv
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
I remember when "fourth-generation languages" were supposed to revolutionize development in much the same way, back in the 1980s. I'm not old enough to remember when COBOL was supposed to do the same thing around 1960.
And, in fact, non-developers got the ability to do some stuff that previously required developers. However, this freed up developers to do more interesting work, and didn't seem to depress developer employment and pay.
Natural progression (Score:4, Insightful)
.
For example, what I currently do in a LibreOffice spreadsheet used to require one or two developers to write the software to do the same thing.
Now I just open a spreadsheet, enter some numbers and do the analysis myself.
Re:Natural progression (Score:5, Insightful)
You have better tools to do more things but those tools came from skilled developers.
In the "apps" world what I see is indeed more and more apps, about 95% or more of them crappy. Unskilled developers produce bad apps. Yes, that seems to be the trend.
Re: (Score:1)
You have better tools to do more things but those tools came from skilled developers.
In the "apps" world what I see is indeed more and more apps, about 95% or more of them crappy. Unskilled developers produce bad apps.
Let them be. They will come crawling back to us when these crap apps start eating their margins.
Re: (Score:3)
You have better tools to do more things but those tools came from skilled developers.
In the "apps" world what I see is indeed more and more apps, about 95% or more of them crappy. Unskilled developers produce bad apps.
Let them be. They will come crawling back to us when these crap apps start eating their margins.
Not to mention the stellar security that these apps will come with. A motley crew of Russian or what have you hackers will clean out their databases and/or bank accounts before they have a chance to crawl back.
Re: (Score:2)
You have better tools to do more things but those tools came from skilled developers.
Absolutely. But once the tool is written, it can be widely used without the need for a skilled developer at each user's location.
Re: (Score:3)
You have better tools to do more things but those tools came from skilled developers.
Absolutely. But once the tool is written, it can be widely used without the need for a skilled developer at each user's location.
Entirely correct, and that's the purpose of well-crafted tools. The tool user, however, must understand the purpose and limitations of said tool.
Even the most well-crafted tools are subject to abuse by unskilled users. I don't mean someone who uses a spreadsheet to add up columns of numbers or balance a few accounts. I do mean users who (as one example) don't understand databases and so use their spreadsheet as the basis for some thrown-together, integrity-free, error-filled system. These are the users for
Re: (Score:3)
In the "apps" world what I see is indeed more and more apps, about 95% or more of them crappy. Unskilled developers produce bad apps. Yes, that seems to be the trend.
So, what you're saying is: app appers only app apps? Not Luddite software?
Re: (Score:2)
So, what you're saying is: app appers only app apps? Not Luddite software?
As someone who "back in the day" coded extensively in assembler language, I've always been partial to Luddite software. Let's hear it for Fortran II !
Re: (Score:2, Informative)
Yep visicalc is an amazing program. Oh wait you mean something recent!
I have been doing this awhile. I have also converted a few excel spreadsheets to 'real' programs. It usually took many months and undoing of bad ideas.
Programming spreadsheets usually exemplifies the worst of the worst in programming methodologies. Usually poor separation of control and data. Meaning it starts off fine. But eventually ends up very difficult to change anything for fear of breaking something else.
Re: (Score:3)
I have also converted a few excel spreadsheets to 'real' programs.
I used to do this as well. I always felt like a dermatologist trying to get a raging, untreated-for-three-years fungal infection under control.
The phenomenon of accountant/programmers is a tragic one. The ones I encountered were all generally smart people, and once they started using Excel to build programs of a sort, they discovered they really liked it, way better than their real job. Which means, of course, that they probably should have been programmers all along, instead of whatever they ended up be
Re: (Score:3)
In 1987 I was "programming Lotus 123" for an engineering office, because the engineers were too busy in meetings and travel to be bothered learning how to do their job with "user friendly" spreadsheet software.
Re: (Score:2)
Which is no problem, unless internet or important (Score:4, Insightful)
Having people writing scripts to make their job easier can be great. Sometimes you don't need to actually know what you're doing to write software.
It only becomes a big problem when either a) it's exposed on the internet, where hacker bots hit it a thousand ties per day (headline: Acme Corp exposes 12 Million Credit Cards) or b) the data is actually important to your business. Example you write "rm $file", that's no problem until someone puts a * in a file name and it deletes everything in the folder.
If it's going to be on the internet, or deal with mission-critical data or resources, it's good to have it done by people who know what they're doing, who know what the common errors are and how to avoid them*.
* Not everyone with the word "developer" in their title is qualified. Does their education include systems development, or do they have a chemistry degree?
Re:Which is no problem, unless internet or importa (Score:4, Interesting)
Multi user too.
Writing some macros that tie word and a spreadsheet together might work ok for the non developer that created it, but once multiple people start using it, the fact that the author didn't know anything about mutex or acid or race conditions will be a re-run of the mid to late 90s all over again.
They know all about about acid (Score:2)
> fact that the author didn't know anything about mutex or acid or race conditions will be a re-run of the mid to late 90s
Some of the code I've dealt, it appears the author knew all about acid. And mushrooms. :)
Browser apps (Score:4)
Re: (Score:2)
Probably includes almost nothing but those type of apps, with maybe a few 'plugins' (read, pluggable functions that are narrowly defined and compiled-in w/ no 'developer' intervention) tossed-in for good measure.
What I'm curious about is how much bloat a typical app generated this way carries, versus a decent/competently-coded bespoke application on the same platform.
Re: (Score:2)
Does that include apps that simply involve invoking a browser and opening the website of the application in question? A tactic popular w/ Microsoft in Windows Phone/Mobile
I prefer that to websites that want me to download an app. Looking at you, Yelp.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
We have these (Score:4, Insightful)
Sharepoint and InfoPath. This has caused nothing but more problems for us.
Re: (Score:3)
Sharepoint seems to be only slightly less productive than an e-mail folder and a shared drive somewhere on the network.
Re: (Score:1)
My job would grind to a halt without SharePoint (Im a lawyer). It allows you to track changes in documents and basically annotate a "folder" in any of a.hundred ways. You cant do that with a shared driver folder. For law firms where 30 or 300 lawyers might touch a document its absolutely a lifesaver. Email and a shared drive folder work fine when its like one or two people working on a file for anything more involved and you want SharePoint.
Smallish firms use lesser "litigation management systems" but they
Re: (Score:2)
There's this technology called "version control". It's rather nice.
Back in the day when sane people still used CVS, I put together a doc store based on CVS with a nice Windows plug-in. Word has a diff viewer, so you could present version diffs as if they used Word change tracking. Would be trivial to do that with SVN today.
Also, folders can have a "readme.txt" in them with all the annotations you want, but that's far too straightforward for anyone who would use Sharepoint.
Re: (Score:3)
I've used trac for about a decade now, and it does document revision control (using svn behind the scenes, I believe) - also hooks into svn or git repositories.
There's a funny thought: lawyers using git for document revision control. It could work quite well, except for the cultural impossibilities.
Re: (Score:2)
Office doesn't annotate well enough for law. Given the context nature of the problem, I would be shocked if SharePoint does either. There are special purpose tools for this (in the legal field).
I really have my doubts about the SharePoint groupie.
Re: (Score:2)
Office doesn't annotate well enough for law.
I think you need to be more specific than "the law". Our lawyers frequently use Microsoft Word for redlining contracts, works great. Sharepoint Document Libraries actually work really well for storing these. There are certainly lots of other systems that work as well, or better (ie Enterprise File Sync and Share Applications like Box, Syncplicity, etc).
Re: (Score:3)
This beer is for you, sir.
Isn't this what VB was for? (Score:1)
no body
Re: (Score:3)
VB, PHP(spit!), JavaScript... the commonality is the ease with which a neophyte can 'code' something, and in the process open some real nasty and easily-exploitable security holes with 'em (which reminds me... how does the TFA product avoid a lot of this?)
Right... (Score:5, Insightful)
Maybe it's because I don't live on the West Coast but I have yet to see or even hear about one of these platforms. Where I work, writing a SQL query flies over the heads of the majority of product managers and business analysts. QA requires a lot of hand-holding. I'm old enough to remember the days when the non-techies tried to write software platforms hacking VBA in Excel and Access and that turned out really well.
This is not a new promise. It's been made before and it seems this article is slanted towards one particular product the one I haven't heard of. I know people have been customizing CMS's with clever hacking to make them work for purposes they weren't intended like WordPress and Joomla and so forth but it's not anywhere near what it needs to be to meet real, ever increasing business needs. Heck, for all the progress that HTML5, CSS, Javascript/ECMAScript and all the MVC/MVVM tool stacks that sit on top of them, for most cutting edge companies, it still ain't good enough. They want the sun, the moon and the stars. If hard-core development tool stacks can't deliver it, these lo code/no code solutions sure as heck can't come close.
Re:Right... (Score:5, Insightful)
Where I work, writing a SQL query flies over the heads of the majority of product managers and business analysts.
This is pretty close to the core of a problem that can't be fixed with drag and drop tools. The core problem isn't writing code. That's the easy part that anyone can learn. The real problem is analysis, a skill that very few people (relative to the business population) have. All the code generators in the world won't solve that problem.
A good developer isn't a good developer because he can write code. He is a good developer because he can integrate the components of a system into a coherent whole. No programming automation system will magically teach someone how to do that.
As you've said before, we've seen this promise come and go more than once in the last 30 years. Like "cloud computing" and the dot bomb, this fad will peak and fall.
Re: (Score:3)
Re:Right... (Score:4, Interesting)
"Much of the essence of building a program is in fact the debugging of the specification."
Fred Brooks, No Silver Bullet
Re: (Score:2, Interesting)
Because MS FrontPage put millions of programmers outta job back in the day...
This is just a passing fad. We'll see what happens when the first big security flaw is exploited.
and they're abandoned in 10... 9... 8... 7... (Score:5, Insightful)
today's low-code shortcut is tomorrow's abandoned platform ... cold fusion ... delphi ... VB6 ... you name it, it's been abandoned ... placing bets on a fly by nite startup's platform is not a good idea ...
Re:and they're abandoned in 10... 9... 8... 7... (Score:5, Insightful)
10 print "Wow, I can make apps with this tool without hiring an expensive developer."
20 print "Oh, this tool only lets me make generic apps and none of the unique features I need; hire a developer."
30 goto 10
Re:and they're abandoned in 10... 9... 8... 7... (Score:5, Informative)
Delphi was and is not a low-code solution. It is a RAD environment where some really simple apps (i.e. the Fish app) could be built by dropping a few components on a form and linking the properties and writing a couple of events. But, most applications (and visual/non-visual component creation required coding skills.
What killed Delphi was stupid decisions by Borland/Inprise to move away from what they did best and become an "Enterprise" company instead of a developer company. They also concentrated on Windows-only development when other platforms (mobile, web, Linux, Mac) were becoming popular (see first f'up). And, they raised the price so far that even dedicated developers and can't afford it's stratospheric pricing ($2600+) - only Gods and birds can reach it.
The language is a dialect of Object Pascal (not in vogue despite its power). Delphi is the IDE and hasn't changed much over the years. It can now target Windows, Mac, iOS, and Android. Linux server is coming. It is very easy to create a highly complex, cross- platform application in a way that Xamarin can't touch. Performance for business apps is good. But, I have yet to see a real game written using it. And, good luck in getting Delphi into your IT shop these days (at least in the US).
Not until developers can afford it again and work with it to see its power (if they can tolerate the language), it will regain its market share.
Re: (Score:3)
Re: (Score:2)
The problem is that nobody can predict the future. Can you point to any currently popular language and say with reasonable certainty that it will be viable 15 years from now?
By the way, Java may now start dying due to Oracle's aggressive lawyers, and McAfee's by-default re-scanning the Java libraries every time you sneeze, and twice if don't.
Re: (Score:2)
On ColdFusion [Re:and they're abandoned in 10... (Score:2)
Actually, ColdFusion is still being sold, and has 2 or 3 open-source alternatives.
Its early selling point was easier web-page coding, and compared to what was available at the time, it was.
Then it became more known for making things simpler for HTML designers to integrate their markup templates with database data. And, it was and still is pretty good at that because you usually don't have to escape in and out of markup versus imperative code. In addition to the built-in CF tags, you can make custom tags for
Simple or disposable apps (Score:4, Insightful)
This'll work fine for very simple apps, ones that only require standardized functionality. But then, with an app like that, do you really need to develop a custom one for any reason other than branding/appearance? And it'll work for disposable apps, ones that do the current job but don't need to be maintained or enhanced down the road. That's been true forever, it's why spreadsheets and word processors had macro languages so secretaries and accountants could do simple operations and calculations without needing to have the programming team get involved. But the moment you start dealing with an app with complex functionality that has to be changed, enhanced and extended over time, that's when you'll discover that you need software engineers. It's the same reason anybody who can grab a hammer and saw can cobble together a sawhorse that'll work for one job, but you need someone who understands architecture and construction to build a house that's expected to last for decades.
Re: (Score:3)
Wasn't C0807 (I will not utter its name here) designed so that accountants could write programs? Then there was CASE, anybody remember that fad?
Yay, just write all your core business applications using MIT scratch!
Re: (Score:1)
One of the reasons that is may not have worked vis-à-vis the RAD platforms like Access and Excel is that the GUI part always looked polished irrespective of the quality of the program.
But, Scratch programs always looks like toy prototypes, so they never fool the non-te
Re: (Score:2)
So you get a a half-assed implementation and have to reverse engineer the spec from it? Doesn't seem like a brilliant idea to me.
There are a number o
Re: (Score:2)
If you say COBOL 3 times in the mirror ... Java appears!
Re: (Score:2)
Yes, but it may turn out that a large percentage of companies have needs that overlap. I think it's safe to say that wrapping databases in UI is not going to keep being a $100k+ skill for much longer.
Nobody cares if it'll last for decades. Most apps are not expected to deliver useful value at all by the people who order them. It's really only after the app has proven to be useful and profitable that the suits begin to think about longevity and scalability.
Now, repairing poorly made applications... That's go
Re: (Score:2)
Thank {{DEITY}} there's the "business logic" layer and "security" to keep us all over-employed then.
Next buzzword (Score:5, Insightful)
“You don’t need to know how to code in order to use them, but you do need strong analytical skills,”
Um yep. Knowing how to read and write a programming language is the easy part. Having the analytical skills to achieve the task is why we get paid well.
"low-code platform" is just another buzzword unless there is a difference between "low-code platform" and SAP, OBI, Sharepoint, infopath, etc.
Our Sharepoint developer also codes in C#. Sharepoint is just a tool for him.
Re: (Score:2, Insightful)
Um yep. Knowing how to read and write a programming language is the easy part. Having the analytical skills to achieve the task is why we get paid well.
Hell, I've watched developers break upon the rocky shores of analytics packages.
You're always going to be able to do more low-skill labor with less people - welcome to progress. There's never going to be a shortage of high-skill labor - welcome to continued progress. Most people who think they're high-skill, aren't, is always the problem - welcome to the human condition.
No-code is bullshit (Score:2)
Just because you are not writing C or Java code does not mean your are not programming. Low-code/No-code is just new buzzwords for high level programming environments which have existed for 20+ years.
And yes, a not of problems can be fixed by non-devs in these kind of environment basically because these problems are not really that complex but there is an enormous problem trying to explain the problem from the "business" environment to the dev environment. These low-code/no-code environment simply provide a
RAD is here! (Score:1)
Again.. Next we will dig up the tapes of those CASE environment sources and try to integrate those into the fold.
Speaking of QuickBase (Score:1)
I work at a company that uses it. It takes a certain developer mindset to go beyond the rudimentary capabilities of QB. Then, the poor decisions and ad-hoc work-arounds become apparent, making upkeep and extensibility difficult, if not, impossible. Then, if you wanna do something more advanced, like copying data from one table to another OR automating tasks OR using external data, you run into the hard limits of the application (lotsa "quickbase doesn't support that" from QB support).
Then, you're either stu
I've seen this kind of thing before (Score:3)
Looking at the links Google turns up for "low code". Marketing hype is all I'm seeing. This will be sold to CEOs the world over and it will fall short. Remember CASE? CORBA? 4GL? Visual Basic? Same smell.
RAD is 25 years old. (Score:5, Insightful)
Search for Rapid Application Development from the 90's.
Powerbuilder is one such tool that started getting built in early 1990's. What is old is new again.
It was all foretold. (Score:2)
What? A disconnect between IT and the users.
That's what the two Bobs get for firing the requirements guy.
Of course in the old days, the SMEs just bit the bullet and changed the world anyways.
let the avalanche of crappy apps continue (Score:2)
no skills coding, what could go wrong?
Skills that thrill (Score:2)
"“Almost any employee now can do most or all of the same work that developers used to do,” says Mnookin."
Yep, just like any employee can be trusted with the company's web site. Do you want your app to look like MySpace, because that's how you get an app that looks like MySpace.
Kind of like Electronic Health Records (Score:2)
Instead of having data entry people transcribing a doctor's notes we can give the doc an EHR and let him/her enter the data directly.
Nobody cares if we replaced a fairly expensive resource with a very, very expensive resource.
Journalistic nonsense (Score:2)
Let me guess: the author thinks readers would be pleased to hear that not even coders are immune to losing their high paying jobs so she comes up with a speculation about the future of software development based on minor blips on the tech landscape in very nichy areas, historical patterns be damned.
QuickBase is awesome... (Score:3)
...but the price is not. They have no serious competitors as far as I can tell, the market is screaming for competition. If you need to build a network-accessible database driven application that runs in a browser, it's really, really slick.
I was involved with a project to build a type of customer database using QuckBase - it would track and follow a customer's project all the way to completion, and multiple people with different roles could interact with it in various ways. Imagine Filemaker Pro or MS Access on steroids and network enabled.
To earn our business, QBase reps basically built the bones of the program in realtime as we chatted on the phone and watched via webex, for free and gave us a month to play with it at no cost. After that it was around $300 per month, so out of range of individuals but fine for businesses that can justify it with revenue.
I think there is a huge future for this market that's waiting to be tapped further. Right now it's a bit of a monopoly.
Re: (Score:2)
QuickBase has no competitors.. except for AirTable, FieldBook, Caspio, Xoricon, PerfectForms, MS PowerApps, Brilliant Database, Ragic, Google Sheets, Zoho, Glom, Credenza, Trello, Asana, the list goes on and on
"Seven Save Us All" (Score:2)
And some people are wondering why general sw quality keeps getting lower. I have some popcorn set aside for the days when these citizen developers will "develop" with tools made by other citizen developers and we can all watch their house of cards
Yawn (Score:2)
QB + Non-technical users = Clusterf*ck (Score:2)
The entropy that builds up from clueless users tying their business processes into these low-code systems is staggering. I have a client that got setup with QuickBase years ago and has been using it to store data culled from their web site and generate reports based on it, sometimes with an interactive UI to sort and filter. Because nobody who created these QB "apps" has any technical training, including the mastermind who set it all up to begin with, these reports are horrendous monstrosities that over the
Re:This has nothing to do with "skills gap". (Score:4, Insightful)
No, we will not see "programming disappear". This same stuff has been predicted continuously for decades now. People skilled in the use of tools are many times more productive than those who are unskilled. As the tools themselves get more productive, the skilled users become more valuable. What I suspect we are seeing here is the temporary drop in the usefulness of software due to phones and tablets causing the unskilled to be able to produce "state of the art". This is a temporary phenomena that will end when software and computers become more useful again.
Re:This has nothing to do with "skills gap". (Score:5, Interesting)
No, we will not see "programming disappear". This same stuff has been predicted continuously for decades now. People skilled in the use of tools are many times more productive than those who are unskilled. As the tools themselves get more productive, the skilled users become more valuable. What I suspect we are seeing here is the temporary drop in the usefulness of software due to phones and tablets causing the unskilled to be able to produce "state of the art". This is a temporary phenomena that will end when software and computers become more useful again.
I don't think we will see programming disappear, but I think we will see the low hanging fruit moving away from professional developers and into a generic white collar worker. Think about the progression of clerical functions - years ago you had a pool of typists, because it was both a manual skill that most office workers did not have, and difficult enough that it was worthwhile to farm it out to specialists (though in this case the specialists were cheap). Then we had word processing come in, and initially it was done by clerical staff, but the bar was raised in terms of what constituted "professional looking" output. Then the software became easy enough, and the office workers sufficiently used to typing and using computers that word processing as a dedicated job function has moved into a publishing role.
Now we have a situation where everyone is expected to be able to use a word processor, and while anyone can type up a simple letter or paper, turning those same people loose on a multi-chapter book that is expected to use consistent styles and formatting rules is asking for trouble. Talk to any tech writer or publisher, and you will hear horror stories about documents in exactly the same way we talk about spaghetti code.
Re: (Score:2)
Low-hanging fruit has been going over the wall to non-developers for a long time. When I first got into the profession, creating a simple report from what we had instead of a database would take a few days of my valuable time. Nowadays, we have tools so non-developers can create simple reports, and I do more interesting things.
Re: This has nothing to do with "skills gap". (Score:2)
I'm calling you out on the "far higher quality standards" bluff. I've worked with big name, cheap labor shops, and it was far from high quality, but it was delivered quickly and cheaply. For proof of concept and quick market capture they're an excellent choice but you'll have to recreate your product later when the tech debt grinds your product to a halt and loses you customers due to service outages and inability to fulfill changing business requirements.
Re:This has nothing to do with "skills gap". (Score:5, Insightful)
Back in the day, you had to move wires around to program and then someone had the bright idea of assembly. Then someone invented human readable code. And we've been programming like that for what? 60 years now? Programming hasn't changed much at all since then. We're basically writing code.
What nonsense.
I remember when "lines of code" was a widely-accepted measure of programmer productivity -- and the industry standard was single digit counts per programmer per day. That's less than ten lines per day per developer. And these were mostly programs for batch processing; some systems supported interactive use, where you'd type a command on a terminal, enter data in response to some prompts, and then see results. There was process-control stuff happening, too, but when a system executing thousands of instructions per second had to control a physical process, it wasn't very elaborate -- there wasn't time, never mind RAM, for much complexity. So, programmers thought really hard about each line that they wrote. (Are you old enough to have heard the term "desk checking"? Why waste valuable computer time trying to compile and run something, when it's got bugs that you should have caught with a few hours' review?)
By the standards of those days, most of today's code is profligate waste -- coddling the users, correcting their mistakes, presenting things in a way that's convenient to the user rather than the computer. But by the standards of those days, displaying streaming video or recognizing speech by comparing it against a multi-terabyte distributed archive of conversational snippets is bleeding magic.
And being able to invoke that power by calling a simple API? Oh, sure, that's exactly like duplicating your Quicksort card deck to add it into your current FORTRAN job.
Re: (Score:2)
automated so much that less developers are needed.
Wierd Al [youtube.com] would like to have a word with you.
Re: (Score:2)
Re: (Score:2)
For small-ish (non-enterprise) apps, the real problem with VB Classic was not really the language or IDE, but the deployment and DLL-Hell, especially if it used 3rd-party components. The installation and help-desk staff hated that aspect.