back to article Hey, IT department! Sick of vendor shaftings? Why not DO IT, yourself

Enterprise IT departments have been reduced to personal shoppers at best and checkout clerks at worst. You want extra lock-in on those chips, sir? I say this because IT departments just don’t make anything anymore. When was the last time you were required to actually make a new thing as part of an IT project? As the …


This topic is closed for new posts.
  1. Anonymous Coward
    Anonymous Coward

    You actually have to have a large, competent, IT department to do it yourself. We used to do it and had loads of inhouse built applications, custom designed to our needs, that had much more functionality than others in the industry who bought in. They were getting a bit long in the tooth though and needed some investment in bringing them up to date.

    Over the past 5+ years though, there has been a shift to buying things off the shelf, and a corresponding decimation of the IT departments, along with farming the remaining work out to India.

    Our costs are up, and functionality is down, but it's a "Success!" by some strange definition of the word. And our remaining IT guys now no longer have any investment as they aren't working with stuff they created, to make it perfect, instead they are tweaking a few config options on something they see as inferior. If they see problems they can't fix them, they have to just raise it to the vendor and hope for the best...

    1. Necronomnomnomicon

      It's not true everywhere - luckily for me

      I'm the lone IT bod in a more-medium-than-small enterprise, and I am lucky enough to be able to build things that actually solve problems.

      We've been hectoring one of our main IT suppliers to add a not-mission-critical-but-extremely-useful function into one of our systems for ages. Unfortunately they're a useless set of ballbags and they've never managed to get started on it. Bored of this delay, a few weeks ago I went on GitHub, found someone had already done exactly what was needed. The code was a bit mucky, so I contributed a little, fired it up in a VM and we're rolling it out next week.

      I know that nearly finished code off GitHub isn't the same as building something from the ground up, but you do come across the thought of "how many times has this wheel been reinvented elsewhere?" and then you look on GitHub and it turns out they've got not just the wheel but another wheel and an axle between them. Hurrah for open source software and the internet for making it so easily accessible.

    2. Anonymous Coward
      Anonymous Coward

      "Our costs are up, and functionality is down, but it's a "Success!" by some strange definition of the word"

      The success part comes from the fact that the IT manager/director no longer has to take direct responsibility for any cock-ups. He can just wave the contract around a bit, point the finger at the vendor and head off to the golf course knowing he's done all he can and the board can't take him to task over it.

      1. Anonymous Coward
        Anonymous Coward

        Devolved Responsibility

        By not making it yourself (which few CIO's and no CEO's understand) you can buy it from someone who buys you lunch and tells you how great you are. Added benefit: the decision maker doesn't have to let on that he doesn't actually understand IT or applications or application development or how to define business requirements and can devolve responsibility to the supplier if/when it goes wrong. Same argument for Outsourcing and Facilities Management. I know of a very large manufacturer who devolved responsibility for the recovery of their business critical 25 year old VAX system (essential to their production process) to an unproven 3rd party who would magic up failed HDDs, motherboards, processors, IO cards. "We have offloaded that responsibilty to a specialist provider and are therefore not running at risk" - Naive at best "Business-Intelligence" stoopid at worst. Meanwhile the (old) guys that had written and maintained that system were retiring / dying / leaving...

        If you're a decision-maker with limited technical understanding, it is much easier to *trust* a 3rd party who can be blamed (they lied to me!!!) than be blamed for an in-house foul up (I made a bad decision!!)

        As for success criteria - well thats easy - its a sucess if I say its a success, if I'm the decision-maker; who's to argue? Increased costs, lost functionality, decreased reliability can all be explained away.

    3. Anonymous Coward
      Anonymous Coward

      Heading downhill one tax dollar at a time

      "Our costs are up, and functionality is down, but it's a "Success!" by some strange definition of the word."

      Such a pattern gets (regretfully) labeled as a "success!" because you are thinking like an IT guy and not like a [modern] CIO / CFO / CEO...where it's all about the MONEY.

      An outsourced app, an outsourced consultation, an outsourced infrastructure designer, etc. becomes a capital improvement investment - in other words, deductible. The salaries paid to in-house IT specialists are...not. So to the CFO, who reports such information to the CEO who then proclaims policy to the CIO, reminds them all that any outsourced expenditures can be depreciated as a capital investment whilst doing business and therefore makes said outsourcing "good policy!".

      We're all caught in the same trap which allowed big business to export call centers, construction contracts, IT development and just about all other job skills to 'somewhere else'. Our corporate tax codes, written oh-so-lovingly whilst the lobbyists are staring right over the shoulder of our legislators, allow this. The tax code can still be 'repaired' - "fixed" - by granting a "home benefit" for all capital expenditures when the money stays within the borders of the home country as locally-fulfilled contracts, but that would cause the foreign lobbyists to say "Unfair!" and would mean any headway into the process would have to start all over again.

      TL;DR: In other words, as a worker, you're screwed. Welcome to the 21st Century, here's your spot of tea.

  2. Anonymous Coward
    Anonymous Coward

    Not sure where you work...

    ...but we have 50 devs "making" our own stuff, sometime we take a vendors products, and customise the hell out of it, or we start from the ground up. Yes we still buy a lot of the off the shelf stuff, but why invent the wheel?

    The other issue, is when it's custom made, if the guy that wrote it buggers off, and there is little or know documentation, it leaves a whole load of shit behind....just look at the banks for a classic example of this.

    1. Britt Johnston

      Re: Not sure where you work...

      In our large pharmaceutical company, the home-grown applications have been systematically replaced over the last 25 years by configuable standards, the residual home-grown applications will have disappeared in the next few years. When they go, the get replaced with some standard with reduced functionality, some were even sold to external IT specialists to turn them into "standards".

      The driving force is the need for full, up-to-date documentation and control of changes.

      The creative programmers who stayed either moved to the internet side, or became business analysts joining extracts (mostly in excel).

      1. RainbowTrout

        Re: Not sure where you work...

        "In our large pharmaceutical company, the home-grown applications have been systematically replaced over the last 25 years by configuable standards, the residual home-grown applications will have disappeared in the next few years. When they go, the get replaced with some standard with reduced functionality, some were even sold to external IT specialists to turn them into "standards"."

        Same at the biopharm company I work at. 10 years ago there were hand built programs to do time off, expenses, data management. The company was split and my bit sold to a VC company and the majority of the IS people stayed with the old company. New software tools were no longer developed but at least the old ones were updated. The company was sold on a couple of years ago and all of the internal webpages have gone along with the perfectly functional software tools to be replaced by a fricken SAP "portal" and internet that seems to be dialup.

      2. rachel_norfolk

        Re: Not sure where you work...

        Having left (presumably a different but similarly managed) pharmaceutical company IT department a year ago, it is such a relief to not have to deal with the depressing nature of knowing how to make something work really well but being told to implement some closed-source "solution" from elsewhere.

        I'm now working on the "internet side" (within the Drupal community) now and the feeling of collaboration and inspiration is fab. Looking back at what is happening where I left, I think I made one of the best decisions of my life...

    2. M Gale

      Re: Not sure where you work...

      The other issue, is when it's custom made, if the guy that wrote it buggers off, and there is little or know documentation, it leaves a whole load of shit behind....just look at the banks for a classic example of this.

      That's why you beat them about the head with the Big Book of SSADM before letting 'em near a compiler.

      Okay, so you could probably pronounce it as "sadism", and probably compress the entire methodology down to "anal retentive attention to detail and documentation", but hey, if you want everything documented, you document everything. Before writing a bunch of undocumented code.

      Or at least encourage them to use Doxygen and heavy use of remarks. Owt's better than nowt.

      1. gv

        Re: Not sure where you work...

        SSADM? Michael A. Jackson would be turning in his grave if he were dead.

      2. Anonymous Coward
        Anonymous Coward

        Re: Not sure where you work...

        "Or at least encourage them to use Doxygen and heavy use of remarks. Owt's better than nowt."

        Of course the downside of heavy use of in code comments whether doxygen style or not, is that yes they're great for the initial version, but then along come half a dozen maintenance coders who all modify the code, but not a single one of them change the comments. So 5 years later the comments are merely of archeological interest and don't match the code at all. So which is worse - no comments at all, or comments that are eventually useless or even misleading? I don't have an answer to that.

        1. Tom 13

          Re: alf a dozen maintenance coders

          Why aren't your maintenance coders required to update the comments when they change the functionality?

          1. Anonymous Coward
            Anonymous Coward

            Re: alf a dozen maintenance coders

            >Why aren't your maintenance coders required to update the comments when they change the >functionality?

            I've worked in over a dozen companies in my career , and not one mandated maintenance of code comments.

            1. Anonymous Coward
              Anonymous Coward

              Re: alf a dozen maintenance coders

              I've worked in investment banks and they were all seriously winging it from minute to minute. Very poor quality code with nothing thought through and misleading comments (if there was any commenting).

              I also worked at an asset management company which ensured that everything was documented, coding standards (including comments & history) were adhered to and procedures were followed for UAT and PROD releases (with sign-off & responsibility resting with a peer). They even had peer reviews of code and documentation. It was a huge shock to me after years of the cowboy approach while working at the banks, but it's made me a significantly better coder as a result.

            2. Blitterbug

              Re: not one mandated maintenance of code comments

              They were run by incompetents then.

          2. gotes

            Re: alf a dozen maintenance coders

            >Why aren't your maintenance coders required to update the comments when they change the functionality?

            In my (albeit limited) experience, when working at a company with a small development team (often just me), the management tend to prefer immediate results over a properly documented and tested solution. When someone asks me to make a change I usually ask "do you want it done properly or do you want it done now?". No prizes for guessing which answer I get.

        2. barryington d'minogue

          Re: Not sure where you work...

          No comments please, appropriately named methods, variable and classes will do just nicely thank you.

          1. Destroy All Monsters Silver badge

            Re: Not sure where you work...

            That and automated test cases made by a separate team of test fiends wired to a "programmer, you are fired" light once a settable number of failures occur in the daily test run.

        3. Anonymous Coward
          Anonymous Coward

          Re: Not sure where you work...

          I think the answer to that comes down to two things - management and code review.

          I've worked in shops where code didn't get to touch a repository until it was reviewed by another engineer. Each engineer had checklists of what they were to check for in a code review, and any public methods without up to date doc-strings would have been things to flag up in a code review.

      3. Steve Knox

        Re: Not sure where you work...

        The other issue, is when it's custom made, if the guy that wrote it buggers off, and there is little or know documentation, it leaves a whole load of shit behind....just look at the banks for a classic example of this.

        That's why you beat them about the head with the Big Book of SSADM before letting 'em near a compiler.

        That's why they start taking months instead of days to deliver anything, and the CIO starts looking favorably at off-the-shelf again.

        1. Matt Bryant Silver badge

          Re: Steve Knox Re: Not sure where you work...

          ".....That's why they start taking months instead of days to deliver anything....." Lazy-arsed male bovine manure. If you code right from the word go (proper structure, syntax, etc., AND GOOD COMMENTING/DOCUMENTATION) then you will usually complete the project faster and more accurately. Only the WYSIWYG editor generation knock SSADM and similar techniques because they slept through the design modules on their CompSci degrees. Yes, managing coders is like herding cats, which is why you need experienced team leaders and project managers willing to tell them to start over if the coders try submitting anything a green graduate can't decipher from the comments and documentation. Edits, additions and re-use all are so much easier when you have whipped the cats into shape.

      4. Roland6 Silver badge

        Re: Not sure where you work...

        SSADM? Surely you adhere to ITIL?

        1. Matt Bryant Silver badge

          Re: Roland6 Re: Not sure where you work...

          " SSADM? Surely you adhere to ITIL?" SSADM is how you make sure what you design is going to work - ITIL is what you use to bamboozle the board into paying for your design.

          Actually, you can throw a large chunk of blame for the current COTS fad at ITIL. One of the things it allowed the board to do was understand risk, something business people really want to know about. I used to do a lot of risk assessments for companies, and I'd point out to them the biggest risk to their business operations wasn't servers failing or corruption of data, it was often that only one or two people in the company actually knew how the systems worked, and if they fell under a bus the company would be screwed. This drove a heightened increase for process and systems documentation (which we, as consultants, charged extra for) and "knowledge sharing" (guilty, we charged for helping them do that too), and produced an unfortunate side effect of "dumbing down" IT to remove the risk of relying on one or two gurus.

    3. Anonymous Coward
      Anonymous Coward

      Re: Not sure where you work...

      @Lost all faith

      The classic example of the banks is not a good one - those jobs were offshored to people who do not understand/care/have responsibility for what they do. The offshored teams churn every few months so even if you did a good technical handover initially, it is diluted in a matter of months as semi-competent guys leave for better money and do minimal handover (because they are no longer trusted to touch the IT and because they no longer care anyway because they're leaving).

      I don't bank with any bank that offshores its IT any more (and neither should you) because they are a ticking bomb and the Business-Geniuses that made those decisions don't even have the wit to know it...

  3. Anonymous Cowherder

    So I'm not the only experiencing this?

    I had a meeting with "the business" earlier this week. Several departments were there who had previously gone off and done their own thing but were now being hit by vendor lock-in, price rises, failure to stick to contracts... All the time we had been providing nuts and bolts IT services in house that kept chuggling along around 99% uptime.

    The various business departments wanted to bring their IT needs back in house for IT to design, build and support. It was a very enjoyable meeting, means I'm going to be doing a lot more work soon but in this climate I was fist pumping all the way back to my desk.

    1. Cliff

      Re: So I'm not the only experiencing this?

      Just don't forget this...

      "...what they didn’t do was give the finance department a thing to play with whilst they got the project off the ground."

  4. dogged

    once they are finished they zip back up the mouthpiece of their latex suit and climb back into the gimp box with (insert service provider's name here) on it.

    You misspelled "Oracle's".

  5. Anonymous Coward
    Anonymous Coward

    The IT industry is like the maturing Industrial Revolution

    At first everything was handmade, crafted by people who had learned their trade over many years. Gradually factories were built so that a product could be made by cheaper labour. Those factories were made possible by large bespoke machinery made specifically for that one job, but it needed people based at the factory who could maintain, fix and update the machines as required. Over time entrepreneurs started making standardised machinery to sell to the factories. This meant the factories no longer needed their own people to build and maintain the machines - they simply bought them in and paid for repairs or changes when needed. The next step in the process was for manufacturing to be pushed to other countries to reduce labour costs and this is where we find ourselves today - very few people able to build or fix machines and manufacturing was decimated.

    This seems a direct parallel with the IT industry; At first a company wrote its own software using self taught people or people who deliberately wanted to get into that trade. But over time it became cheaper to buy standard tools for the job and the in-house IT departments dwindled away in favour of service management teams who managed contracts and project managers who managed system rollouts. Gradually the remaining high cost was salary and that meant that the remaining jobs flowed out to other countries who could provide it cheaper.

    We are at the tail end of the IT revolution where there remains little knowledge or expertise in the larger companies, and increasingly in the smaller ones. But like manufacturing the only real option left is to specialise and own the IP even if the actual manufacturing is performed elsewhere.

    Whether this is a good or bad thing is hard to say but we can learn a lot of lessons in IT from the decimation of the manufacturing industustry.

  6. Anonymous Coward
    Anonymous Coward

    Use experience

    I was the IT lead in an educational service. Once we were able to get a local authority IT person to help us choose, modify or even build for us the stuff we needed. And we could also draw upon our contact in the IT team to help us select hardware to meet our needs, which I could source myself, and they'd set it up for us.

    Then all of a sudden it became corporate. We had to use software packages that didn't quite fit our needs. The corporate IT people introduced all sorts of overcomplicated, big, expensive, often incomprehensible outsourced designs that didn't quite work and, in one example, relied on an obsolete version of IE to keep working.

    Meanwhile we had to order our hardware through a nominated person who never seemed to be able to help us to select stuff, (I don't think he'd even heard of TCO let alone being able to match our usage profile), only used what was available through authorised suppliers, always took 5 times as long as we could have done it, even from the same suppliers- we had to join the queue- (if he did it at all) and ended up costing more to buy than I could have got it myself ( I tested this a few times) then added his costs on top.

    And stuff we needed sorting out didn't happen unless everyone else in the council had identified the same need ( which was seldom the case).

    If it wasn't for the fact that we hadf really good IT guys working with us on the day to day stuff we'd have opted out ( which we could have done).

  7. This post has been deleted by its author

  8. spamspamspam

    I wish our IT department would google stuff, generally I have to tell them exactly what I want by looking at their vendor's catalogue, then they charge me 10% more that that & I have to help them install & configure it. The idea of IT being able to actually help me do my job better seems frankly laughable from here...

    1. Captain Scarlet

      Erm ok

      Do you have an inhouse department, sounds like an outsourced reseller

    2. Anonymous Coward
      Anonymous Coward

      I was dealing with an infrastructure team recently, using industry standard software packages.

      In the aftermath I asked them 'did you google it (as you are trying to do a standard thing with the most prevalent tool that does this sort of thing)'.

      The answer - we don't Google stuff, we have been doing this for years and we do things our way.

      The top five developers in the IT organisation are consultants, and they are ten times faster, produce code with less bugs and far less technical debt.

      The idea of moving development back in house is laughable - COTS all the way!

    3. ecofeco Silver badge

      Don't blame the IT department. That was a management decision.

  9. CogniDox

    It could be as simple as a 4-point "charter"

    Very elegantly written article: "Sharepoint has never been an answer to any question ever asked by a business person" :-)

    The choice is too often reduced to a bipolar distinction between smooth commercial COTS and in-house development that is never documented, and has one socially dysfunctional developer as the only source of knowledge. It isn't that single-dimensional.

    It seems reasonable that ALL commercial software vendors should: (1) provide source code available licenses to their customers; (2) use applicable open source software that clearly out-performs where development resources and adoption are concerned; (3) always choose an open standard over proprietary alternatives; and (4) create an API that expects the customer to add functionality (and makes it clear such derivative works belong to the customer).

    Software vendors will find themselves at different levels of maturity when measured against these criteria, but that's fine.

    Until IT buyers start asking for this from their suppliers, lock-in and frustration will be the norm.

    1. billat29

      Re: It could be as simple as a 4-point "charter"

      With my vendors hat back on --- although I have built stuff along your suggested lines, there ain't no money in it. My problem has always been getting enough licence and support revenue in to keep a decent development team and a decent support team together. If I am a vendor with thousands (or millions!) of customers, it works, but if I am, say, a specialist supplier providing applications to local government (total market 433 or maybe less depending) then I am going to struggle.

      If I am going to have to expose an API, then that will increase my support burden and cost.

      Now the freetards on here will express no sympathy but consider this. There's no value to you in putting the vendor of your business critical application out of business.

      But I agree there's no point in your vendor just taking the p**s either.

  10. Ken 16 Silver badge

    Horses for courses

    The key word in there is 'competent' and that's the piece in short supply (no shorter supply now that 15 years ago but rarer as a proportion of the IT community). I started out working with first generation COTS packages and making them work, sometimes with a hammer. I've come to the view that modelling the business requirements and processes first is key, then slotting in reliable packages to do the 80% that's common and needs to just work and get supported and upgraded regularly leaving the remaining 20% of functional gaps to be filled by bespoke elements adding business benefit.

  11. Neil Woolford

    Lovely writing. The "possessed multi function device on the 8th floor"...

    I'd especially advise not working on that one after hours; the lights will start flickering, and it won't go well for you.

  12. Trevor 3

    10 years ago...

    When I started doing this 10 years ago, it was expected that the in-house guys knew what they were doing. They build infrastructure, wrote code, did some development work.

    Now though, it seems these basic skills of building say, a web server, or a mysql database, or a webpage with a bit of java on it to do something simple has disappeared from IT teams.

    Everything is spoon fed to them by vendors. The IT teams go out into the market place, get bombarded with information about the particular task they want to achieve, and are then forced to choose one, based on no knowledge at all, just the scales of cost the individual vendors are pushing at them.

    You wonder why places buy the cheapest, or the most functional (but not necessarily the most functioning) bit of software? You wonder why businesses are so confused they seem to buy the nearest bit of crap to what they want without thinking about the environment they need?

    There is very little skill left in the IT sector now. If you're wondering where its gone, look at the smallest, sweat filled cupboard with no air-con or adequate ventilation at any vendors office. Thats the place where our best developers and system architects are. Stuck in pre-sales designing overly complex systems for generic solutions for people who don't understand what they are buying, or buying into.

    1. Anonymous Coward
      Anonymous Coward

      Re: 10 years ago...

      Absolutely, you only have to look at the prices of the IT contracts signed by Government departments to see it. Want a new Intranet page? Thats £100,000 please. The problem is that people see these contracts as safe when in reality they can be just as, if not far more risky. It really annoys me when an Organisation like the NHS outsources absolutely everything, its not like they are too small to support a permanent Software team. At least where I work if I find a bug in one of the tools I am using I can either A: Fix said bug (although I admit as we grow I do this much less) or B: Walk over to the software team who will then be able to see the exact issue and resolve it quickly. Also as I have direct vision / control over the systems (in the main anyway) and don't have stuff hidden from me because it is not part of my contract I can generally fix or work around problems quickly. Much better than raising a "severity 1" case with Company A who will blame Company B until Company C hears and realises one of their services has crashed so restarting a service takes 8 hours instead of 10 minutes.

  13. Anonymous Coward
    Anonymous Coward

    Smart kids in the UK are making better career decisions too

    In the 90's kids in the UK who were good with computers were steered into IT jobs, today their equivalents view IT as just another skill set to help them in their chosen careers.

    I don't think that it was so true in the USA, though my experience was limited to New York. There I met plenty of users with a very poor opinion of their IT dept's because they viewed them as second best.

    1. Anonymous Coward
      Anonymous Coward

      Re: Smart kids in the UK are making better career decisions too


      The careers teacher in the 90s sold me a pig in a poke.

      I ran SimCity on their 386s, suddenly I was some sort of whizzkid.

      Ended up with a BSc Comp Sci, was sold some sort of golden path, ended up in App. Support fixing other people's messes.

      If I had to do it all over again - I wouldn't.

      1. southpacificpom

        Re: Smart kids in the UK are making better career decisions too

        Yeah, most are actually avoiding a career in IT - now that's a smart move!

      2. ecofeco Silver badge

        Re: Smart kids in the UK are making better career decisions too

        Same here.

        As I get more experience I get less pay and more trouble.

        Yet the whole world would literally collapse tomorrow without IT.

        What's wrong with this picture?

    2. Warren 2

      Re: Smart kids in the UK are making better career decisions too

      That is a great point - I should have made that in the article! :-)

  14. Christian Berger

    It's actually what many businesses do when they switch to Linux

    Such switches usually aren't "out with the Windows box, in with the Linux one", but also switches from foreign IT products to self made ones.

    One of the problems with doing things that way is that you need people who look at a problem and see the core of it. There's plenty of software developers who, when given a simple task will add layer upon layer of complexity.

    There seems to be a correlation between such skills and people who prefer something unixoid as their operating system. One of the basics of the Unix philosophy is, in fact, the "Rule of Optimization" which states that you should build a prototype first.

    In fact you typical unixoid environment comes with lots of useful tools for prototyping. Everything you can do on a tabulator can be done trivially with standard console tools in the time it takes to install even the simplest SQL server. It probably will be slow and buggy, but it's a prototype.

  15. southpacificpom


    Yes DIY basically explains the mess most IT departments are in and it's usually driven by the IT managers masturbating over the latest product to come out of Redmond. Why the fsck are these managers always going on about change management and adapting when they are the last bastards that want to change anything?

    Thankfully, there are some good guys about that are willing to take the plunge and change the way they do things in the name of progress and lower TCO.

  16. Anonymous Coward
    Anonymous Coward

    Missing the competative advantage

    Putting togther a decent IT dev team is not cheap or easy to maintain, so it should be used for competative avantage.

    If your service or product is sold using the same software as all your competitors, where's the market differenitation. Why buy yours or stay with your company when you get the same vanilla online sales and service.

    Companies that use their IT to build unquie customer service get to keep customers and poach their competitors, i've seen multi-million pound deals signed purely because our company could offer an BI service to our corporate clients that the other players didn't have.

    1. Christian Berger

      Re: Missing the competative advantage

      Actually it doesn't need to be expensive. Treat your IT dev team the right way. Give them decent amounts of money (actually give them what those bad IT guys get), but give them freedom.

      Free them from clerical work. Get them an assistant who takes care about company bureaucracy. Give them a small "experimental" budget on which they can try out new technologies.

      Then also identify the normal staff members who can program. Include them in technical decisions about your IT. Maybe they can act as a sort of interpreter between the needs of the department and the capabilities of IT.

  17. Anonymous Coward
    Anonymous Coward

    Why couldn't the vendors be right?

    I think it goes even deeper than the article portraits. Because in my experience the degradation of IT departments began even earlier than this. You know; when system administrators were reduced to (sometimes first-line) helpdesk or "service desk" operators. Hardly my idea of a systems administrator or engineer.

    SO isn't it also possible that those who were more qualified eventually went to the other side of the pool? Isn't it possible that because of that move the vendors eventually got it right (or at least more usable) so that most companies and IT departments simply don't feel the need to expand or extend even more?

    And that's but one example; what about those environments / applications which already provide you with a massive degree of customization options? Best example I can come up with is Microsoft Office. It's not merely a spreadsheet / word processor, but underneath it's also one heck of a programming environment which allows you to make it do whatever you want.

    1. ecofeco Silver badge

      Re: Why couldn't the vendors be right?

      Good points.

      Have an upvote on me.

    2. P. Lee

      Re: Why couldn't the vendors be right?


      As it is for Sharepoint, so it is for Office. Office is not something you run an enterprise on.

      "Thou Shalt Not Mix Presentation With Data" is the first commandment of data processing.

      The Second is also important for DIY: "It is better to fail sometimes, obviously, and be cheap and simple than to strive to be 100% accurate and comprehensive and add multiple degrees of complexity."

      There is a vast amount of data in Word which is handed to IT, who either copy to excel and then into csv, or straight into notepad. It then goes to a perl/sed/ruby script which maybe slightly tweaked to accommodate formatting variances and then through grep and wc piped to different files for sanity checking. Excel can be used to sensibly process data, but better to have column upon column of intermediate data than some incomprehensible code hidden behind some small cell.

      Have skills in data processing. Non-interactive interfaces are likely to save you heaps and of programmer time. Procmail is actually quite handy.

      But back to the article, it so true about vendors. The problems are hidden and you pay as you scale. It astounds me that enterprises with large economies of scale pay linearly or worse for facilities.

  18. James 100

    Custom v COTS

    I've seen good and bad aspects of both. Yes, sometimes we find ourselves wrestling with expensive proprietary crud to make it do things that would be easy, or mocking an in-house kludge - but then we get "big projects", micro-managed to specifications written by people with no clue. They'll want a few basic functions ... but specify it must all be done in Visual Basic and get hosted on some rusting Windows cluster. Never mind that complying with those demands triples the cost! (Public sector, needless to say; they dumped that in-house deployment, after discovering that the hosted version of the same web app running on a budget server in another country was much faster as well as cheaper.)

    Back at my previous place, when we switched email platforms, someone demanded that we include the facility to tell when an outgoing message was read. That eliminated most of the sane options and left us enduring proprietary crudware for years, throwing more and more money at bigger and faster SANs and servers to make the crud chug at a semi-adequate speed - ten times the resources for a quarter of the performance.

    Right now, I'm limited to a 50 Mb home directory at work, on in-house servers - plus 25 Gb for email, on commercial outsourced ones, for a fraction of the cost. Can anyone really justify the extra cost for less service? I'd like to think nobody would try: better to focus on services where in-house staff could actually deliver a *better* service than a cheap off-the-shelf service.

  19. Anonymous Coward
    Anonymous Coward

    Filed under hobbies and interests ..

    "Too many CIOs use lock in as a reason why they can’t adopt public cloud but then once they are finished they zip back up the mouthpiece of their latex suit and climb back into the gimp box with (insert service provider's name here) on it"

    There's a lot of people on here who don't want to hear about your other hobby ..

    1. Destroy All Monsters Silver badge

      Re: Filed under hobbies and interests ..

      I, for one, welcome our latex-clad reg writers.

  20. Anonymous Coward
    Anonymous Coward

    ...Why not DO IT, yourself?

    From experience, as an internal customer, the enterprise IT department is not requirements driven.

    It's only interested in providing solutions which are generally one size fits all, and do not meet customer requirements (eg cost, timescales, efficiency). As a customer service provider, their attitude is take it or leave it (regardless of poor customer feedback).

    Their arrogance never ceases to amaze me - they would never tolerate such a response from real world service providers, eg banks, restaurants, shops etc.

    1. ecofeco Silver badge

      Re: ...Why not DO IT, yourself?

      Again, don't blame the department, blame the management.

      The average IT person is making less money and being asked to support more and more all the time and trust me, they see things that would make your hair curl and ask the same question: whose bright effing idea was this?

      And they are also restricted, by threat of job loss, from doing any more than they are allowed to do and as most of you know, many times a problem requires a LOT of creativity and unorthodox fixes.

      There is plenty of frustration to go around, none of which is felt in the board room.

      1. Anonymous Coward
        Anonymous Coward

        Re: ...Why not DO IT, yourself?

        The IT department should be improving its processes to ensure it meats its customers requirements. That they aren't successfully influencing the management to provide adequate resources is irrelevant to their customers. It's only because the IT departments are effectively in a monopoly position that they aren't bypassed completely.

        If you get poor service from a bank, you really don't care whether it's a resource problem, you just demand (and expect) customer satisfaction.

        IT departments aren't delivering much satisfaction.

    2. sam bo

      Re: ...Why not DO IT, yourself?

      "they would never tolerate such a response from real world service providers, eg banks"

      never really thought of a bank as a service provider, much less one I could tell what to do !

      Most people barely tolerate them, and since it is impossible to be paid without them, tolerate them we must.

  21. Anonymous Coward
    Anonymous Coward

    Job Justification!

    You can see that these postings are made by self serving techies trying to keep their jobs(nothing wrong with that but be honest)

    The reality is that most in house software is designed to support unique but not required business processes and operating models that offer no competitive advantage. Remember that the sole purpose of a company is to generate a return to shareholders and not to have IT departments.

    Most company's would benefit from streamlining business processes where that process does nothing to advance the cause of economic returns and long term share holder value.

    Anyone that has lived through a modernisation program at a bank or any similarly complex business understands that regression testing apps costs £100M's and that COTS require less remediation because the vendors work to ensure capability over multiple version/operating environments. The applications that cause the most grief are the ones that have been built in house often with little documentation.

    The goal of many ERP implementations has been to drive standardisation of business processes and most fail because of poor planning, poor change management and a focus of changing the software to the business without realising that changing the business may be the best outcome particularly where a businesses "unique way of doing things" does little or nothing to help the business compete.

    The cloud is now beginning to mature to the point where consumption of applications will no longer be a focus but the consumption of standardised services will be the main goal. This gives organisations the opportunity to externalise non critical processes and focus on those things that make them better able to compete and win.

    The most successful techies will be those that understand the world of tomorrow will be standardised business services where there is no differentiation to be gained and specialised IT services where there is. These are likely to mainly cloud sourced services in the former and on premise COTS for the latter.

    1. Roland6 Silver badge

      Re: Job Justification!

      >The most successful techies will be those that understand the world of tomorrow will be standardised business services where there is no differentiation to be gained and specialised IT services where there is.

      Sounds like the 80:20 rule we were pitching in the 90's: 80% of what a business wants IT to do adds no competitive advantage (it just allows them to participate in a market) and hence is probably best 'outsourced' (ie. purchase off-the-shelf package or service), it is the remaining 20% that makes them different and hence they want to keep tight hold of. The challenge was and is in any individual business identifying the 20% and separating it from the 80% because it is highly likely to be different even in companies operating in the same sector and offering similar products and services...

    2. Canecutter

      Re: Job Justification!

      "Remember that the sole purpose of a company is to generate a return to shareholders and not to have IT departments."

      To take your statement to its logical conclusion, permit me to make the following change. To make it compact, I will use a grammar.

      $S ::= "Remember that the sole purpose of a company is to generate a return to shareholders and not to have" $ITEM "."

      $ITEM ::= [" IT Departments" | " employees" | " capital equipment" | " managers" | " products" | " services" | " customers"]

      In other words, it is all just a means to an end. The sooner us IT folks realise that, the better it will be for us, won't it?

  22. Destroy All Monsters Silver badge

    There is no such thing as a free lunch

    Three months of IT involvement into the project the strategy document was handed to the business sponsor of the project for sign off upon which he was told “Don’t bother, one of the grads put it together weeks ago”.

    And you know exactly that horrendous amounts of bitchmoan will land on CIO's desk about "it isn't working / it's a catastrophe / where is the source code / arrrgh the results are all wrong" until the hotwired piece of junk from the bright light just out of uni is replaced with something a bit more production-ready. Sure he/she did what he/she could, but let's be realistic here.

    Suffering and entropy are what this universe is about. That and progressive automation. And self-delusion.

  23. Destroy All Monsters Silver badge

    For those interested in IEEE Software's take on this (Jan-Feb 2014 issue):

    Bespoke Infrastructures (PDF)

    "In the 1920s, the Ford Motor Company embarked on an ill-fated attempt to establish an industrial town in an Amazon rainforest as a way to secure a cultivated rubber supply for its cars’ wheels. At the time, it already owned ore mines, forests, and a steel foundry to produce the raw materials for its cars; today, it buys from external suppliers, even for its cars’ electronic control units. How do these two phases of the automotive industry’s history relate to the way we currently develop and adopt infrastructure in our profession?"

  24. itzman
    Thumb Up

    I cant but applaud this article.

    Years ago I spent upwards of £120k for a bought in product. Ultimately I wrote a better one myself in a few months.

    The thing is that finance departments like fixed price contracts. IT managers like specs and big teams.

    Actually one good guy who knows the business as well as the IT tools running a skunk works of less than 6 people, can deliver bloody miracles.

    1. jelaft

      Re: I cant but applaud this article.

      That certainly used to be the case (effective small skunk works) where I work (a bank), but no longer. It was There are unavoidable scalability and audit issues that just didn't exist even 5 years ago. Also once that team of 6 people slowly moves on, it's very difficult to maintain that constant delivery and, perhaps more importantly, support and cohesively extend the system without introducing huge amounts of technical debt. The audit and regulatory aspects are just soul destroying. As a result actual per-person productivity drops off a cliff as the team size grows to take on the load. There's not an obvious answer; agile (small 'a') just doesn't scale well and older software development practices have been shown to be very poor in the face of rapidly changing requirements.

      It's sad as those teams a great places to work, but I haven't found another industry yet that does them well. I suspect they only really survive in quite niche industries that aren't under pressure to scale or be regulated.

  25. ecofeco Silver badge

    It's all this and more

    Having now worked for some of the largest companies in the world, I can also tell you it's all this and more.

    The biggest problem I see is always the same: super tight budgets on billion dollar profits resulting in the people actually doing the work becoming very unhappy and doing the bare min to keep their jobs.

    You want custom X? And I don't get a raise or bonus? Here's my 2 weeks notice. You want us to support more new X in addition to the old X? And I don't get a raise or bonus?

    See where this is going?

  26. OzBob

    Most managers I meet

    confuse having the responsibility for seeing a decision being made, with the responsibility of actually having to make the decision. None of my senior practioner coworkers get consulted about viability of options. Most of the time a new product gets announced I ask "is this happening with us or to us"?

  27. Glen Turner 666

    I think the trick with DIY is to know when to step back. A good example is IP addressing: DHCP is here, it has worked for a decade, but the number of IT shops which have a DIY IP address allocation service. Sigh.

    Another thing is not to get caught up reinventing. Not reinventing should be the main reason for choosing a language. LOC costs pretty much the same in every language, you want the maximum amount of work done by the language so that you write the minimum LOC.

    Finally the nature of DIY has changed. These days it isn't the IT Dept going its own way. It's the IT Dept participating in a worldwide open source project which sets the future standard. This means that DIY isn't a dead end, but just the future arriving sooner.

    1. Canecutter

      The trick with DIY

      "I think the trick with DIY is to know when to step back."

      Couldn't agree more.

      "A good example is IP addressing: DHCP is here, it has worked for a decade, but the number of IT shops which have a DIY IP address allocation service."

      Agreed with one note: so far, DHCP needs to be augmented with a comprehensive means of providing the data to answer the question, 'Which station (MAC address, user, location, interface port) has IP addrss X assigned to it?' Most shops don't have such a means in place, and when there is a problem on the network, they need to perform a lot of detective work to find the offending station.

      "Another thing is not to get caught up reinventing."

      The counterweight to that would be don't become so afraid of finding yourself 'reinventing the wheel' that you fail to recognise that you do need a wheel, or you are unable to specify what kind of wheel you need.

  28. Why Not?

    Better is the enemy of good enough

    I see so many business units that have a 'special way, that is so complicated you couldn't possibly understand it' of dealing with customers in basic tasks.

    When you peel the onion, they aren't doing anything special that can't be done by the major ERP's / MRPs much better and with more standard add ons.Maybe they have one or two quirks used by 1% of the customers but these have very little effect on the bottom line or the potential to do so.

    The real benefit is when you improve their process and make sure they serve their customers better.

    And if you have thousands of sites it makes sense that every major tool is the same and supported by a Vendor or preferably multiple competing vendors rather than Dave from accounts.

    Now there are some real niche tools that can affect the bottom line. An ex employee -> contractor wrote a tool that allowed us to report on customer units and charge a good whack for it. Now those are worth doing. However ordering, building, buying & invoicing its best to get off the shelf.

    The problem is getting it across to the single business unit that they are 0.05% of the the profit so spending 10% of IT's time to increase their profit by 1% is a waste of time.

    Sorry in biggish companies standardisation is the way forward.Now getting it right is more challenging and requires clever and motivated people, most of those left years ago when the accountants took over.

    Also the business never appreciated the benefits of the one off's or the advice from IT as one guy said when I said - that is bad idea because of business reason X,Y & Z the order came down from on high 'just do it'. You guessed it XY&Z bit us in the rear. There followed a long weekend producing my original suggested solution and was greeted with 'well at least IT got it right at last'. Guess who got the payrise?

    But if you do it with standard tools then you have to do it well, that means lightening fast networks, great support & applications that work properly, the funding for those is stored with the Unicorns.

    1. Canecutter

      Re: Better is the enemy of good enough

      "Sorry in biggish companies standardisation is the way forward."

      The problem there is that quite often the standardisation is done before finding out exactly what WORKS in the situation, and then you have standardised wrongness.

      Standardisation should be treated the same way as optimisation: get it RIGHT before you standardise or optimise.

      1. Why Not?

        Re: Better is the enemy of good enough

        A point I obviously didn't address fully enough in my post then?

        I suggest you join the business you would fit right in.

  29. Anonymous Coward
    Anonymous Coward

    On DIY and satisfaction

    If I did not satisfy my users and did not make it myself, I'd be out of a job.

  30. Dave Harvey

    The PERFECT example of this was the NHS "national programme for IT"

    It managed to make every one of the mistakes in this article (and more!)

    * Contracted BIG companies with lawyers better than their IT skills

    * Totally deskilled the existing workforce

    * Cost a fortune (about £20 billion)

    * Limited choice, upgrades etc.

    And worst of all - it STILL doesn't work, and we're still paying for systems which never will deliver anything like they were promised to do

    1. Anonymous Coward
      Anonymous Coward

      Re: The PERFECT example of this was the NHS "national programme for IT"

      Often the outsourcing company hires the same people that were originally working for you directly. You gain nothing but a bigger bill and denyability for individuals neither of which are in the company's best interests.

  31. Anonymous Coward

    Just as well all dev teams are now 'agile', so we can unashamedly ship a barely functional app as it's delivering value to the business sooner.

This topic is closed for new posts.