June 11, 2012 at 9:20 pm
Comments posted to this topic are about the item The Danger of Custom Software
June 12, 2012 at 9:03 am
I liked Redgate SQL Monitor, but I utlimately came down on the side of SQL Sentry's Event Manager because it has an "Outlook Calendar style" for managing just about everything on my DB servers that I need to, plus it shows me exactly when it happened in a calendar format I can easily feed to my manager and have him readily digest and understand it. I mean who doesn't already know Outlook? Plus, I just love their FREE Execution Plan Explorer with the SSMS Add In. It's the bomb..:-D
"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"
June 12, 2012 at 3:00 pm
Interesting article. It pertains quite heavily to my current job, where the original database structure as well as some other programs were written by the first programmer to work for the company. While they served the company's needs at the time, the business grew and changed, and so those programs needed to be rewritten. This involved a move to SQL Server for the databases, and a rewriting for the external programs.
The problem with rewriting the external programs, unfortunately, was that there was essentially no documentation of the coding at all. Figuring out what any given part of the 50,000 lines of coding did was difficult, and only made more so by bad variable naming conventions (here's object a. It has properties a, b, c, d, and e. Fun!).
In the end, the business agreed with my decision to simply tear out the external programs and rebuild them from the ground up, this time with good naming and documentation standards. We'll still be using custom coding, but I'll be the person standing behind it this time. Should someone else need to modify it... Well, I'll be as descriptive in documentation as I possibly can be, but that alone can't fix the other problems pointed out in the article, like latent bugs.
On the other hand, though, the functionality the business needs can't be fully captured in any one external solution, either (inventory management, bookkeeping, shipping rate calculators, distributor inventory), so that's a problem, too. In the end, I'd imagine there are many programming teams that simply have to bite the bullet when it comes to custom coding, but hopefully there's a long proofing and quality-testing lifetime for the coding in question.
- 😀
June 12, 2012 at 3:43 pm
The biggest problem with using off-the-shelf software is you have no control over how it works, or fixing the bugs in it. The problem escalates as the software provider gets larger.
I have been battling (and the dents in the wall of my office show this) with a popular report designer from one of the largest software providers. When it crashes and looses your changes EVERY time I resize a row in a table, I start to get frustrated. When it randomly changes the parents of an object, and there is no way to directly change this, other than editing the XML, things start to boil over. And I won't go into the random differences in rendering between media, the incompatibilities between versions of the designer, SQL Server, Visual Studio, web & fat client rendering, difficulties with getting reports to be just the way they are wanted, and reported bugs still unresolved since 2 major releases ago....
If this was an in-house product, we would be able to understand, control & change these issues. At the moment, it is a sealed black box that we have no control over. Maybe we should have stuck with our in-house reporting tool, enhancing it to meet our growing needs, rather than trying to adopt an industry standard. It may have saved time overall, particularly with the number of reports we have to create in the coming months.
June 12, 2012 at 4:44 pm
I'd say there's two sides to this particular coin. As an example, Indie Game Development can be a perfect place to admire the contrasts in the choices.
For example, there's a software called "Unity" which allows for a lot of Indie designers to pick up from an existing engine and build their game on top of it. This forces these developers to create workarounds and/or just live with any limitations of that engine. It speeds their development tenfold, however, and a lot of them wouldn't be able to put out the quality work (or sometimes, any work) that the engine allows them to do. Also, fixes to the engine generically fix them as well, simply as being purchasers of the product.
On the flipside, this does mean a lot of end user concerns are simply un-addressable by the game company, they literally cannot fix a number of issues that may crop up, since they can't get at the root cause, and usually no one shop is big enough to force an engine company to fix any particular thing in a timely manner.
There's good and bad to both ends of the process. In the end, you have to decide between internal costs and flexibility to respond to specific issues with the understanding that you won't be able to address every issue.
Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.
For better assistance in answering your questions[/url] | Forum Netiquette
For index/tuning help, follow these directions.[/url] |Tally Tables[/url]
Twitter: @AnyWayDBA
June 21, 2012 at 5:49 pm
COTS still cost money.
Homegrown cost lots of money.
To COTS or NOT, is not the question. The question is can you affort to COT or Not?
Sorry Steve I could not help myself.
Not all gray hairs are Dinosaurs!
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply