I have scanned through my email archive last night, and found a note from one of our ex colleque at Quest on his everyday life as a developer . Just would like to share with you all…
The note was written a few years ago, it is a good reminder to us all here that we must do our best to make life easier for our customers who are doing the same type of work as we are all doing at Quest - writting code - create solutions…, by providing you solutions/tools that will give you a better and more productive workflow…
" Day in the Life of an Application Developer
Application developers often have to provide production support. This is important because they will generally need tools that are useful from their remote PC (i.e. the licensing scheme and speed over phone lines) and often dictates when they’ll begin their workday. To assume an 8-5 daily work schedule is a mistake. If you’re on call, you can reasonably expect four nights in seven of being woken up mid night to resolve problems. Some of these problems can be solved using software via a phone connection, but about 20% of the time the problem requires the person to throw on some sweats and go into work early. We’ll focus on the problem natures in a moment.
For those developers who do get to work regular hours, again to assume an 8-5 daily work schedule would also be a mistake. If you’re not on call, you often have to arrive to work early in order to check on the prior night’s batch program execution. Did all the jobs run to completion? Where there any errors or warning requiring attention and a decision before end users arrive (i.e. business day starts). Did the on-call person leave instructions for the early morning staff?
So the early morning routine is to check your email, your desk, the on-call person’s desk, the project manager’s desk and the project white board for any notes on issues needing immediate attention. Often, a call to the operations center to double check is prudent. Then you either TELNET onto server and review the batch logs or FTP those logs to your PC for inspection. There are generally three kinds of problems: data related, program related or schedule related.
If the data is the suspected culprit, you spend 10 to 30 minutes querying the data for possible problems. Examples include a bad lookup field in a new record, a child record with no parent, or a value out of range. If the problem is correctable and time permits, then you alter the data and resubmit the job. If it’s too close to the start of business operations, then you setup that file for inclusion in the next batch cycle. Often that means to TELNT onto the server and move or copy a file. It’s also is customary to FTP that file to your PC and either email or hand-out hardcopies of the offending records to other team members for their education. It may even require a short write-up for the customer.
If the problem is program related, there generally is no quick fix. Source code has to be checked out, modified, checked-in, reviewed by peers, scheduled for deployment, and signed-off on by the customer. The process generally goes like this: TELNET onto the server, check program code out of source code control system, FTP that code back to your PC, revise and test the code, FTP it back to the server, and check the code into the source code control system. The revise and test is a much more elaborate process then would seem obvious. First, you edit and compile code until you get no errors. Then you have to unit test that changes effects. Often this requires the editing of the development environment’s tables for the necessary test data. If it’s a scenario previously tested, then you might TELNET onto the server and then uncompress and load necessary data files. If they’re on your PC or a shared NT server, you might instead copy and unzip them for loading from your PC – or unzip and copy them to the server to be loaded.
If the problem is schedule related, then you have to discern whether it’s due to database internal resource sharing/locking, external operating system resource sharing/locking or batch schedule interdependencies that either overwhelm the database server or have some previously unknown business requirement effecting the order of processing. These are probably the hardest kind of error to track down. Often this requires running the entire batch cycle (or at least major portions) in the test environment in order to reproduce the problem in order to arrive at and test any possible solutions. It might seem that you could simply utilize the unit tests for all the programs of interest, but those unit tests were written by programmers who wanted to test their code – not necessarily the conditions the code must handle. So you may have to refresh your test environment with a subset of production data (new or previously created) in order to test the programs. You also have to create a second copy of the batch cycle within you scheduling software that mirrors the cycle – but points to the non-production area or server.
Assuming your morning goes well and you don’t have all these issues to resolve, then you read your non-critical morning email, have a cup of coffee or a coke, attend the morning development staff meeting to confirm project milestones for the day and any special upcoming batch cycle anomalies that could occur that night. Then you go back to your desk and finally write programs. Hopefully there are more hours left than have expired by this point. Often, the application developer writes code much less than 50% of their workday – so again, tools are critical.
Let’s assume a totally new program is to be written. You first create an empty source file that contains required header comments, FTP that to the server, TELNET to the server, and check that program in to reserve the name. Then you examine target programming environments: Pro-COBOL, Pro-C, SQLJ, JAVA stored code, PL/SQL, SQL Loader, SQL Plus, Oracle Forms, Oracle Reports, PERL-DB, host shell scripting, etc. Often you will utilize two or more of these options for a given application, so let’s assume Pro-C and PL/SQL for simplicity. Unless your company uses NT database servers, application developers tend NOT to use Microsoft IDE’s. They often have to develop Pro-C or other 3GL code using notepad, FTP, TELNET plus their host compiler, debugger and profiler.
Even if the application is thought to be 100% PL/SQL, you will need host shell scripts callable by your scheduler to invoke SQL Plus to execute your PL/SQL – and possibly SQL Loader and other Oracle utilities. The point is that PL/SQL coding, debugging and profiling accounts for less than a majority of the overall application. I can honestly say that from working side-by-side with 36 PL/SQL developers over a 3 year period – that writing the code and stepping through the debugger represented less than 20% of their work. For example, it might take a week to construct the unit test specifications and data for a session that failed and could be resolved (i.e. debugged successfully) in a few hours at most. If you include their scheduler work, shell scripting, pre-compilers, other Oracle utilities and email plus meetings – they spend very little time in the narrow focus of edit, compile and debug.
Another way to look at this is just the sheer number of different tools they use to accomplish what we consider a single task. Remember my examples of TELNET to check out, FTP to get code on PC, and then use SQL Navigator. The ideal would be to provide an Oracle IDE that facilitates my doing my entire job and all its support tasks from within a single IDE environment. Here’s a list of tools that it would be nice if SQL Navigator replace on a developers desktop (note – many of these items build upon each other to provide the actual stated functionality):
TELNET session in an MDI window within SQL Navigator
X-Window session in an MDI window within SQL Navigator
FTP interface providing tree view graphical interface to server
Source code control interface to host based tools such as SCCS
Ability to edit and debug host OS scripts so that users can test their application from cradle to grave (e.g. shell script which – either invokes SQL Plus which runs a SQL script that invokes stored procedure, or a Pro-whatever 3GL program that invokes stored procedure, or a SQL Loader script that invokes stored procedure)
Ability to compile and debug host based Pro-whatever 3GL programs
Ability to compile and debug host based SQLJ programs
Ability to have JIT debugger capture and trigger for server based 3GL code
Import & Export interface that interfaces with Windows compressions such as WinZip and host compression programs such as gzip, tar, zoo, compress, etc.
Test data generation (could leverage Data Factory)
Test case generation (using Steven’s open source idea)
Test case automated execution engine and score card mechanism
Cyclomatic complexity metrics for PL/SQL code (requires parsing)
How many loops, variables, etc. to judge complexity of code
PL/SQL code inspection and review utility (like LINT for C code)
PL/SQL code tree/hierarchy print utility (like C-Tree for C code)
PL/SQL code explain plan scanning analysis (via SQL Impact’s capability)
PL/SQL – JAVA bi-directional conversion utility (with expert advice)
PL/SQL – Pro-C bi-directional conversion utility (with expert advice)
Context based hot link from Nav to Oracle HTML help (e.g. if I highlight a PL/SQL cursor for loop, I’d like a hot key to jump me to the Oracle help)
100% SQL Plus compatibility within Nav’s SQL script editor
Visual Basic like automation engine to facilitate task automation (e.g. developer defines steps to purge tables, reload data, and then launch into a debug session)
Ability to work offline (i.e. I can edit and compile PL/SQL, just not execute, even though I’m working remote with no Oracle connection – requires parser and offline snapshot of Oracle dictionary required to support desired source code)
Interface to be able to create and send HTML based email messages containing user selected code, error messages and/or explain plans (like window’s explorer send-to email capability)
Ability to open an Oracle Forms and/or Oracle Reports window within Nav (via a callout to execute those editors within the Nav process context as MDI window)"