A Simple Solution

Question

A Simple Solution

Steve Jones - SSC Editor

SSC Guru

Points: 735655
More actions
September 13, 2024 at 12:00 am

#4451089

Comments posted to this topic are about the item A Simple Solution

Viewing 4 posts - 1 through 3 (of 3 total)

You must be logged in to reply to this topic. Login to reply

Doctor Who 2 SSCrazy Eights Points: 8187 More actions · Answer 1

I can think of a complex solution which, in my estimation, is overkill. At work we started on a project of rewriting an old Microsoft Access application, into a WPF application, that will soon (we hope) be released. We started this project three years ago! This application is for scheduling training on equipment that police officers need to be trained on. At the beginning it didn't seem like it should be as complicated as it has become, but over the life of this rewrite the customers really got scope creep going. There were dozens of, "Oh, we need this. We're sorry we didn't include it in the original spec", etc. I know the users didn't really want to move off the MS Access app that someone wrote many years ago. And our (IT and development) desire to get something that could be maintained in source control fell on deaf ears; after all users couldn't care less if an application's code was in source control or not. Even pointing out to them that no one is around who can maintain the code, because no one knows how to write VBA code, doesn't matter to the users. They honestly believe that there's someone like a Fairy Godmother who can come in and wave her magic wand and then, "POOF", all is well. Honestly, this is one of our worst experiences at coding something, and a large part of it is the users who too often would say they were done adding functionality, "that has to be there", only to turn around a week later and go, "Oh, we're sorry, we've got to have this additional thing, or it won't work."

Rod

Steve Jones - SSC Editor SSC Guru Points: 735655 More actions · Answer 2

I think rewrites invariably get complicated as people who've held bugs or implemented workarounds start to push more for core changes in code, and add to scope creep.

For complexity, I more worry about devs that try to be perfect, maybe starting a process and checking constantly for changes in a db or service, or they implement a serialization/deserialization for some data with complex transforms and they create a knowledge gap for others coming after them. I also see this with SQL people sometimes doing a process like a backup system and adding lots of code to their script for exceptions or for changes based on an environment and the next person can't quite grok how it works.

I always aim for simpler things that work well, maybe not perfectly, but are easier for the next person to understand and maintain.

david.gugg SSCertifiable Points: 6076 More actions · Answer 3

When I started my current gig a couple years ago, I was given a couple of crazy procs to manage. They both have WAY too much flow logic; variables that are often updated with transient data and control whether sections of code run or not. It is almost impossible to troubleshoot unexpected results.

The previous head of IT was the author, and he just continued to insert additional logic as the business requirements changed over time. I've heard he was well aware of how the proc worked in his head, but he never left any documentation. He left the company about 6 months before I started.

Because of this bloated code, an extremely simple change to add an incrementing ID column took us a full year to implement. SQL is not meant to be written like app code, but that doesn't stop the I-can-do-it-all type folks.

Fortunately I have phased out one of the procs and the replacement for the other is in testing.

Be still, and know that I am God - Psalm 46:10