I'm working right now on something that should be fairly simple in most applications: adding two columns of data to a screen. I have to update the logic that retrieves and saves the data, and also modify the GUI to accept user input and display the new columns.
But this task is taking me two or three times the normal amount of time because the original developer didn't understand the programming tool's strengths and probably wasn't too hot on data modeling either. In exploring the table that stores this data, I found that the table has no primary key and nary an index. There's no relational integrity established through keys or triggers, and columns used to define uniqueness at a row level can have mutating values if the user wants to change the data. *Shudder*
Moreover, in the GUI the original developer didn't cater to the strengths of the programming language's construct for managing data (it's the PowerBuilder datawindow, one of the best object-relational mapping devices out there, I don't care what anyone else thinks). The constuct makes database interactions very easy if you work with it rather than against it. The original developer instead bypasses the tool and puts responsibility for updates and deletes for key columns in list box controls outside of the datawindow, manually controlling everything. This is like clubbing yourself in the knees with a sledgehammer.
He loads the list boxes with the possible values for the columns. You pick what you want and save it to the database. But when scrolling through the datawindow, he is also reloading the list box values whenever a different row gets focus, and then populating the list boxes with the values in the current row, so that as you navigate rows, the list boxes mirror the values. He could have simply kept all this in the main datawindow, because the user can already see what the values are there, but that would have been too easy.
And of course, the coup de grace is that for everything (the updates, the loads of the list box values, and deletes), instead of simply configuring the datawindow correctly and issuing a single PowerBuilder update() command, this fellow offloads everything to embedded SQL, which is a mistake in several ways. It spreads data access across several points increasing the complexity of coupling. It also creates a context switch from programming language to SQL, which can cause performance problems in some languages. It gets worse; you know the part where he is keeping the list box values in sync with the current datawindow row? He is triggering a full repopulation of the list box values with each row change, and the list boxes are populated with embedded SQL cursors, a totally needless construct in the PowerBuilder world. This means that even though you have everything you need in the main datawindow, this app is generating several SQL calls to the database with every click on a different row. This creates both network traffic and database server loads that are completely unnecessary.
This means that instead of having to make small modifications to the table, a stored procedure, and the GUI screen, I have to create new list boxes, plus tons of new code to manage them within the same "framework" the original developer created. What should have been about half a day of work becomes almost two days given the extra work and testing that needs to be done.
Why didn't I just rebuild the whole thing? This is where the Ghost of Project Manager Past is supposed to come in and take the blame, but it doesn't happen and even if it did, the truth remains: I am on a deadline to get this work done, and it will be actually less expensive to do it inefficiently than to fix it and make it right. I groan with every line I write, despising myself for it, but I get it done and sneak in an improvement or two. If I was the Ghost of Project Manager Present, I would change the project scope and maybe rebuild the app. But Boss of Project Manager Present would probably not approve.
How do guys like the original developer get hired in the first place? And why aren't they held accountable for their work? Please see my earlier entry, Mind Your Contractors.