Just to add my 2 cents worth to this. When one writes a large system with many things happening (potentially) at the same time one needs to code extremely defensively. This means protecting against all kinds of potential problems that have the opportunity to arise. As well, trapping if they do arise and writing a log or other ways that you as the programmer (because users will not tell you) are informed of the issues that you never thought would happen (because they will). Hopefully your logs (or other means) give you enough information so you can track it down and write the code better.
The alternative I lived through many years ago with my own code. As the application grows the strange behaviour grows. Tracking it down becomes near impossible. Therefore we had to go back in and write the code the way we should have written to begin with. Lots of back work, but all of us learned - hopefully. Therefore creating standards of code, standards of methods, documentation, etc that are ALWAYS done. This is so that the ‘not likely to happen’ just cannot happen as far as you know because of the defensive code you have written. Still though - being notified so you can look back at your code and the data at that site and get that Ahh moment and write the code even better. We implemented a feature set with an OEM product we had installed at many sites >100 with many 100+ concurrent users. We would collect various ‘problems’ at each site, and each night all the sites ‘called home’ and we recorded them in our local server for this feature. I could then look at these and be proactive in understanding what was happening that was a surprise. It might mean there was no problem, but we could write things better so that the issue didn’t occur. It could mean that there was a problem and we wrote our code to protect that. It could mean speed, convince, better user interface. All in all a great tool, and learned a lot about our code, coding, and user interaction with our system. I may be paranoid, but I find writing protective code a better way to rest at night, weekends, and holidays knowing that the code is written well, though it takes much longer to get it that way (why I like our shell). Version 15 and version 16 are giving us a great set of commands so that we can write more defensively than we could before. It is giving us new features that let us write things we had to jump through many hoops to accomplish and ensure got done. Part of it for us is that our shell was based on a version of 4D with version 11/12. Our new shell is taking advantage of the new versions of 4D. An exciting time for us. Jody ********************************************************************** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:[email protected] **********************************************************************
