Back in the early 80's my company brought in a mainframe code generator called Pacbase (vended by some French company, and later acquired by IBM if I recall correctly). I don't believe my company uses Pacbase any more, and I don't know if IBM even supports it anymore.

What I remember is the VP telling us about this exciting new tool. I remember the exact words as if it were 2 minutes ago: "You just feed Pacbase your specs, and it creates the program for you." This was delivered with a satisfied smile because naturally this simple statement said it all.

What I learned was that Pacbase obscured the "coding". You interacted with IMS online screens, where you put in something along the lines of "mv a b", and Pacbase magically coded that for you in COBOL ("MOVE A TO B.").

There, isn't that easier, only feeding Pacbase your specs?

Bob, your point is very well taken. Even if some magic compiler were able to take something more abstract like "Analyze the last 6 months of inventory and report instances where the reorder point was higher than necessary at least 6 times", there will always be a role for the human to do the requirements gathering and analysis.

And, I don't expect to see in my lifetime a compiler that will accept as input the kind of "spec" I just used as an example. Maybe I'll be proven wrong, but I bet I still have a job, if a bit of a different one (as long as I'm capable of adjusting--I hope I am).

"even when they themselves aren't entirely sure [what they want] until they talk it through with a professional."

And even then they might not be sure. In my experience, users don't *really* know what they want until they get their hands on a thing and use it for a while. I've come to expect that we'll be tweaking for a while when we roll out new functionality. And I think it's a good thing.

I think this becomes more and more a matter of definitions.

Does a compiler really need to be cryptic to make the user a "programmer"?

Lets say we have a "natural language" compiler that will take the words that a user types (or says) and "compiles" it into a "program". Will it be able to do this 100% correct 100% of the time? I seriously doubt it because of all the nuances of "natual languages". Someone will have to understand the nuances of the "natual language" compiler and what words to use to generate the correct program. This "someone" will be a programmer ... although with a much different "compiler" than in use today.

Software Programs (Engineers?) will be around for years (maybe centuries). The languages and tools we use may change, but our goal will stay the same. Getting computers to do what people want.

I agree that the human intervention will not go away. But I also want to point out that 'report-generating' software is also being sold the same way - that the end users can create these grand glorious reports all by themselves without needing a programmer. But I say that unless the end user is programming-savvy, all that report-generating software is just a big unneeded expense as it will not be used for more than a few very minimal reports, and the end users will wind up fighting with it and complaining about it.

I remember when they were trying to generate metrics for programmer productivity. There is no question that writing software is one of the most labor intensive jobs today.

One measure was lines of debugged code per day.

Then I remember reading about "function points".

If you were to take that viewpoint, then a spreadsheet with macros was a much more efficient method of writing code than using a programming language such as Fortran.

I would argue there are a lot of people who create spreadsheets, some of them very complicated, who have never compiled a line of code.

Then I would ask some of those who have had to generate a mainframe application based on that spreadsheet to comment on just how well designed that spreadsheet was.

Remember the days of Assembly? Then along came C, which just put a layer of abstraction on assembly. That's all these "automation" tools do. They do the mundane tasks, so that developers can spend more time being productive on writing the actual guts behind the code the tool wrote.
Human software development will not go away for a long long time.

Isn't there some truth to a future where programmers roles change and code generators are used for basic progrmming tasks? Hasn't that time already come?

I started may carreer writing lines of code and tweaking for speed but in corporate America that will not be respected. We need to focus on generating business solutions fast and CASE tools are a great way to start.

Isn't the form designer in MS Access a code generator? Imagine the lines of code to create a button and OnClick method when you can use a tool to handle the "nuts and bolts" and string together the business logice instead.

Furthermore, the younger generation entering business will have more computer knowledge and training than todays executives...they will need less hand holding to get what they need.

YES...we will still need programmers but their role needs to change to developing new tools for users to service their needs.

Application Development Without Programmers, by James Martin, 1981

Wish I had kept my copy of this book instead of throwing it out. Would have been as good as a copy of "The Earth is Flat".

I agree with you, Bob. The magic compiler comes around every few years. It's the compiler that enables a business person to produce his or her own programs. My first such compiler was actually an interpreter: BASICA, which came with the original IBM PC. It enabled me to do wonderful things, and I was not (still am not) a programmer.

Next cycle, it was pfs:file. Then dBASE. Then Access. In each iteration, I had to learn something new about programming. In each instance, the outcome was that I max'd out my skills and had to turn to a programmer (or several) to produce the programs I really needed.

Higher level languages are great. Ambitious business people use them until the need for real programmers is stimulated. Maybe Morrison really has another nifty tool for us biz folks. But what does that really mean?

Programmers, get ready to catch us when we reach the end of the next higher-level-language rope...

The programmerless code generator has been and will continue to be a fantasy of management for quite some time to come. It won’t be a reality at least until the day that computers are smart enough to replace management.

What the managers who buy these things do not realize is that the “spec” that they think they are going to feed into this thing isn’t really a “spec” at all, but is an abstract idea of what they’d like to see on the other end. On almost every project I’ve done over the last quarter century (sounds longer when I say it that way) I have been the one who has in fact developed the “spec”. For all practical purposes, the databases and source code I generated was the “spec”.

As long as that remains the norm, programmers won’t be going anywhere before managers do.

I believe the first programming language that was supposed to do away with programmers was FORTRAN. And it did - to a limited degree, but there are always new problems to solve and no language is going to be the best for all of them or even useful for most of them.

This idea just keeps coming back again and again. The new one may be a good tool that will take the market by storm, but it will not eliminate programmers.

Remember "IT doesn't matter" and the "main frame is dead". And what about all those poor COBAL programmers who either didn't see the light or couldn't adapt to change, you know, the ones who are now retiring after a long carrier.

The infrastructure is crumbling around us, my youngest graduated college last year, I have a small stack of freedom chips. I think it's time to start building that tiny sailboat I have always wanted. I could be finished by spring, May is so delightful for sailing. I'll be around until then. Maybe I will take along a COBAL book in case I ever have to come back.

"Keep the Joint Running" if you can. Good luck, y'all gonna need it.

The issue is that businesspeople just don't think like computers. Computer professionals are trained to think in terms of what the computer requires, but almost no one else is.

So fantasy #1 is that the IT department is a barrier, hindering business. While that may be true in some cases, a lot of the time businesspeople themselves don't really know what they want. They just know they want something "better". This is OK, but it's just the first step on a long journey to a better system.

Fantasy #2 is that businesspeople can develop an adequate set of specifications for the magic compiler. Nope, for the most part they can't. Or they don't want to, once they learn what is really involved.

Most people's idea of a set of specifications is a disjointed group of scribblings on a napkin!

There will always be computer technical people. The tools they use will get better and run at a higher level. The micromanagement of absurd system details is slowly receding into history. But the idea that a general businessperson is ready to step in and fill this role - hah! They already have a job to do. And this isn't it.

I've been in IT since 1981. I was a mainframe COBOL/CICS programmer. We used a database called IDMS, which had a development environment called ADS/O that could be learned by non-programmers to develop screens and have them collect data into database tables. It worked for basic functions, but when something broke or wasn't working correctly, you had to go into the code to fix it anyway...and then you realized that nobody knew how it worked.

I also maintained a huge set of COBOL programs in the early 90s that were created by a code generator. It created programs that contained about 30-40% of unused code in each program and still required a team of three very competent programmers to make changes to it.

Today, as a guy who manages a small IT department more than does the programming himself, I look for simple languages that can be coded quickly, but effectively (we use Cold Fusion for web pages a lot), use our own templates, style sheets and include modules to eliminate repetitive programming tasks and generate applications that make our employees more effective at their jobs using a very small IT team.

The points made above are correct: Understanding the business and how to convert requests into useful solutions has become as valuable as the programming skills. Also, folks often don't know what they really want until they see what they don't want (even if it is what they described originally), so we often knock out a quick prototype for them to shoot at. I have been telling business executives for years that your most important people in your IT group are the analysts who know how everything ties together. You can always find programmers to implement the requests, but I will be surprised to see requests become so routine that they can be totally generated automatically...and the actual coding tasks may be simplified over time, but I don't see the need for flexible, adaptable programmers going away any time soon.

As a programmer, I'm about as concerned about the automation of programming jobs as secretaries should be about the paperless office.

These advances are always coming, but hardly make us obsolete. They make us more capable and efficient so we can focus on the creative work humans do best, leaving the repetitive mechanical work to automation.