The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
We are maintaining this application and the policy is to do as little change as possible.
Add a comma? pass a triple review!
Many a times my change are rejected as not needed. And many a times, a few weeks later come a bug report that must be fixed, which was fixed by my "rejected and unnecessary" change. It just happened again.
In fact I got a new version of the app. With all those fix and more feature. We plan to use it eventually. But we must fix those bugs first! (Bug that are already fixed in that new version, btw! )
And I know, new version might have new bugs. But it's also tremendously simpler than old version (while having more functionality), i.e. it's easier to fix and likely to have less bug!
In fact many bug fix now are just about copying new code over. It's just very frustrating when old static variable have tentacle everywhere and I just can't copy new code over because it will need to update 80% of the app because of tentacular static variable reach!
I'm pretty sure I would not like to live in a world in which I would never be offended.
I am absolutely certain I don't want to live in a world in which you would never be offended.
Freedom doesn't mean the absence of things you don't like.
I work on a software development pseudo-Scrum team that sends nearly all of the actual coding work to an overseas development company. What I've observed over the last 3 years here is just how slowly and poorly the software is built (compared to my previous job). You might be tempted to think that we're just cheap, but when you figure in the cost per man-hour of delivered software, they're actually far more expensive.
The problem isn't necessarily geographic separation either (although it contributes), since we have plenty of great communication tools for non-collocated teams. In my opinion the problem is that they're deficient in critical skillets and turn over every 6 to 12 months.
While discussing these concerns with upper management, I was surprised to find that they already knew about these problems. They explained that they're not optimizing for speed, quality or cost, but rather flexibility. With the uncertainty of our yearly budget and workloads, offshore companies allow us to quickly add or remove bodies in a tight timeline. If funding is cut, we only lose a few contractors and not our more expensive systems experts.
Do any of you work for a company with the same mindset? Any ideas for either convincing the higher-ups to change, or at least for making the current process work better?
I have seen only 1 major project get anywhere near fruition, it is not there yet but getting close. IMHO the only reason it worked was that we had serious buy in from management and regularly sent BAs & PMs to oversee the project in India.
The cost was well over the initial estimates and there were many problems with the lack of domain knowledge by the developers. As the team matured this dramatically reduced both T&M and the dead ends that were ventured down. The developers are now proactive in the design of the solution which was missing early on.
Never underestimate the power of human stupidity
Good point. Perhaps part of our problem is simply that we don't retain anybody long enough to let them build domain knowledge. I've heard that they treat the positions they're in as entry-level and then leave after they've acquired enough experience.
Did you hire your offshore staff directly or through a company?
They worked through one of the major body shops. The team will probably evolve into a permanent team dedicated to the Bank I work for. I think the volume of developers fluctuated from 5 to about 20 and they had real trouble retaining devs in the initial stages. Once they had a stable core progress was a lot quicker and the error rate dropped.
By error I mean misinterpretation of requirements.
Never underestimate the power of human stupidity
Yes, to me it seems like a dedicated, collocated, cross-functional team is the obvious structure for actually getting stuff done. That's why I was surprised to hear that the choice to use offshore developers was an intentional decision based on a desire to rapidly scale teams for a business that plans budgets a year at a time.
So I wouldn't necessarily say our company is just figuring this out. I'd say they knew the limitations all along and chose to use an offshore company anyway.
Managers making the managing of people easier, by sacrificing speed, quality and profit.
I've not thought about it from that perspective before. When I was arguing for minimizing our usage of offshore companies (which is not a popular opinion around here by any means), they said it would jeopardize my own position if our budget was cut. Right now we "just" drop a few contractors when that happens.
Perhaps being part of a real team is more valuable than job security.
And their budget moves so drastically that you should be daily worried? What kind of job-security would that be? What kind of projects are those, that he must drop hired talent because of budget-issue's?
Sounds like a peanut-factory where the amount of workers has to be exactly right for the amount of harvested peanuts.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
The company itself is certainly not hurting for money. The problem is that business owners obtain funding for projects which is translated into staffing up a team for the work. If the project is delayed or cancelled, those developers can't bill to the project, which causes problems, which means they get cut. I've lost or gained developers on my team 3 or so times this year already because they were moved to or from a project.
I'm not going to pretend to understand the complexities of our budgeting around here. Unfortunately this lack of knowledge on my part means that these discussions typically end with a budget concern that "people like me" just don't understand.
Last Visit: 10-Jul-20 13:27 Last Update: 10-Jul-20 13:27