Not Feasible



  • Here's a quick story I just remembered.

    Back around 1981, I was friendly with a certain well-known Games Programmer, whose mother worked for British Coal (before Thatcher bashed it with her privatisation handbag) as a compensation assessor. Basically, she had a number of tables - "Lost eye= £x,000. Lost leg = £Y,000" etc., and would work out a total sum with a few simple formulae. One night, The Programmer (who was aged about 16 at the time) decided to input all the tables into his Vic20, duplicate the formulae and make her job a lot easier.

    The next day, his mother took the whole shebang - Vic20, Tape drive and TV set into work, plonked it down in front of her bosses and showed them. "Lovely" they said, "but we can't use it - he's not our Approved Computer Supplier". Fired by the idea though, they contacted their Approved Computer Supplier and asked them to duplicate this.

    A week later, they got the reply that it might be possible to do, but it would take an estimated 6 months and would cost a ridiculous amount, making it basically infeasible.



  •  Yeah perfect example of why exclusive contracts are a bad idea.  It may seem like a savings at first, but the long term cost are well beyond any savings you may receive.  This is akin to the exclusive supplier contracts our American government falls into and end up paying $100 per hammer.

    Companies like getting thier clients into exclusive contracts because now they dont have to be competitive any more.  They no longer have to work to keep thier clients, they have them chained tightly to the walls.

    This also cuts out the little guys who may be able to do a better job, faster and cheaper, we don't know because they aren't given the chance to do so.

    But, maybe this all worked out for the best as this well-known games programmer ended up not in corporate software development but creating some of the greatest games of thier time.



  • Let's see ...

    • Develop a project plan to cover all aspects
    • Figure out how it fits in to the existing infrastructure so that it scales to all users
    • Verify that you have all possible data tables that could be used
    • Implement test/development system system and create initial system
    • Do initial verification of test system
    • Create training materials and schedule classes for test group
    • Implement training of test group
    • Roll out to small test group to use on a trial basis
    • Monitor and verify use of system by test group
    • Incorporate changes requested by trial group
    • Create training materials and schedule classes for all users
    • Implement training of all users
    • Roll out to full company
    • Monitor and verify use of system by full company
    • Incorporate changes requested by full company
    • Retract use of manual tables
    • document all processes and systems used

    That could easily be a 6 month project given that British coal is/was not a small industry and that your friends mother was most likely not the only compensation assessor and most likely more than compensation assessors would need access to the data.. Implementing a proof of concept on a small scale is easy. The hard part is scaling it up and delivering it at a professional level.

    Insurance is a very cautious business, and this project is proposing to totally change the way they went about their tasks



  • @OzPeter said:

    Let's see ...

    • Develop a project plan to cover all aspects
    • Figure out how it fits in to the existing infrastructure so that it scales to all users
    • Verify that you have all possible data tables that could be used
    • Implement test/development system system and create initial system
    • Do initial verification of test system
    • Create training materials and schedule classes for test group
    • Implement training of test group
    • Roll out to small test group to use on a trial basis
    • Monitor and verify use of system by test group
    • Incorporate changes requested by trial group
    • Create training materials and schedule classes for all users
    • Implement training of all users
    • Roll out to full company
    • Monitor and verify use of system by full company
    • Incorporate changes requested by full company
    • Retract use of manual tables
    • document all processes and systems used

    That could easily be a 6 month project given that British coal is/was not a small industry and that your friends mother was most likely not the only compensation assessor and most likely more than compensation assessors would need access to the data.. Implementing a proof of concept on a small scale is easy. The hard part is scaling it up and delivering it at a professional level.

    Insurance is a very cautious business, and this project is proposing to totally change the way they went about their tasks

    QFT

    Back when I was still a teen, I did something of a similar scale for my father.  However, as I was 19, and in college, and his firm was a bit nepotistic1, I had a bit of opportunity to see that a bit farther than the above story.

    Now, the program my father wanted assistance with was not financial in nature2, and it was of very limited use.  However, to make it so that it could be used by the rest of his team and the two other teams who could've conceivably benefited from this software took more than the five weeks I had before summer vacation was up.  And that's without doing

    • Develop a project plan to cover all aspects
    • Create training materials and schedule classes for test group
    • Implement training of test group
    • Monitor and verify use of system by test group
    • Create training materials and schedule classes for all users
    • Implement training of all users
    • Monitor and verify use of system by full company
    • Incorporate changes requested by full company
    • Retract use of manual tables
    • document all processes and systems used

    (To be fair, I didn't actually

    • Roll out to full company
    , but if I'd have left that in the list, I'd have had to say that I did have time to do everything, except those items on the list.  This was the one thing the company had wanted that I didn't have time for.  That having been said, a couple of the people from the other teams did get an opportunity later on to use the "great tool", and without having the "Incorporate changes requested by full [applicable portion of the] company" step, attempting to roll it out to the full company would've been a disaster.

    The software was an enhancement to a vendor product.  Before my next summer vacation, the vendor unleashed a new version which made it obsolete.  Not that the functionality wouldn't have still been useful - it just couldn't perform the function it had been doing, as their new version neatly removed all the hooks I'd been using.

    1 At the time, he was one of the highest ranking employee who had no other family members working for them.  This is not to say he was very high up on the totem pole, however.

    2 Well, not very.  At least, the financial people had no inkling of its existence.



  • What we are talking about here is why microcomputers took over the world. When a computer became cheap enough to hide in your own budget, you no longer needed IT department authorization to create a program. Instead of months of IT assessment, you could grab an Apple II and VisiCalc and make your own spreadsheet to do the job. Then you handed copies around to your co-workers and no authorization was necessary. That's why you've got a PERSONAL computer on your desk today.



  • @AndyCanfield said:

    What we are talking about here is why microcomputers took over the world. When a computer became cheap enough to hide in your own budget, you no longer needed IT department authorization to create a program. Instead of months of IT assessment, you could grab an Apple II and VisiCalc and make your own spreadsheet to do the job. Then you handed copies around to your co-workers and no authorization was necessary. That's why you've got a PERSONAL computer on your desk today.

     

    This is also why IT has an intense dislike for these sorts of homegrown applications, because once they get distributed then whenever someone has a problem with it the first place they go for help is to IT. And then they get upset when IT says, "Huh? What are you talking about? That's not one of ours."

    I work in an IT department and have no problem with people wanting to put together their own applications to do whatever they want/need to do. If they can do it without invoking the corporate process then more power to them. But if they want to do that I also want them to be aware that they are on their own with regard to support. I've got enough "official" work to keep me busy without having to dig through someone else's spare time code.



  • Some years ago, I put together a prototype for a system to shcedule training courses online.  I used Microsoft Access because it was very quick to create the tables and forms.  I presented it to my boss and said: "This is how it can be made to work.  Now we need to program the real system."

    Of course my boss says, "Well this works really well.  Why don't we just use this?"

    I was about to explain but he was still looking at the screen.  The very next thing he clicked on, Access crashed.

    "That's why."

    So the real system was programmed, using the logic and process flows I had prototyped in Access and it worked very well for many years.



  • @Qwerty said:

    Some years ago, I put together a prototype for a system to shcedule training courses online.  I used Microsoft Access because it was very quick to create the tables and forms.  I presented it to my boss and said: "This is how it can be made to work.  Now we need to program the real system."

    Of course my boss says, "Well this works really well.  Why don't we just use this?"

    I was about to explain but he was still looking at the screen.  The very next thing he clicked on, Access crashed.

    "That's why."

    So the real system was programmed, using the logic and process flows I had prototyped in Access and it worked very well for many years.

    So what you're saying is that we should include code to induce crashes in mock-ups so they aren't used in production?

Log in to reply