So here is the last observation while looking back at 20+ years of(web) database application development. The fourth observation is aboutthe required developer knowledge investment. How much time do you, as adeveloper, need to invest in learning and taking on the tools withwhich you can build database (web) applications.
Similar to the DBMS (
observation 1)it was real simple to learn the application development tools in theearly nineties. All it took was one weekend of reading thedocumentation and trying out the software tools. In the Oracle scene,Forms 2.0 was really not a too difficult tool.
Steve Muench(as far as I know the "inventor" of the Forms product) did a real goodjob. Of course, it would take a year or two to realize how good theForms product really was: i.e. what it did for you, so you did not haveto worry about that (that = locking, preventing lost-updates,generating insert/update/delete statements, etc.).
Outside the Oracle tools scene you could also opt for "
third generation languages"in those days. Turbo Pascal, Lattice C, Fortran and the likes. Combinedwith Oracle pre compilers, which gave you the ability to
embed SQL inside the code, they would typically offer the possibility to implement performant batch-processes.
Then,in the early/mid nineties when (anonymous) PL/SQL was introduced in thedatabase (oracle version 6) Steve gave us Forms 3.0. A huge leapforwards. It also had a local PL/SQL engine. The reference guide for3.0 was more than twice as thick as the guide for 2.0 or 2.3. Do yousee the resemblance with observation 1? It would take a few weeks tobecome really productive with this tool.
A few years later,moving from character-mode to GUI-mode, (the infamous early releasesof) Forms 4.0 was (were) brought to us by Oracle. Which really tooktill Forms 4.5 to become stable. At this time other (third party)tools, such as Powerbuilder, Uniface, and maybe two or three othersthat I cannot remember anymore, were "hot" also.
By now theForms product had reached a level of complexity where using Forms"generators" really became the way to build applications. Generatorswere already available in the char-mode era (with Forms 3.0). I forgotwhat the product was called. I think it was Oracle Case 5.0.
Thesegenerators added yet another level of complexity to the tool-stack thatyou, the developer, had to master, in order to deliver databaseapplications. This however was solved by add-on utilities (headstart).Which again just added more complexity, if you ask me. Since youcouldn't purge your Forms (builder, design-time) knowledge. A 100%generation was unrealistic, unless you were the actual developer of theheadstart toolset. The majority of the projects always required"post-generation" development. And sometimes a lot so. Furthermorethere was the wholy grail of keeping the forms re-generate-able. Onlyvery, very, few projects managed to achieve that (and at a very highcost).
I used to be "all round". An application developer morethan a DBA. I did both. But I decided to quit being a developer whenCase Generator (later called Designer/2000 etc.) became the way tobuild apps, and move over to the DBA field. I knew forms inside-out,and was able to kick out screens really fast: I did not see how these"generators" were making my job easier. Of course I was alreadybuilding database applications in a (pre-version-of-the) Helsinkiapproach.
The developer toolstack then moved to Forms6.0 andForms6i: webforms. An applet running in your browser, dealing with the(client/server) forms. Obviously this was going nowhere...
Hence, here came J2EE...
Apart from the fact that it was way back to writing low-level code again, it was also code that was hard, no, really very hard, to read and thus, hard-like to maintain.
Overthe years J2EE became JEE,. Design patterns and frameworks gave us'lessons learned' and 'abstraction layers'. Writing low-level Java codewas replaced by configuring frameworks. Of course you still have toknow and understand Java, like you still had to know and understand theForms builder product. Not only Java, but more technologies: html,Javascript, XML, cascading style sheets, etc. And let's not forget theframeworks-du-jour.
So this is observation 4:
Theratio of "required knowledge investment" versus "produced output" fordevelopers is way off the scale nowadays. For the more young people outthere reading this blog: you have no idea with how little (compared tonow) technological knowledge we were able to build databaseapplications in the past. I also suspect that you find it very hard tokeep up with, and to have broad and deep knowledge of, todays "tools"that you are supposed to use when building these kind of (web) apps. Ifar from envy you. It must be horrific.
There is no way oneperson can grasp all the technological knowledge that is required tobuild these kind of applications today. This is why development teamsnow always consist of several (different) specialists. And of courseone "architect". The person to mediate and achieve consensus betweenall involved specialists. In my presentation I call the architect theperson to keep TPTAWTSHHTF (*) away.
This is the last observation I wanted to point out.
In summary, here are all four observations:
- The DBMS is finally mature, hence we-do-not-use it anymore.
- We still develop UFI's, but in a lot more complex manner.
- There is an ongoing YAFET technology explosion.
- The investment required for developers to become productive, has gone through the roof.
In future installments on this blog I'll refer back to these observations.
First we need to spend some time on J(2)EE.
Stay tuned.
