Just a few ways available technology has determined where we spent lots of development time.<br>
<br>
In the 60's we went to extremes to optimize code to fit in small RAM's and run efficiently. In the 70's we went to extremes to make efficient use of expensive disk space. In the 80's we worked overtime to limit the actual amount of traffic over communication lines in order to provide response times that users would wait on. In the 90's we have trained an army of network administrators to deal with the finicky nature of LAN's & WAN's.<br>
<br>
User expectations went way up with the introduction of the PC. My corporate customers want to know why my custom developed accounting apps don't have all the neat user stuff of Quick Books (never mind that they need multi-user, multi-location and integration with other custom apps, a distributed corporate database, etc.<br>
<br>
So here in early 2000 what do we developers of business apps prepare for? I sure don't know, but I must bet on my guesses. Her are my current bets:<br>
<br>
1. Microsoft will continue to own the desktop for the plannable future (3 years?).<br>
2. Continued declines in equipment costs will make practical techniques now beyond cost justification. Included will be objects "floating" in RAM with full knowledge of database contents, business rules, etc.<br>
3. Encapsulated resuable code will be the primary key to more efficient development of functionality userswill demand.<br>
4. Networks will become as stable as mainframes and minis, and will require little more user administration than operating systems do now. (I really do hope much for this one).<br>
5. CORBA and/or DCOM may not be the long term answer, but are a sure bet now for preparing for what is next.<br>
6. As important as technical knowledge is, our knowledge and understanding of the real requirements of our apps will always be more important.<br>
7. Much of the above will be off the mark. I wish I knew which parts.<br>
<br>
What are your guesses?<br>
<br>
In the 60's we went to extremes to optimize code to fit in small RAM's and run efficiently. In the 70's we went to extremes to make efficient use of expensive disk space. In the 80's we worked overtime to limit the actual amount of traffic over communication lines in order to provide response times that users would wait on. In the 90's we have trained an army of network administrators to deal with the finicky nature of LAN's & WAN's.<br>
<br>
User expectations went way up with the introduction of the PC. My corporate customers want to know why my custom developed accounting apps don't have all the neat user stuff of Quick Books (never mind that they need multi-user, multi-location and integration with other custom apps, a distributed corporate database, etc.<br>
<br>
So here in early 2000 what do we developers of business apps prepare for? I sure don't know, but I must bet on my guesses. Her are my current bets:<br>
<br>
1. Microsoft will continue to own the desktop for the plannable future (3 years?).<br>
2. Continued declines in equipment costs will make practical techniques now beyond cost justification. Included will be objects "floating" in RAM with full knowledge of database contents, business rules, etc.<br>
3. Encapsulated resuable code will be the primary key to more efficient development of functionality userswill demand.<br>
4. Networks will become as stable as mainframes and minis, and will require little more user administration than operating systems do now. (I really do hope much for this one).<br>
5. CORBA and/or DCOM may not be the long term answer, but are a sure bet now for preparing for what is next.<br>
6. As important as technical knowledge is, our knowledge and understanding of the real requirements of our apps will always be more important.<br>
7. Much of the above will be off the mark. I wish I knew which parts.<br>
<br>
What are your guesses?<br>