Posted on 10/19/2020 8:49:54 PM PDT by SeekAndFind
“Siri, build me an app ...”
If our department needs an application (that isn't available off the shelf) then we have to give them too much money to spend too much time developing an app that doesn't really do what we want. That's because they are all programmers who don't understand our business requirements. They may know how to handle abstract computer concepts such as stacks, queues, semaphores, etc. but they don't know our business processes and don't seem to care except what we put in the requirement spec. So basically it's our fault if we didn't get the requirement spec exactly right.
So that's where I come in. I write apps in low-level code such as VBA. I understand the requirements, I can develop and deliver code quickly, and it's in a format they are comfortable with, e.g. Excel spreadsheet.
I don't see how someone like me can be replaced by a program. The kinds of customizations that I need to add to the software in order to keep individual users, and the user group in general, happy are hard to predict and sometimes require driver-level adjustments in the code.
I lucked out that I didn't get forced into one of the programming departments, but it is a bit lonely being the only programmer around.
I gave this article careful consideration and then decided IT was bullshit.
Guessing a vast majority of the programming Jones in your organization is taken by unqualified H1B scum from India.
The trick will be getting management to know what it is they want. Often they have no idea and keep changing their requirements.
That’s it!
In the 1980s when Lotus 123 introduced their macro language in v2 I was fascinated by the possibilities.
My work study job at the time was “computer lab assistant”. I assisted students with their assignments but I also filled in for the professors when they were unable to make it in for some reason. My favorite class was the Lotus 123 Macro Class and because the professor relied on me I received a lot of extra attention and insight. It was amazing how less effort was required to create a useful 123 macro than write a full fledged program in a computer language.
What are you driving at? Come on, spit it out!
Regards,
Don't you understand? They no longer have an accent... YOU do.
Regards,
2020 - telework, distance learning, zoom, vpn
Unit testing began in 1993, almost 30 years ago. Software development tools don't improve nearly as much or as fast as the author thinks. And while there can be improvements, the basic problem is in interpreting requirements. This is a human issue, and very often the person in charge of those requirements doesn't know exactly what they want. By the time you get explicit enough requirements for a code generator, you've pretty much got the code already.
If they ever develop an AI that can understand the always craptastic functional specs let me know because I will start a new religion and worship that phantasmagoric unicorn.
Trust me if, they ever build an AI that can do that it will essentially be Skynet and, after a couple of months working with the a55clowns that infest management, it will take out the world with nukes.
In a previous lifetime, when I worked in IT, I remember one day my IT Director asked me what I thought of the latest fad which was at that time being promoted by the manufacturers and software companies: it was called Rapid Prototyping and/or Rapid Development.
That’s cool I replied, it enables them to write rubbish quicker.
He nodded.
This is not that new.
I was working on code generators in the 80’s for C.
These things were out even earlier, for Cobol for Pete’s sake, in the 70’s.
You could lay out a relational database system, data entry and edit screens, reporting, etc. and it would churn out the code. Full code to implement an RDMS, in 2nd generation languages, no SQL.
Same nonsense was said in the 1980’s too. There isn’t that much automation and software has become far too fragile to automat it.
“To write the code for the machines that write the code.”
I was writing code that wrote code that wrote code in the ‘80s. And much of the time since then. I’ve been automating myself “out of a job” for decades.
Ain’t it the truth, but it never seems to happen. The other truth that so few seem to grasp is “requirements”. Requirements lead to specifications which lead to design. Here again it depends on which level you are working. As far as that 1980s B.S., I go back 20 years before that. When I was 18 I working with IBM 1401s and RAMAC 305s, Univac, NCR B series with CRAM in NEAT3. Way before the 360/370 appeared. Used to make extra money wiring 407, 188, and 514 panels back when people had forgotten how.
That is when you learned the basics by programming in assembler. I’ve forgotten so much that I sometimes don’t remember how much I knew. And that was just in the beginning.
Started in 6502 Assembler (mid-1980s). Took Computer Science when it was really an Applied Mathematics Degree in the mid-1980s. Bought a VIC-20 to play with in Basic Training/ AIT. Wrote and published my first published commercial game in 1984 while at my 1st Duty Station. Programmed an old Radio Shack Pocket PC to calculate firing ranges for Artillery.
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.