|
Hello,
BTW, I think in business programming (from the management/end user point of view) the first criterion is usually does it work? The second is how fast can you write it?
You're right. Though, I think the second criteria is actually "how much will it cost for you to write it?", which often translates to the amount of time.
Good program design isn't even a nice to have. If you need to take longer to design a good program than to slap something together that will work.....Of course you run into problems if the program needs to be extended or changed to reflect changes in business rules but...
True, but for someone who is proficient with program design, it doesn't take any longer to do it right. Indeed, he'll be quicker in the long run, because he'll already have routines from the previous job that he can re-use.
The hard part is convincing people to do undergo the learning curve necessary to move from "monolith" to "proficient in modular program design". Particularly when there'll be a period of time where the latter takes longer.
This, actually, is one of the great strengths of RPG. Since it has all of the tools of the previous generation of RPG, as well as the more advanced tools, you can keep working as a monolithic programmer while you experiment and gradually move forward.
It's also one of the greatest weaknesses of RPG, since so many people get frustrated with learning the new stuff, and never move forward.
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.
midrange.com
