Re: Stepping into someone's shoes
- From: Gigamite <GigamiteDB@xxxxxxxxxxxxxxx>
- Date: Sat, 09 May 2009 10:07:03 -0700
Builder wrote:
> Would any of you step into a job - high paying, say $100/hour - where you
inherit 10 Access systems?
I'd classify 4 of them as large: 100+ forms, up to 200 tables, few dozen reports, tens of thousands of lines of code, etc.
Most utilize the front-end .mde/back end local .mdb standard as well, and most are integrated with enterprise Oracle/DB2/SQL Server databases.
You'll need strong development skills in all facets of MS Access: db design, forms, SQL/queries, reports, VBA. Also required is some Oracle PL/SQL knowledge and the ability to create/manage Oracle objects (tables, views, triggers, sequences, etc).
85% of your work would be maintaining/enhancing these systems, and the remainder would be new development.
It's not clear whether you are asking for advice for yourself or whether you are looking for someone to fill *your* shoes.
If it's the former, you need to look at the applications from the front end and the back end, too. I've filled shoes such as you're describing at three different organizations. The best jobs were the ones where management trusted me to design, maintain and optimize the applications in both ends of the databases. They were well pleased with the results: performance that made the applications run in 10% to 30% of the time of the original applications, better user interfaces and rock solid security. I removed a bunch of bugs my predecessors hadn't been able to figure out. I showed them what kind of applications could be built by experienced database developers, things they'd never seen before.
The worst job was the one where the management only allowed me to optimize the front ends and not touch the back ends, because they'd been built by my predecessor, who was considered their guru. This despite the fact that I'm an Oracle trained DBA and I've spent years as both an Oracle DBA and SQL Server DBA in high tempo/heavy data organizations with tens of thousands of users to support. Successfully. He'd done none of that, but he wrote a lot of code while he was there. Impressed the heck out of management. (Which I can say helped me get hired too. I programmed in the large for years and wrote three times as much code per year as their guru did.)
He'd written tens of thousands of lines of code that frankly could have been written in half as many lines if he'd been a good database programmer. Instead of using SQL queries, he wrote VBA code using recordsets and PL/SQL or TSQL using cursors for all data manipulation. The performance hit isn't much for a limited amount of rows, but when you go row by row in a recordset for 100,000 rows or more, it takes a lot longer than an update query does. He had several unnormalized tables in Oracle and SQL Server with 10 to 25 rows, 25 to 35 columns and over 100 indexes designed to improve performance because they were used in about 60% of all queries. I had an opportunity to make some changes in the Oracle database one day and spent three hours analyzing and optimizing. The front ends that used those two schemas where suddenly running their views and stored procedures in 1/5 to 1/3 of the time. Wish I'd had the chance to make changes to the other schemas, but management wouldn't allow it, even after they heard about my results from the users.
So examine the applications and the database schemas and see whether the original developer was using best practices. If he wasn't, find out how much of a hurdle it will be and what time frame they'll allow you to make the necessary changes. If it turns out to be a "running of the bulls" both in speed and difficulty to fix the current problems or design your own applications, it's better to find another job.
.
- Follow-Ups:
- Re: Stepping into someone's shoes
- From: Tony Toews [MVP]
- Re: Stepping into someone's shoes
- References:
- Stepping into someone's shoes
- From: Builder
- Stepping into someone's shoes
- Prev by Date: Re: Stepping into someone's shoes
- Next by Date: Re: A simple method for distributing client upgrades
- Previous by thread: Re: Stepping into someone's shoes
- Next by thread: Re: Stepping into someone's shoes
- Index(es):
Relevant Pages
|