New Post Advanced Search

Early-retirement wannabe

5.8K replies 1.2M views
1275276278280281580

Replies

  • saver861saver861 Forumite
    1.4K posts
    gadgetmind wrote: »
    All of our customers are paying millions of $ on projects that cost them 10s to 100s of millions. One teeny problem can cause major issues, and if the product is already shipping to dozens of customers, who have 100s of products available on Amazon ...

    What you are describing there is a small problem that has been replicated multiple times ... and it is that replication that has the significant negative impact. So, something that started out small puts a company's survival in danger.
    gadgetmind wrote: »
    After solving that one problem, our CEO thanked me personally, said I'd saved the company's bacon, and earned my year's salary while in the shower. (Someone else told him the shower bit!)

    Smart CEO to ensure you got the plaudits and thus increasing your motivation - a key requirement for any team leader.

    However, maybe not so smart CEO in that your skills are misused. You have described a problem that got into a product. Thats the first failure. The lateness of the discovery of that fault is the second failure, which in this case clearly impacts significantly.

    You are describing a failure of quality management procedures. A more effective quality system would have either stopped the fault from occurring in the first place, or identified it much sooner - thus not getting anywhere near the escalation it had go to.

    Of course, there is considerably less glory is identifying and halting a fault than troubleshooting it successfully at the end of the process.

    So, had you been placed at the forefront of the development process, your skills might have been even more beneficial and profitable.
    gadgetmind wrote: »
    Most people understand computers at a certain level, and specialise in either hardware or software. I understand them at every level, am happy to tackle both s/w and h/w

    Most engineers beyond user level should have an appreciation of hardware and software skills. After all, hardware is driven by software. Clearly the complexity of these applications and components is ever increasing and thus the variation of skills required.

    Not everyone will have those skills but they can be developed. It depends of course on the areas of discipline and the skills required are multi-functional.

    Most products now are developed from components and software from multiple suppliers.

    The quality management procedures apply throughout though, and my view would any company heavily reliant on a skilled troubleshooter has possibly got things wrong way round.

    gadgetmind wrote: »
    I agree, and I have good leads in every team, but they need someone to pull them together. I haven't found that someone internally and may need to recruit.

    But that person does exist - internally or externally .... and you can get your pipe and slippers and relax :D
  • SjmbSjmb Forumite
    21 posts
    The graveyards are full of people who thought they were indispensable, life goes on.
  • Sjmb wrote: »
    The graveyards are full of people who thought they were indispensable, life goes on.


    Great post
  • gadgetmindgadgetmind Forumite
    11.1K posts
    Ninth Anniversary 10,000 Posts Combo Breaker
    ✭✭✭✭✭
    saver861 wrote: »
    What you are describing there is a small problem that has been replicated multiple times ... and it is that replication that has the significant negative impact.

    Agreed. Most problems are seen quickly, the vast majority of others before product is deployed, but some are like submarines. Or mines. Yes, land mines,
    Smart CEO to ensure you got the plaudits and thus increasing your motivation - a key requirement for any team leader.
    Yup, but he's now gone after I'd worked with him for 20 years. Also gone is my old boss of 15 years. Fortunately the guy who was on the hook for the trip to Taiwan (short notice, clashed with family event) but who was excused it due to my "zany work around" is my new boss. :D
    However, maybe not so smart CEO in that your skills are misused. You have described a problem that got into a product. Thats the first failure. The lateness of the discovery of that fault is the second failure, which in this case clearly impacts significantly.
    We design some of the most complicated things that mankind makes. We put 75% of our resource into verification but things still creep through. Our competitors have just as many issues many of which are more publicly visible, which doesn't make us complacent, but does make customers just a little more understanding. Mostly.
    You are describing a failure of quality management procedures.
    I'm describing a fundamental limitation of them, which is that they can never be perfect, no matter how hard we try. We learn from every failure that gets through any stage, and have "post mortems" to try and learn how to prevent repeats, but we're always tackling the fact that 100% verification of every combinatorial case isn't possible.
    So, had you been placed at the forefront of the development process, your skills might have been even more beneficial and profitable.
    I'm there too. My team creates a lot of the heavy-duty real-world stress tests, and we keep adding test after test after test, and we work out ways to introduce as many variables as we can. Are we at 100% test? Nope, never, but there are a right lot of 9s!
    Most engineers beyond user level should have an appreciation of hardware and software skills. After all, hardware is driven by software.
    Yes, but finding people who understand every level well enough to solve problems by closing their eyes for eight hours and letting their hind brain figure it out isn't easy.
    But that person does exist - internally or externally .... and you can get your pipe and slippers and relax :D
    I really hope so.
    I am not a financial adviser and neither do I play one on television. I might occasionally give bad advice but at least it's free.

    Like all religions, the Faith of the Invisible Pink Unicorns is based upon both logic and faith. We have faith that they are pink; we logically know that they are invisible because we can't see them.
  • saver861saver861 Forumite
    1.4K posts
    Sjmb wrote: »
    The graveyards are full of people who thought they were indispensable, life goes on.

    Well the graveyards are full or near full ... not necessarily all thought they were indispensable, but some will have done - and as you say life goes on.

    The geniuses of today depended on the geniuses of the past to go that step further .....

    So life goes on, but those gone before us have contributed to our greater knowledge today ... and so forth it will go.
  • saver861saver861 Forumite
    1.4K posts
    gadgetmind wrote: »
    Agreed. Most problems are seen quickly, the vast majority of others before product is deployed, but some are like submarines. Or mines. Yes, land mines,

    As you might expect ... most are caught early ... but clearly the later these problems are caught the more expensive the impact. The concern would be twofold, one, the fact that they were not detected prior to deployment, and two, the number of faults going out post deployment.

    gadgetmind wrote: »
    We design some of the most complicated things that mankind makes. We put 75% of our resource into verification but things still creep through.

    Its not the amount of resources you put at it but the quality of the resources.

    The most complicated things that mankind makes I think is relative. Some safety critical systems may not be as complicated but clearly more important than some clever embedded system within some product or other.

    gadgetmind wrote: »
    Our competitors have just as many issues many of which are more publicly visible,

    What you mean is your competitors quality management processes are even less effective than yours!

    gadgetmind wrote: »
    I'm describing a fundamental limitation of them, which is that they can never be perfect,

    It may be a limitation of the application of the procedures rather than a limitation of the procedures. Clearly, if faults are going through then either the application of the procedures is faulty or the procedures are not fit for purpose.

    gadgetmind wrote: »
    no matter how hard we try. We learn from every failure that gets through any stage, and have "post mortems" to try and learn how to prevent repeats, but we're always tackling the fact that 100% verification of every combinatorial case isn't possible.

    Well 100% is possible but probably not practical. Designing effective testing for every combinational pathway within the application would be a near impossible task, depending on the size the application and the cohesiveness between modules etc.

    On the other hand, if faults are appearing just after deployment, then the relative testing of these pathways would seem insufficient.

    I'm reminded of a Mars Orbiter that was launched around 20 years ago, and got all the way to Mars from recollection. Then it crashed and they subsequently worked out that one team were working on an output of pounds-seconds as per requirements specification while another team of developers were working in newton-seconds.

    They flunked on the most basic of things, inconsistent output. Unfortunately the thing got all the way to mars before the error caused its impact and the subsequent post-mortem to find out what happened. I'm guessing they will compare notes on output format for future projects!!

    gadgetmind wrote: »
    Yes, but finding people who understand every level well enough to solve problems by closing their eyes for eight hours and letting their hind brain figure it out isn't easy.

    But maybe thats the problem. Is it necessary to have someone to understand every level. Perhaps the design is insufficiently decomposed so that it's modularisation is such that it should not be necessary to have a complete holistic understanding of its complexity.
  • gfpluxgfplux Forumite
    5K posts
    Part of the Furniture 1,000 Posts Photogenic Hung up my suit!
    ✭✭✭✭
    When I worked I loved my job. I found it the most fascinating thing in the world. I could talk all day about it and often did.
    Thankfully after I retired I realised it was just work.
    There will be no Brexit dividend for Britain.
  • gadgetmindgadgetmind Forumite
    11.1K posts
    Ninth Anniversary 10,000 Posts Combo Breaker
    ✭✭✭✭✭
    saver861 wrote: »
    What you mean is your competitors quality management processes are even less effective than yours!

    They are some of the largest companies in the world, investing billions into their products, using vast teams just on test and verification. Maybe we're all missing some simple trick? Doubt it.

    We have layer upon layer upon layer of tests, with some parts of the system being formally verified, some of it tested against models using pseudo-random sequences, and the whole being tested with extensive real-world "torture" tests that equate to weeks of runtime (but which take months to run because we test the product before it exists!)
    Well 100% is possible but probably not practical. Designing effective testing for every combinational pathway within the application would be a near impossible task, depending on the size the application and the cohesiveness between modules etc.

    This isn't software, nor bits of silicon being hooked up, but designing the silicon itself.
    But maybe thats the problem. Is it necessary to have someone to understand every level.

    At times, yes. If the fix involves knowing what's going wrong in the silicon (which has itself taken a long time) and then figuring out ways to exploit artefacts of how it interacts with the rest of the system to come up with a software fix that's implemented deep in the guts of an operating system, then you need someone who does have a working knowledge of every level.
    I am not a financial adviser and neither do I play one on television. I might occasionally give bad advice but at least it's free.

    Like all religions, the Faith of the Invisible Pink Unicorns is based upon both logic and faith. We have faith that they are pink; we logically know that they are invisible because we can't see them.
  • saver861saver861 Forumite
    1.4K posts
    gadgetmind wrote: »
    They are some of the largest companies in the world, investing billions into their products, using vast teams just on test and verification. Maybe we're all missing some simple trick? Doubt it.

    You would like to think not.

    Equally, as in the Taiwan example, a simple fault occurred and remained unidentified for a considerable portion of the product development lifecycle. That simple problem mushroomed to a point of threatening the company's existence.
    gadgetmind wrote: »
    We have layer upon layer upon layer of tests, with some parts of the system being formally verified, some of it tested against models using pseudo-random sequences, and the whole being tested with extensive real-world "torture" tests that equate to weeks of runtime (but which take months to run because we test the product before it exists!)

    I have no doubt your testing procedures are robust .... equally I'd like to think that the team that were responsible for the hardware and software in the aircraft I might be in was also tested exhaustively!!

    The point is though much testing is the process of identifying errors already in the system. The system can never be proven to be fault free, though its possible it might be.

    The key is to stop the error developing in the first place - whether you are dealing with silicon or a supermarket checkout system. In the Taiwan example, your CEO was no doubt very relieved that you produced a work around for the problem. Were I the CEO, I too would have been relieved - but that relief would have been dwarfed by my concern on how and why the fault lay undetected to the point of potentially putting them out of business.


    gadgetmind wrote: »
    At times, yes. If the fix involves knowing what's going wrong in the silicon (which has itself taken a long time) and then figuring out ways to exploit artefacts of how it interacts with the rest of the system to come up with a software fix that's implemented deep in the guts of an operating system, then you need someone who does have a working knowledge of every level.

    Clearly down at such levels specialist knowledge and experience is required - no question of that. Equally, if you have to write software to manipulate the behaviour of an interface between the operating system and the hardware you will indeed need knowledge of both.

    But, is that not something that is happening all the time? Much to the annoyance of many hardware manufacturers! For instance, as we all know, operating systems change relatively frequently. This may mean the interface software for some hardware needs to be redesigned or modified to continue working with the new version of the operating system.

    To be good at that particular area of expertise, I think there are two requirements - one, to have the ability and skills set to understand the various components and their interaction and two, probably just as important, is a genuine interest in that field of development.

    Those that are in a job that they enjoy doing are definitely lucky - no question of that. That may well keep many people working longer than others. That said, you can't buy back time.
  • atushatush Forumite
    18.5K posts
    Ninth Anniversary 10,000 Posts
    ✭✭✭✭✭
    Well I am in france on holiday, and am trying out a few lower cost things to do (good for retirement).

    Sipping free wine samples in the vineyards of Beaujolais, and had a 6 course meal for 24E (2 courses were amuse bouches and there was an extra plate of small things with dessert which would have made 7).

    Not bad for just over 20 quid pp.

    We nearly had a catastrophe as the OH forgot his Ipad from work, and his phone wouldnt charge at first. As I said, he has to check work emails daily in case of something big pops up. Of course, if he took responsibility for his own packing, and listened when I reminded him to pack things he was still using- wouldnt have happened.
Sign In or Register to comment.

Quick links

Essential Money | Who & Where are you? | Work & Benefits | Household and travel | Shopping & Freebies | About MSE | The MoneySavers Arms | Covid-19 & Coronavirus Support