Twenty Years of Trying to Sabotage My Own Job
-
When I first started in development work, I had a little fear rattlin' around in the back of my mind. I was worried that efficiency might eventually cause me to run out of work. Sometimes a great big new vended product would launch - the one application to rule them all - and it would seem, for a time, that the queue was getting a bit short. Not anymore. I've argued until I'm blue in the face: for-the-love-of-code-use-the-free-version to no avail. I've seen new mega-system put into place that killed four of my applications but spawned the need for a dozen more. They'd rather pay me six figures to write something custom because, on the free version of some product in use by a million people, the description field on a tab nobody uses sits off to the side kind of funny. You cannot talk yourself out of work in the coding biz.
-
When I first started in development work, I had a little fear rattlin' around in the back of my mind. I was worried that efficiency might eventually cause me to run out of work. Sometimes a great big new vended product would launch - the one application to rule them all - and it would seem, for a time, that the queue was getting a bit short. Not anymore. I've argued until I'm blue in the face: for-the-love-of-code-use-the-free-version to no avail. I've seen new mega-system put into place that killed four of my applications but spawned the need for a dozen more. They'd rather pay me six figures to write something custom because, on the free version of some product in use by a million people, the description field on a tab nobody uses sits off to the side kind of funny. You cannot talk yourself out of work in the coding biz.
MadGerbil wrote:
When I first started in development work, I had a little fear rattlin' around in the back of my mind. I was worried that efficiency might eventually cause me to run out of work.
Me too... and everytime I am with low moral I go to the Q&A That makes all my fears disappear immediately :rolleyes: :-D
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
When I first started in development work, I had a little fear rattlin' around in the back of my mind. I was worried that efficiency might eventually cause me to run out of work. Sometimes a great big new vended product would launch - the one application to rule them all - and it would seem, for a time, that the queue was getting a bit short. Not anymore. I've argued until I'm blue in the face: for-the-love-of-code-use-the-free-version to no avail. I've seen new mega-system put into place that killed four of my applications but spawned the need for a dozen more. They'd rather pay me six figures to write something custom because, on the free version of some product in use by a million people, the description field on a tab nobody uses sits off to the side kind of funny. You cannot talk yourself out of work in the coding biz.
Slightly off topic, but relevant... Back when I worked for TRW Ballistic Missile Division, I was a Project Engineer for development of all support equipment to field and maintain a couple of ICBM systems. One assignment was a contract for $3.2 billion to develop equipment for a missile they had not yet designed! It wasn't TRW pushing this, it was the USAF, with their "parallel development" policy. I had to produce cost estimates, design and validation schedules, manpower estimates, specifications, contracts for associate contractors, all for something that didn't yet exist. Every status meeting with my management and the commanding general I asked the same thing, "Why are we doing this? It makes no sense!" I could not stop the irresistible force of bureaucratic momentum. Anyone who's ever worked in the support equipment field knows that the fielded product will change repeatedly during development, rendering all support equipment developed to date useless. It was a massive waste of money from the get go. I could compare it to trying to design a graphics card for a PC that hasn't been designed yet, and create drivers when the CPU hasn't been selected, nor a buss specified. Happily, when peace broke out a year later, all our contracts were cancelled and we all got laid off. Sometimes no matter how hard you try to put yourself out of work, stupidity overrules you. :sigh:
Will Rogers never met me.
-
Slightly off topic, but relevant... Back when I worked for TRW Ballistic Missile Division, I was a Project Engineer for development of all support equipment to field and maintain a couple of ICBM systems. One assignment was a contract for $3.2 billion to develop equipment for a missile they had not yet designed! It wasn't TRW pushing this, it was the USAF, with their "parallel development" policy. I had to produce cost estimates, design and validation schedules, manpower estimates, specifications, contracts for associate contractors, all for something that didn't yet exist. Every status meeting with my management and the commanding general I asked the same thing, "Why are we doing this? It makes no sense!" I could not stop the irresistible force of bureaucratic momentum. Anyone who's ever worked in the support equipment field knows that the fielded product will change repeatedly during development, rendering all support equipment developed to date useless. It was a massive waste of money from the get go. I could compare it to trying to design a graphics card for a PC that hasn't been designed yet, and create drivers when the CPU hasn't been selected, nor a buss specified. Happily, when peace broke out a year later, all our contracts were cancelled and we all got laid off. Sometimes no matter how hard you try to put yourself out of work, stupidity overrules you. :sigh:
Will Rogers never met me.
Funny. About 25-30 years I was experimenting with anti-fuse FPGAs. It was the era just after the appearance of HDLs (Verilog, VHDL) with the first synthesis tools. In an effort to put another weapon in my consultant background, I was studying Verilog. To check my progress, I reverse-engineered a complex peripheral (UART) of an MCU of the time, Motorola's 6805. That code was asked of me by a couple of South American students (I don't really remember which countries). One day, sometime later, an American wrote to me and asked if the code was still available. I gladly sent it to him. After two days he tells me he has fixed a couple of minor problems in the code. I synthesized it with one of the early versions of Symplicity, and I knew it was fine. So I asked him what tool he was using. He told me he had taken it to a Mentor Graphics workstation. I was amazed, as I thought he was another student. At that time such a workstation, equipped with the right software, cost no less than $250,000. Finally, he qualified as an engineer in the "Missile and Electronics" department of McDonnell Douglas.
-
When I first started in development work, I had a little fear rattlin' around in the back of my mind. I was worried that efficiency might eventually cause me to run out of work. Sometimes a great big new vended product would launch - the one application to rule them all - and it would seem, for a time, that the queue was getting a bit short. Not anymore. I've argued until I'm blue in the face: for-the-love-of-code-use-the-free-version to no avail. I've seen new mega-system put into place that killed four of my applications but spawned the need for a dozen more. They'd rather pay me six figures to write something custom because, on the free version of some product in use by a million people, the description field on a tab nobody uses sits off to the side kind of funny. You cannot talk yourself out of work in the coding biz.
As a Waterfall organization, we are massive followers of the parallel development strategy mentioned above. We are forbidden use fo the words "Waiting for ...X". Replace X with any activity that you choose. You are allowed to develop non-sense that will need to be reworked when the above mentioned X is finally delivered. Then we are not allowed to say the "Re-Work" word as that would hurt our Powers-that-be's fragile feelings. SO we use weasel words like "Proof of Concept", "Preparatory Analysis", "Planning & Resourcing". All that tomfoolery has happily sunk the entire batch of funding we sourced recently and I guess we now need to find another fine angel to see things our way. Are our jobs secure? Absolutely, the gravy train has a lot of other skin in the game stakeholders, so I guess we may run a decade or so more. You simply cannot sabotage your own job, its a feedback loop that will repair itself. Unless you do something criminal and intentional or dumb like declaring your intentions. You are simply not going to succeed in any such attempt.
-
Funny. About 25-30 years I was experimenting with anti-fuse FPGAs. It was the era just after the appearance of HDLs (Verilog, VHDL) with the first synthesis tools. In an effort to put another weapon in my consultant background, I was studying Verilog. To check my progress, I reverse-engineered a complex peripheral (UART) of an MCU of the time, Motorola's 6805. That code was asked of me by a couple of South American students (I don't really remember which countries). One day, sometime later, an American wrote to me and asked if the code was still available. I gladly sent it to him. After two days he tells me he has fixed a couple of minor problems in the code. I synthesized it with one of the early versions of Symplicity, and I knew it was fine. So I asked him what tool he was using. He told me he had taken it to a Mentor Graphics workstation. I was amazed, as I thought he was another student. At that time such a workstation, equipped with the right software, cost no less than $250,000. Finally, he qualified as an engineer in the "Missile and Electronics" department of McDonnell Douglas.
-
When I first started in development work, I had a little fear rattlin' around in the back of my mind. I was worried that efficiency might eventually cause me to run out of work. Sometimes a great big new vended product would launch - the one application to rule them all - and it would seem, for a time, that the queue was getting a bit short. Not anymore. I've argued until I'm blue in the face: for-the-love-of-code-use-the-free-version to no avail. I've seen new mega-system put into place that killed four of my applications but spawned the need for a dozen more. They'd rather pay me six figures to write something custom because, on the free version of some product in use by a million people, the description field on a tab nobody uses sits off to the side kind of funny. You cannot talk yourself out of work in the coding biz.
-
When I first started in development work, I had a little fear rattlin' around in the back of my mind. I was worried that efficiency might eventually cause me to run out of work. Sometimes a great big new vended product would launch - the one application to rule them all - and it would seem, for a time, that the queue was getting a bit short. Not anymore. I've argued until I'm blue in the face: for-the-love-of-code-use-the-free-version to no avail. I've seen new mega-system put into place that killed four of my applications but spawned the need for a dozen more. They'd rather pay me six figures to write something custom because, on the free version of some product in use by a million people, the description field on a tab nobody uses sits off to the side kind of funny. You cannot talk yourself out of work in the coding biz.
Something about no one ever got fired buying from IBM.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
Slightly off topic, but relevant... Back when I worked for TRW Ballistic Missile Division, I was a Project Engineer for development of all support equipment to field and maintain a couple of ICBM systems. One assignment was a contract for $3.2 billion to develop equipment for a missile they had not yet designed! It wasn't TRW pushing this, it was the USAF, with their "parallel development" policy. I had to produce cost estimates, design and validation schedules, manpower estimates, specifications, contracts for associate contractors, all for something that didn't yet exist. Every status meeting with my management and the commanding general I asked the same thing, "Why are we doing this? It makes no sense!" I could not stop the irresistible force of bureaucratic momentum. Anyone who's ever worked in the support equipment field knows that the fielded product will change repeatedly during development, rendering all support equipment developed to date useless. It was a massive waste of money from the get go. I could compare it to trying to design a graphics card for a PC that hasn't been designed yet, and create drivers when the CPU hasn't been selected, nor a buss specified. Happily, when peace broke out a year later, all our contracts were cancelled and we all got laid off. Sometimes no matter how hard you try to put yourself out of work, stupidity overrules you. :sigh:
Will Rogers never met me.
Not to hijack the thread further, but I believe this is quite common. I was working on a government contract where we were required to develop two separate sets of equipment to support two assembly processes for two different customers of the same contract. There were two teams running in parallel and there were not supposed to share information between the teams even though a lot of the team members worked for both teams. When election season was over, all the top brass changed which changed the scope of the project. We were not allowed to discuss which customer was which and only refer to each process by the project code name. The development times were decadal, so senior engineers would retire and come back several years later to pick up where the last activity was cancelled and mothballed by the government.
-
Not to hijack the thread further, but I believe this is quite common. I was working on a government contract where we were required to develop two separate sets of equipment to support two assembly processes for two different customers of the same contract. There were two teams running in parallel and there were not supposed to share information between the teams even though a lot of the team members worked for both teams. When election season was over, all the top brass changed which changed the scope of the project. We were not allowed to discuss which customer was which and only refer to each process by the project code name. The development times were decadal, so senior engineers would retire and come back several years later to pick up where the last activity was cancelled and mothballed by the government.
I believe you're right, in that this stuff happens all the time, always to the detriment of the taxpayer. I recall one I helped produce a bid package for - same product, two different military branches. Final day of proposal preparation, one branch sent us a new, 300 page spec change. We declined to play.
Will Rogers never met me.
-
When I first started in development work, I had a little fear rattlin' around in the back of my mind. I was worried that efficiency might eventually cause me to run out of work. Sometimes a great big new vended product would launch - the one application to rule them all - and it would seem, for a time, that the queue was getting a bit short. Not anymore. I've argued until I'm blue in the face: for-the-love-of-code-use-the-free-version to no avail. I've seen new mega-system put into place that killed four of my applications but spawned the need for a dozen more. They'd rather pay me six figures to write something custom because, on the free version of some product in use by a million people, the description field on a tab nobody uses sits off to the side kind of funny. You cannot talk yourself out of work in the coding biz.
Just talked to a customer today that we developed an application for 10 or so years ago. We didn't win the follow-on builds for political reasons. What I learned was that our system and the newer versions' learnings were scrapped in favor of "doing it better our way". Well, the first systems used FPGA/embedded devices. The current vendor is trying to replicate the embedded devices with the equivalent of a 386 processor running DOS. The application was precision load control running at 50kHz sample rate with a load fault detection time of less than 100us. Not very possible with non-realtime systems. Customers will always want to have an application "their way" because Burger King said they could have it.