November 8, 2010 at 8:50 pm
Comments posted to this topic are about the item Code of Conduct for Software Maintenance
November 8, 2010 at 9:38 pm
I've always been a fan long term products, and have yet to truly understand the need to re-invent the wheel every 3 to 5 years. Some good has come out of that, but really, there's no reason to be chucking people off XP for the latest and greatest.
Our work is so that company's can do business. I'm not against flexibility, new development, etc. However, at one firm, they started the design of the next complete overhaul of the in house software 1 month after the launch of the last 2 year design. Why?
"Because we have to keep up with the Microsoft versions so that we don't fall behind."
Wow.
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
November 9, 2010 at 8:12 am
In the world of commercial/business software, aka database systems, the answer to maintenance costs is to embrace SSD/BCNF. Why, you may ask? Let me count the ways.
1) by putting the data and its integrity logic in one place, the server, letting the client code be responsible only for screen painting and data input; one small group of smart database geeks keeps the data under control. compare to the human wave approach of client-side coding. in fact, embracing SSD/BCNF means the data is utterly agnostic to the client code. could not possibly care less whether it's a java screen, or VB screen, or csv file. makes no difference. I offer xTuple as an example; not yet a SS application, not that this matters much.
2) by embracing SSD/BCNF, maintenance amounts to adding columns/tables/rows (a row is a business rule, remember) to the schema. the data hangs together on the RM.
3) by embracing SSD/BCNF, client side code can be generated from the schema. not saying it has to be, or should be (well, yeah, it should), but it can be. at the least, clients should interact through SP.
4) with significantly (and soon to be, massively) parallel servers available for small bucks, what's the most adept application for such machines? well, the relational database engine, of course. client code, not so much; as client coders are discovering.
5) by embracing SSD/BCNF, the byte footprint is an order of magnitude less than it is with the flat-file storage so beloved by C#/java/VB/COBOL coders.
6) as Celko (at least) has written (in "Thinking in Sets"), using auxiliary tables to implement constraints makes maintenance still simpler: just add (or delete) rows to update constraints. for that matter, authorized users can update check constraints and the like from screens; such constraints are just text stored in the catalog.
That should do it for now. Remember, the cost of maintenance is *directly* a function of the code/data structure. The more obscure that structure, the higher the cost. Historically, for those that have been paying attention, coders view life (largely because those that employ them are dumb enough measure them so) as a LOC exercise. Anything which increases the LOC future is good; likewise, anything which decreases LOC future is bad. Those that employ them often take the same view, though few will admit it. The reason is that such organizations are inherently bureaucratic, and it that environment the one with the deeper org chart gets more money. Efficiency and productivity really aren't the goal. The hardware and software, in the commercial world, has existed for decades, yet the COBOL/VSAM paradigm persists; only the syntax has changed. That's not an accident.
November 9, 2010 at 8:28 am
Is that because software just needs repair and enhancement once it gets used by the public? Or is it because software vendors are not testing enough and expecting clients to just live with their level of quality?
As a software developer with many years of experience working for three different software vendors and having purchased third-party "online" software from several vendors, the answer is definitely the latter--software vendors are not testing enough and expecting clients to just live with their level of quality.
I've also worked on software for internal clients and find the same level of quality for online software deployed in-house. Software management is more interested in getting it out the door as fast as possible than they are in getting it right--hence higher long-run IT costs.
Most non-technical users don't seem to understand why the software development process takes so long. So, maybe a desire to meet the unrealistic expectations of non-technical managers is driving this. Nevertheless, haste does make waste. And if that's true anywhere, it's true in the realm of IT.
November 9, 2010 at 8:38 am
C.J. (11/9/2010)
As a software developer with many years of experience working for three different software vendors and having purchased third-party "online" software from several vendors, the answer is definitely the latter--software vendors are not testing enough and expecting clients to just live with their level of quality.I've also worked on software for internal clients and find the same level of quality for online software deployed in-house. Software management is more interested in getting it out the door as fast as possible than they are in getting it right--hence higher long-run IT costs.
Most non-technical users don't seem to understand why the software development process takes so long. So, maybe a desire to meet the unrealistic expectations of non-technical managers is driving this. Nevertheless, haste does make waste. And if that's true anywhere, it's true in the realm of IT.
I would also add that this is a result of users and developers allowing the idea of "everything and the kitchen sink" to be added to a project/product. Many times, in house developed software is supposed to automate a business process, but the company isn't sure exactly what their process is, and they want to replace the whole shebang of an unknown framework with this whiz-bang software that does it "all", except they don't know what "all" is.
I think more IT people working to support a business need to get on the bandwagon of putting smaller chunks of functionality out, let it get excercised, determine if it truly meets the business needs, and then expand on it rather than spending 2 years to write an app that they can't possible test because it's a brand new business process.
November 9, 2010 at 9:10 am
Actually I think a big problem is so many business people running technology companies, and the pride of doing something well being slipped in favor of making a ship date. However many programmers will not drive forward to a finish line quick enough without some pressure. Hard balance. I'd like to see a little more liability, and product support from companies and understanding that profits should be a bit lower so that quality can be higher.
Keep in mind that much of Linux, and open source stuff is tossed out there by programmers, who do their best, but they also make lots of mistakes. They fix them quickly, but don't often overly test things as well. The large community does end up helping make this work with a wider variety of tests than many people could run.
November 9, 2010 at 9:49 am
I'm not sure if everyone understands just what the Lowes CIO may have meant by the word Software Maintenance cost.
Besides the usual software you would associate with a corporation. ERP, Office Productivity, Back Office data support, etc. Lowes has thousands of Point of Sale cash registers. These feed the accounting systems with Sales and Inventory adjustments among other things.
Elsewhere they are scanning everthing that ships into their stores when it arrives and scan where in the store it goes to further track specific Inventory detail. The software for just that did not come "off the shelf".
Then there are the Distribution Centers where additional likely custom software has been built to their specific needs in order to track what is on order, predict what will be needed to be ordered in the future and when. It tracks when an item arrives, where it is stored, assigns it to a route to get it out, and tells the loader which specific loads to put on which truck, and in what order.
I could be wrong, but I'm not so sure that that CIO's statement is typical of Software Maintenance cost.
November 9, 2010 at 9:58 am
Tom Garth (11/9/2010)
Elsewhere they are scanning everthing that ships into their stores when it arrives and scan where in the store it goes to further track specific Inventory detail. The software for just that did not come "off the shelf".
Don't be so sure. I worked on a distribution VAR package years ago. "The travelling salesman" problem has been around for hundreds of years. Computerized solutions, for decades. Every warehouse/distribution package has such a module; some more sophisticated than others. There's no reason to build such, any more than there is to build a G/L from scratch. Businesses do both, but mostly for NIH reasons, not superior algorithms.
November 9, 2010 at 10:16 am
RobertYoung (11/9/2010)
Tom Garth (11/9/2010)
Elsewhere they are scanning everthing that ships into their stores when it arrives and scan where in the store it goes to further track specific Inventory detail. The software for just that did not come "off the shelf".Don't be so sure. I worked on a distribution VAR package years ago. "The travelling salesman" problem has been around for hundreds of years. Computerized solutions, for decades. Every warehouse/distribution package has such a module; some more sophisticated than others. There's no reason to build such, any more than there is to build a G/L from scratch. Businesses do both, but mostly for NIH reasons, not superior algorithms.
Maybe you are right to some extent, but I have worked with several warehouse/ distribution packages. Very versatile packages at that. And I've done a couple from scratch. What I continually see is software being forced to fit an existing operation with little give in the other direction.
People are reluctant to change how they do their jobs if it has been working well. I hear people say "its managements job do make them change.", but life just isn't that easy. Thus we get the Hybrids, and Custom software packages.
November 22, 2010 at 12:24 pm
I believe that software maintenance and costs are getting out of control. Part of that is the rush to get something out without doing it right the first time and thus having to bandaid it and "fix it later".
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
Viewing 10 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply