The Lounge is rated PG. If you're about to post something you wouldn't want your
kid sister to read then don't post it. No flame wars, no abusive conduct, no programming
questions and please don't post ads.
I know the feeling. I work for a small software firm and our primary product is so mired in old code (much of it Borland OWL which pretty much only one person in the company touches these days), that any attempt to improve the product is met with the same "that will be a ton of work that we can't do because we need to concentrate on new features".
I almost always end up implementing new methodologies in my off-time or in projects that are entirely within my control, and slowly begin interfacing the legacy code to use them in "baby steps" ("what about Bob?"). We have countless requests for specific improvements that have literally all been handled in a "proof of concept" I wrote a few years ago, but until I can mirror all of our internal and external legacy API calls, there is no way to drop in this new system. That proof of concept was proven to be faster, more memory efficient, more fault tolerant and more resilient to abnormally high concurrent transaction counts than our old legacy system, while also opening up the door for a clustered parallel processing solution.
4 years later, that "proof of concept" still has not been implemented in our product because of the fear of beginning a new branch that could get out of date with current fixes while in development. (Though, I have it running as an alternate service provider for several of my projects on one of my test servers.)
An analogy just occurred to me. Re-writing software in a different framework or language might be like switching a petrol engine car to electric.
For most users (bosses included), when they sit in the new car, and don't see or feel anything different, they might wonder why all the fuss and cost.
But it's more efficient. The engine kicks in 0.2 seconds vs 2 seconds.
Running cost will be lower.
Fixing things will be simpler because fewer moving parts.
It will be easier to re-use the engine across other cars, reducing the development time of those (repeat time might be reduced but initial development expense might mean return takes a few years - long term planning for the win)
Boss: "And it will look and feel the same"?
You: "Yes, with those additional things you want!"
Boss: "But you could add those additional things to the existing version?"
You: "I will go back to my dungeon and add the feature to allow a user to define how big they want the buttons to be."
I'm so tired of government contract work...we don't have the time/desire to do it at work, and you'd think I was trying to hack the freakin Pentagon.
It was my understanding that government contracts were based on dollars for features. Thus if it isn't in the contract then it should not be done in the first place.
To be fair however that is how all contracts work. The developer doesn't get paid to work on what they want - they are paid to work on what the customer wants.
One is of course free to convince the customer that they should want something else. And produce another contract. However that role is seldom one that a developer will be doing.
Somewhat reasonable of course given that normal businesses end up in the situation where they find that a developer has spent the last month working on something that they are sure is better (although often being able to quantify that is non-existent) rather than what they were supposed to be and said they were working on. Not to mention that they fail to consider the actual cost to the business such as impacts like the cost to re-test the entire stack or even actual impacts to customer processes.
Not all contracts are time/material. The last one I was on wasn't, but this one is. All that means to me is that we can hire more people if we can justify it. The problem with that is that anyone we hire MUST have the contract-specified certifications before we can hire them, and finding devs with Security+ AND CSSLP is like looking for hen's teeth.
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
Or... it could be the gates of hell opening up to usher in new development work on technology that hasn't been supported for 15 years.
"When you are dead, you won't even know that you are dead. It's a pain only felt by others; same thing when you are stupid."
Ignorant - An individual without knowledge, but is willing to learn. Stupid - An individual without knowledge and is incapable of learning. Idiot - An individual without knowledge and allows social media to do the thinking for them.
But it was built from QA and SO code fragments cobbled together by a Guru ... who left six weeks ago.
So you did have a second job.
"I controlled my laughter and simple said "No,I am very busy,so I can't write any code for you". The moment they heard this all the smiling face turned into a sad looking face and one of them farted. So I had to leave the place as soon as possible." - Mr.Prakash One Fine Saturday. 24/04/2004
The Grain is Big Data.
You, the developer, are the Hen -- you must consume the Grain.
The Fox is Corporate Security who won't let you in the same room as the Grain and won't let you have the tools to consume it even if they did.