The Ongoing Costs of Building Software

  • Comments posted to this topic are about the item The Ongoing Costs of Building Software

  • In business they often talk about "Value Added" by an entity, be it a company or an individual. For me this applies to most of life and is about where we can provide that extra over an above other solutions. In the IT world this can be as simple as the tailoring of a piece of COTS software. Sure, I could write it all from scratch but why would I? (If there is a valid answer to that then I may be in a position to write a whole system but of course, from another point of view, I won't because I am unlikely to develop an OS, a data repository, a web server, a compiler, etc.

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • Let's not forget that a COTS still involves an employee's time, from evaluating the possible products available, determining specs, reading the documentation (if there is any), pulling hair out trying to install the product, fighting with the vendor over bugs, complaining about the need for "sa" access to a shared Cluster, continual updates, etc.

  • Absolutely...but someone else can support it. (That's the point I was making or, perhaps, I was highlighting Steve was making.)

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • I was in a position where I had written a few small single purpose applications that a bunch of folks used. They were somewhat related, so we ended up bringing them all together into a single enterprise application that has been my bread-and-butter for 10+ years now. Still going strong and growing in functionality. This is a DoD electronic warfare application so there's nothing off-the-shelf that does what we need. All the functionality is custom .NET code with SQL Server as the back-end database.

  • The value of a developer's time is relative to whatever else they could be working on at that very moment in time. For example, if you have an active data warehousing project in the delvelopment, QA, or deployment phase where developer time is required, then their time is expensive. Pull them away from a project that's work in progress, and the deliverable date or quality slips.

    However, if you have a team of developers who are currently sitting on the bench because their primary project has stalled due to funding or conceptual design reasons, then allocating their time to other projects or tasks costs the organization practically nothing. I mean, the developers get paid a salary regardless of what they are working on (or not working on), so you're already paying for their time, and it's a sunk cost. Smart IT managers don't allow accounting principles, inner office politics, or methodology get in the way of leveraging the resources of their development team as much as possible.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • That "someone else" is still an employee, so still costs the company money.

    I'm sure I'm not the only one here, who finds that they are expected to support any COTS which involves any kind of backend database connection. And field all kinds of support queries, even when the issue clearly has nothing to do with the database connection.

  • Andy sql (1/13/2016)


    That "someone else" is still an employee, so still costs the company money.

    I was interpreting it as a personal cost.

    As a company cost? Well not all support costs are equal and very few, if any, are free.

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • I find the "Build or Buy" question to be quite the problem. Yes, I absolutely agree with what was stated in the "If you build it, they will complain" article but a lot of those same problem can occur with something that you buy. You CAN pull the old Star Track trick of "I was meant to offer history in this fashion" and be done with "supporting" third party tools (whether free or not) but that's normally not what happens even if people outside of IT aren't using the tool. You still need support and, especially if it's a free tool (think of something like Ola Hallegren's wonderful tool set), you might not be able to get what you want because that person also has a real job and truly doesn't have the time to provide free support.

    Then there's the problem of third party tools not doing quite what you need to do. You might think it an advantage when someone provides the "open source code" for such things so that you can customized the code for the "perfect fit" but then you're the one that has to maintain those customizations and you're right back where you started.

    I think the real key to the "Build or Buy" question was stated in the "If you build it, they will complain" but it should be titled "If you build OR BUY it, they will complain". To wit, "If you build it for yourself but let others know, they will want it... and then they'll complain". 😛

    The bottom line is that you really need to consider the cost of ownership v.s. ROI prior to the introduction of ANY new tool, homegrown or not.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • Andy sql (1/13/2016)


    Let's not forget that a COTS still involves an employee's time, from evaluating the possible products available, determining specs, reading the documentation (if there is any), pulling hair out trying to install the product, fighting with the vendor over bugs, complaining about the need for "sa" access to a shared Cluster, continual updates, etc.

    For sure. However this goes along with the time you'd spent evaluating your own requirements and spec'ing out software.

    There's a cost either way.

  • lionfan91 (1/13/2016)


    I was in a position where I had written a few small single purpose applications that a bunch of folks used. They were somewhat related, so we ended up bringing them all together into a single enterprise application that has been my bread-and-butter for 10+ years now. Still going strong and growing in functionality. This is a DoD electronic warfare application so there's nothing off-the-shelf that does what we need. All the functionality is custom .NET code with SQL Server as the back-end database.

    This is certainly the case at times. I wrote an inventory piece for our custom demo system at one point, when we couldn't find anything that worked as we did, at a reasonable cost. There were some data center packages, but they were multiples of my annual salary, so me doing this part time worked well.

    It ran for about a year, our company got purchased and it was EOL'd, so a good choice for us.

  • Fair point that support costs are not all equal; the dba is valued far less than most 🙁

    I certainly don't want to be re-inventing the wheel, and COTS / Ola / SQLFool / etc can be great solutions. Furthermore, my support time probably costs less than in-house development time. But when the COTS costs an absolute fortune, and still doesn't deliver what the end user needed, then no one wins..... and everyone complains.

  • Jeff Moden (1/13/2016)


    ...

    The bottom line is that you really need to consider the cost of ownership v.s. ROI prior to the introduction of ANY new tool, homegrown or not.

    The TCO, which means guessing about ongoing costs as well. Certainly there are cases where you choose one over the other, but for many staples of software, like monitoring, backups, I'm not sure it's worth writing your own.

    Note that for things like backup schedules and maintenance, "buy" is learning to use something like the Minion products, Ola Hallengren or Michelle Ufford's scripts, or something out there.

  • When I worked in the video game industry, we frequently had these conversations. This was mainly because the tools we needed were non-existent. The market was too small and very few shared secrets to the trade to do your job better. It's only been recently that we started having more and more game engines and tools come available to satisfy the millions of hobby game developers who want to make smaller games for mobile devices, pc and more.

    One of the biggest pieces of software we developed ourselves outside of licensing was the game engine. This includes rendering, audio, scripting, monster design, level design, quest design, the works. All developed by a large-scale dev team over the course of 10 years.

    The process of maintaining, updating, securing, hiring and so forth was extremely complicated. But, that's how it goes sometimes. Not much you can do if you need something now and want to goto market.

    This is similar to Google when they used MySQL and eventually created Big Table. Nothing else existed to solve their problem, so they had to make it.

  • As with so many things, whether COTS will do for you is an "it depends" kind of answer.

    If the COTS has most of what you need at a reasonable cost and is reliable, then it may be the best solution. However, too much software out there has a bunch of "bloat" - features you don't need but are being charged for.

    Far back in my past we were looking for a change management system that accommodated DB4. The two major packages that handled it ran around $2,500,000 and had tons of functionality for other languages that we just didn't need (our home-grown change management system already handled our other needs).

    I was given an intern and three months, and we developed a module for our homegrown system that handled the DB4 just as well as those more expensive systems. Five years later the home-grown version was still working just fine with minimal maintenance.

    TCO always needs to take maintenance costs into account. A lot of our software comes with yearly maintenance or licensing fees, or upgrade fees. Then, as mentioned, there is training or a learning curve. All of that needs to be taken into account - there is always a cost.

    Sometimes COTS is better, sometimes build-your-own works out. I have to chuckle sometimes regarding the "open source is free!" argument. It's free like a puppy. 😛 You still have to buy the food dishes, leash, shots, de-worming, neutering, etc. Not to mention the food! And if you're smart, you'll do the training too.

    For software, you really should do the TCO even if some of the costs are just estimates. It at least gives you a number you can compare with other options.


    Here there be dragons...,

    Steph Brown

Viewing 15 posts - 1 through 15 (of 24 total)

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