|
I think that tools will evolve (like Dreamweaver, etc.) that will make knowledge of the underlying languages nice to know, but the tool will do the work much better, faster and accurately than we can do today with current code generators. ------------- I disagree with this. In fact, it's so wrong it's scary. There still isn't a code generator today that can write a decent application; if there was, the whole world would be using it. And why is that? Because code generators don't understand the concept of an application. Fred Kulack has a great quote that he's been using for some time as his tagline: "The stuff we call "software" is not like anything that human society is used to thinking about. Software is something like a machine, and something like mathematics, and something like language, and something like thought, and art, and information... but software is not in fact any of those other things." Bruce Sterling - The Hacker Crackdown Software is still art, folks. I don't care what anyone says - when it comes down to the making of a great piece of software, it still requires that nutty, kooky kind of inspired madness that each of us has tasted at one point or another in our careers. Sure, I can probably design a DFU generator. It might even have a few cool rules. And then the end user can put together tables to their hearts contents and generate all kinds of pretty graphs. But when it comes down to designing a tiered pricing structure that requires rebates based on total volume sales not counting discounted items over the previous three quarters with a sliding scale based on the market penetration of the client, but with exceptions for direct sales sites who participate in corporate funded marketing efforts, well, I think I'm gonna have to call in a programmer. The art of making a business run with a computer is not about getting the end user to get the most out of a limited toolset, but instead it's about extending the toolset to let the user be as productive as possible. A limited feature set is fine in a word processor, but not in an order entry system. The ability to tweak payroll bonuses based on production statistics is crucial to companies trying to figure out how to properly apply incentives to a demographically evolving workforce. Work that crap into an Excel spreadsheet sometime. Everybody keeps comparing OS/400 and Windows, or even Unix. This works fine when you're talking about software as commodity, but the analogy falls apart when you're talking about software as custom designed tool. Where this discussion misses the point is where it is so focused on the price that we're forgetting that the customer will spend more for a top-of-the-line hammer, as long as they perceive it to truly be the top of the line. RPG and DB2/400 are still the top of the line for custom built business operations. If you think of each site as a lovingly restored and maintained classic car, then the software is the big red rolling toolbox that is used to keep that car maintained. Now, if the customer base decides that they need to go to fuel injection, then carburetor maintenance is going to be a declining market. But that doesn't mean that the entire marketplace is going to go out and buy Hyundais or Kias. UNLESS we refuse to learn how to maintain an electronic ignition. So what we need to do is figure out how these newfangled fuel injectors work. But we don't have to all become Hyundai salesmen. Instead, we need to learn how to make those fuel injectors really hum with that balanced and blueprinted 455 Wildcat engine we have under the hood. Enough of the metaphor. The point is that there is still a place for custom software, and we are the ones that keep that place safe. If we all throw up our hands and decide that some generated SQL code with a VB front end is good enough, then we're going to see the end of custom software shops, because frankly, folks, the new generation of Nintendo technicians can throw those together quicker and better than we can, and in short order companies like Oracle are going to have "application servers" that you can rent over the web that will be cheaper than anything a custom shop can provide (Oracle just announced this, BTW). And if we drop ourselves to that lowest level of standards, then the customer will by default go to the lowest bidder. But if we as a group design an architecture, or a set of architectures, that combines the benefits of a GUI with the flexibility of an n-tier structure and the power and maintainability of an RPG/DB2 back end, then we can still provide a reasonable, cost-effective service to the community. But sticking a screen scraper on an outdated order entry system is not the solution, nor is rewriting your legacy applications into yet another proprietary user interface. What's required is a lot of lateral thinking, a combination of a tactical quick fix and a strategic long term direction, that provides both a growth path into the new technologies while still taking as much advantage of the existing legacy programs and legacy programmers as possible. Or you can read up on Dreamweaver and polish your JavaScript skills, and ask Larry Ellison for a job. Joe +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.