Slashdot Mirror

← Back to Stories (view on slashdot.org)

Pure Play Maintenance Costs Consuming IT Budgets?

Posted by ryuzaki0 on from the is-your-IT-budget-being-eaten-away dept.

ContractualObligatio asks: "The Register asks the question of whether businesses are at risk of having no budget to develop code, from maintaining too many 'pure play' applications. What has the experience been among Slashdot readers? Are people spending too much time maintaining code and integrations because the business is adopting too many applications? Do IT teams have the time and money to actually improve and innovate the way their companies do business?"

2 of 39 comments (clear)

  1. Re:Too much to do to get work done? What? by afidel · · Score: 3, Insightful

    Only true if you can make an application design that can scale arbitrarily with the business and can meet all current and future business needs. Since that's impossible there will always be some level of maintenance and replacement of software systems. Then there's the hardware platform on which the application runs, and unless it's something basic like OS/360 nee Z/OS then you might have to redisign the app every so often to keep up with the changing OS platform. The goal of IT is to meet the businesses needs at the minimal cost necessary to maintain that position and meet ongoing business growth.

    --
    There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
  2. Re:Too much to do to get work done? What? by eschasi · · Score: 2, Insightful
    You write it once, you write it well, and it works, and keeps working.

    ...giggle...

    ...snort...

    hahahahahahahahHAHAHAHAHAHAHAHAHAHAHhahahahaha . . .

    Go on, pull the other one.

    OK, ok, I'll be serious for a second. What about:

    • OS patches that break things
    • new feature requests from users
    • new browsers that have to be accomodated
    • the code just being slapped together in the first place (yeah, I know you said you write it well. Given the circumstances under which most non-programming IT shops build apps, it's rarely written well.
    • Applications that interact with it change
    • etc, etc, etc.
    Let's face it, the circumstances you describe are damned rare.