December 6, 2016 at 8:31 am
Oh YES! Crystal clear! I have a mess of a system like this and, over the time, we apply all the solutions. At first we have no time nor money to re-make the system so we apply many band aids to cover issues and new needs trying not to break things on the client program side. Once we get a minor knowledge about the system functionality, we start to improve the tables and stored procedures. But it took over 3 years until we dare to do it! Now we are taking the final step and re-making the system with new techniques: Model View Controller, Web Enabled and all that. It's worst than you pointed out when you think that is not only the database but the client program also (vb6) that have to be maintained and changed. A nightmare of a job but we are almost done!
December 6, 2016 at 8:41 am
There is a tipping point, where the system is so poorly designed that a total re-write is less effort- and possibly even less risk- than trying to fix the design or refactor it.
Then it becomes a political issue to get management to re-develop something that's "already done".
December 6, 2016 at 9:03 am
I just inherited a mess - I'm documenting everything and highlighting what needs to go and what needs to stay. I had virtually no documentation, and the person was too creative with powershell, SSIS and stored procedures. All together in a batch command. Eeps.
December 6, 2016 at 9:17 am
Really it depends on what the organization, or your management, has a tolerance for. I have been hired on to fix messes but then had the reins pulled back hard when I started to propose changes/fixes. You have to find that sweet spot of getting as much done as possible while not freaking out the company with more change than they can tolerate.
December 6, 2016 at 9:33 am
You should see the "forest" instead of the "tree". Think first, code later then you can have the best solution for your project. There so many best practices out there and there so many mess created by those best practices. If a solution works fine, it is well-documented and gives the expected results no one cares how it was coded.
TD
December 6, 2016 at 9:39 am
^^ This ^^
Whoops - this was supposed to be a reply to david.gugg:
What really sucks is when you're supporting a mess that is a back-end for third party software. You are powerless to fix any of the code and are limited to playing with indexes. Our PLM software is the worst thing I've ever seen. It's like they were trying to make it as bad as possible. I'd love to have any of those three options to fix it, but instead all I can do is give the users my condolences when they complain about the product. I even sent a detailed demonstration to the vendor showing how they could greatly improve the database but they ignored it.
December 6, 2016 at 9:51 am
dhsweg (12/6/2016)
I generally opt for the 'scrap and start over' approach. Building on a poor foundation is not a good practice, and if I must dig all the way down to the foundation to fix it, starting over is usually more efficient.
Agreed. It's similar to driving a vehicle and not doing the regular maintenance. Then at some point it runs poorly (performance), burns oil (maintenance costs), and eventually breaks down out on the highway, preferably not on the way to the hospital, with very expensive repairs required on a vehicle that is now worth not a penny more. Now you are forced into a very uncomfortable position while being under extreme pressure.
Might have been far better off buying a new vehicle. 'Hindsight is 20/20'.
And again, the critical thing for IT folks is to proactively keep superiors appraised of the ongoing situation. Better to go to them and be refused than for them to come to you. I've seen this in both hardware and software where aging systems are not maintained due to perceived risk of change while in actuality the risk is constantly increasing
Rick
Disaster Recovery = Backup ( Backup ( Your Backup ) )
December 6, 2016 at 10:06 am
Brian J. Parker (12/6/2016)
There are, as you and several commenters note, a lot of factors; I wouldn't say that there was a universal best approach.Generally, what I've done is introduce improvements at a point where they are going to be QA'd anyway. For example, if I've got a stored procedure with a slow cursor in it, I'll try to wait until I've been tasked with another change to that procedure. Then I'll quietly go in and rewrite the cursor as a set-based operation at the same time. Although this does increase the chance of introducing a bug, it's the "least risky" time to do it since the results of that procedure need to be (re)tested anyway.
I guess this is closest to "systematic," maybe I'd call it "opportunistic"? 🙂
Amen to that, Brian! In my experience, the QA folks had no coding and development experience and were not about to compare new to old code, so I slipped in many, many fixes along the way. New version of code releases often 'required' an index fix or modifications to 'related and required' stored procedure modifications. it mostly depends on your familiarity with the system and lots on your sense of adventure.
Rick
Disaster Recovery = Backup ( Backup ( Your Backup ) )
December 6, 2016 at 10:16 am
skeleton567 (12/6/2016)
Brian J. Parker (12/6/2016)
There are, as you and several commenters note, a lot of factors; I wouldn't say that there was a universal best approach.Generally, what I've done is introduce improvements at a point where they are going to be QA'd anyway. For example, if I've got a stored procedure with a slow cursor in it, I'll try to wait until I've been tasked with another change to that procedure. Then I'll quietly go in and rewrite the cursor as a set-based operation at the same time. Although this does increase the chance of introducing a bug, it's the "least risky" time to do it since the results of that procedure need to be (re)tested anyway.
I guess this is closest to "systematic," maybe I'd call it "opportunistic"? 🙂
Amen to that, Brian! In my experience, the QA folks had no coding and development experience and were not about to compare new to old code, so I slipped in many, many fixes along the way. New version of code releases often 'required' an index fix or modifications to 'related and required' stored procedure modifications. it mostly depends on your familiarity with the system and lots on your sense of adventure.
Even if they were to compare, the idea is, it should still be the same effort to test!
December 6, 2016 at 10:20 am
TD-238967 (12/6/2016)
You should see the "forest" instead of the "tree". Think first, code later then you can have the best solution for your project. There so many best practices out there and there so many mess created by those best practices. If a solution works fine, it is well-documented and gives the expected results no one cares how it was coded.
Just remember that while each individual tree burns, the forest fire destroys the whole thing. The nature of forest fires is that they often begin in small patches on the ground, but by the time they reach the tree tops they rapidly spread and get out of control. Same with developing new code based on existing poor code. The likelihood of things getting better is very small. So you really DO need to care about how things are coded.
This is my concern for the current feeling that 'anyone can write code' It ain't necessarily so.
Rick
Disaster Recovery = Backup ( Backup ( Your Backup ) )
December 6, 2016 at 10:52 am
I generally opt for the 'scrap and start over' approach. Building on a poor foundation is not a good practice, and if I must dig all the way down to the foundation to fix it, starting over is usually more efficient.
I worked with a programmer once who would run across some code that he thought should be optimized, written better. So he would modify the code. Half the time, because of his ignorance in what was really going on, he would introduce errors. You may think something is a mess but maybe it's your own inability in recognizing brilliance.
Hey you two know each other?
December 6, 2016 at 11:37 am
Good question, Ben. I've seen only 2 options taken, you passive response and systematic. From my experience its been a combination of whose involved (developers, DBA, managers, customers, stack holders) as to what is done.
The last project I inherited that was handled in a passive way is an internal app and database for tracking employees' time for a Federal regulation. The database is terrible. (No indices, keys, etc.) The application's source code was nonexistent. I had to make modifications to the source code, so I had to go to the system administrators to have them try and restore the code from the last guy who worked on it years ago. They recovered several different copies. Using a decompiler I was able to determine what I believe was the closest match to the existing production software. At this point I proposed nuking the whole thing and starting it over from scratch, but my boss said no. He wanted me to only make the changes necessary to satisfy the users' requests. I wasn't happy with that and honestly am still ashamed of that poorly written application. But I can see my boss' point of view. The application is only used 2 months out of the year, the rest of the time it just sits there dormant. So, it does what it has to for 2 months.
One of the systematic projects is one I joined late, so I was a join heir, you might say. I did the DBA work whereas the other guy was the front-end developer. The project lasted a total of 2 years, but I didn't join it until half way through. This had a reasonably good database design. The application wasn't great, but OK. The hard thing was the customer never agreed to anything. They always added more requirements before signing off on old ones. They would say they wanted one them, then 2 weeks later changed it to something else, the a month after that go back to their original requirement, etc. They wouldn't test anything we put out, so you never knew if they liked it or not. Finally, after nothing substantive being done, my boss' boss just called a halt to it. He said that since nothing had of consequence had been accomplished in 2 years and other projects needed our attention, we had to move on. (Good for him.) This project is the only one in my experience that had an outcome like that. I've been on other systematic projects and they've gone well.
Kindest Regards, Rod Connect with me on LinkedIn.
December 6, 2016 at 11:48 am
skeleton567 (12/6/2016)
TD-238967 (12/6/2016)
You should see the "forest" instead of the "tree". Think first, code later then you can have the best solution for your project. There so many best practices out there and there so many mess created by those best practices. If a solution works fine, it is well-documented and gives the expected results no one cares how it was coded.Just remember that while each individual tree burns, the forest fire destroys the whole thing. The nature of forest fires is that they often begin in small patches on the ground, but by the time they reach the tree tops they rapidly spread and get out of control. Same with developing new code based on existing poor code. The likelihood of things getting better is very small. So you really DO need to care about how things are coded.
This is my concern for the current feeling that 'anyone can write code' It ain't necessarily so.
The same goes for self-service query tools like Power BI. Users certainly can build reports without relying on IT or the DBA, but that doesn't mean that we won't get involved at some point when the database server grinds to a halt under the weight of 10 or 20 ad-hoc queries.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
December 6, 2016 at 11:49 am
Iwas Bornready (12/6/2016)
I worked with a programmer once who would run across some code that he thought should be optimized, written better. So he would modify the code. Half the time, because of his ignorance in what was really going on, he would introduce errors. You may think something is a mess but maybe it's your own inability in recognizing brilliance.
The real skill is in discerning the difference.
Rick
Disaster Recovery = Backup ( Backup ( Your Backup ) )
December 6, 2016 at 12:05 pm
I had one of those systems. The state agency had a vendor provided system, that was shared with another state agency, that sent alerts out using fax and email. In 2011, the vendor provided a year's notification that the system would no longer be supported.
In January 2012, I was assigned to the project to develop a new system that replaced the old system. There was no way to create a new system and have it operational in six months, not even using the "Nine Pregnant Women Project Management Model". The "project manager's" "Plan A - Clean Slate" schedule was impossible.
I proposed a "Plan C - Moving Van", which was load the systems in a U-Haul and move it from the hosting state agency to our server room. That was the only way to get a notification system up and running on short notice. Fortunately, the system was on virtual machines and the source for the web application was on the VM; but there was no source for the password expiration service or a proprietary DLL.
After a month in production, the system failed and it failed hard! We didn't have any documentation or training on this orphan code. I traced the problem to that no source proprietary DLL where it hands the alert to the server that controls the telephone lines. The system was broke for about a month. The "project manager" promised to get the source for the DLL, but she failed to deliver. I remembered about a Unix utility called "strings" that can find strings in object code, so I downloaded Cygwin and dumped the strings of that DLL looking for a "smoking gun".
I found a suspicious SQL statement: select MAX(Convert(Int,AdHocId)) from avsAdHoc. AdHocId is a string column, but it normally contains integers. But there were a few rows that had non-numeric characters in the column. I deleted those rows and that fixed the system.
The system was fragile. Since I wasn't about to modify any code in the system, any problems found were a "pre-existing condition" when it was a shared agency system.
Finally, this year, the agency issued an RFP for a new system that sends notifications and it was awarded and now in operation. Last month, I was able to decommission the old system.
Viewing 15 posts - 16 through 30 (of 49 total)
You must be logged in to reply to this topic. Login to reply