5 ms·

What kind of software do you work on? At what company? I have seen low level parts that are managed well, because employees have skin in the game But I’ve al

by chubot 3y ago

What kind of software do you work on? At what company? I have seen low level parts that are managed well, because employees have skin in the game But I’ve also seen a lot of what this post is talking about

bombolo 3y ago
Until you have the star developer that starts promising the product manager he can do all the extra features in a week. And then of course none of them actually work decently or at all. But at that point it must be maintained by the whole team anyway.
- sirsinsalot 3y ago
  Well yes, but I have veto power for that reason, as lead engineer. I am the lead because I know, from experience, not to allow this kind of nonsense to happen.
whstl 3y ago
I'm in the same boat as GP. I work in finance. CTO said he wanted to keep things simple and stable, so I do it. It is only possible because I'm a technical manager myself and I have a very competent (and technical) product manager working with me. But for every person like me, there are 10 other devs trying to cram every pattern from the GoF book in their corner of the codebase, so I have to spend my scarce time reviewing PRs.
- sirsinsalot 3y ago
  Am GP, it is finance based, but not commercial finance. Most of the systems handle complex calculations. The system is a monolith that has been around for 15 years or so. It isn't cool. It isn't pretty. Lots of it would be better for a refactor, but absolute stability is the goal. Refactoring things may result in long-term cost savings, but with risk. The business has no risk appetite, so it doesn't make sense. If it works, it stays, however ugly and costly. That isn't to say some things don't get refactored, but there's a strict business case that needs to be met. Usually if the system is under performing, error-prone or end-users want features/performance that can't be accommodated without a refactor. It's nice. The latest framework isn't being integrated year after year, there's no microservices, nothing fancy. It's java. It's tested. It works. It makes money. It pays.
  - wruza 3y ago
    Interesting, I believe there is something to finance that allows or forces things this way. There’s much less fidget spinning and much more business in it for some reason.
    - lazyasciiart 3y ago
      Regulations, I’m guessing.
      - whstl 3y ago
        Regulations are a good excuse, but there is still a lot of fuckery in Finance apps, especially in the Fintech space. Stability is something that must be culturally hammered and enforced by leadership. If it's done by stakeholders, the app will look simple but still be a juggernaut of over-engineering underneath.
    - SgtBastard 3y ago
      Regulations (as sibling comment mentioned) is one aspect, but also the cost of screwing up is real-world. A status quo system that isn’t screwing up has a much higher bar to replace where the risk that the replacement system will screw up. Much of the same reasoning and even more extremely applied, is medtech - hence why you see many medical imaging setups still obviously running a version of Windows XP.
    - sirsinsalot 3y ago
      Regulation and risk. The same applied to government too. The cost (financial, legal, reputation) of certain classes of bugs is so high that avoiding those risks becomes top concern. One calculation issue, one buggy float operation means millions or billions in damage and the loss of your clients ... never to return ... because your name is tarnished. I actually think this is _wrong_ and we need better resiliency in finance to being able to roll-back transactions and rewind and replay with adjustments.
abhibeckert 3y ago
I work at a consulting firm. Our salary is loosely linked to what percentage of our work is billable (with leniency for inexperienced staff, who aren't expected to be profitable while they're learning their craft). If you spend three hours figuring out why things fall apart on the 31st of the month... that generally can't be billed to the client, and therefore it's bad for your salary. On the other hand, if you spend three hundred hours writing tests and implementing an awesome multi-stage deployment process that avoids one production bug a month? Your manager can totally bill that work (with the right client).
- sirsinsalot 3y ago
  I would argue the billing model, client relationship and everything else commercial isn't running effectively at that firm. If I were a client, I wouldn't want these perverse incentives to exist. I would want a razor sharp focus on _my_ needs, and assurance that _my_ needs are modelled in the billing. And for that, I would pay more.
- MSFT_Edging 3y ago
  Why is the bug fix not billable, but the test writing is?

by chubot 3y ago

bombolo 3y ago

Until you have the star developer that starts promising the product manager he can do all the extra features in a week. And then of course none of them actually work decently or at all. But at that point it must be maintained by the whole team anyway.

sirsinsalot 3y ago
Well yes, but I have veto power for that reason, as lead engineer. I am the lead because I know, from experience, not to allow this kind of nonsense to happen.

whstl 3y ago

I'm in the same boat as GP. I work in finance. CTO said he wanted to keep things simple and stable, so I do it. It is only possible because I'm a technical manager myself and I have a very competent (and technical) product manager working with me. But for every person like me, there are 10 other devs trying to cram every pattern from the GoF book in their corner of the codebase, so I have to spend my scarce time reviewing PRs.

sirsinsalot 3y ago
Am GP, it is finance based, but not commercial finance. Most of the systems handle complex calculations. The system is a monolith that has been around for 15 years or so. It isn't cool. It isn't pretty. Lots of it would be better for a refactor, but absolute stability is the goal. Refactoring things may result in long-term cost savings, but with risk. The business has no risk appetite, so it doesn't make sense. If it works, it stays, however ugly and costly. That isn't to say some things don't get refactored, but there's a strict business case that needs to be met. Usually if the system is under performing, error-prone or end-users want features/performance that can't be accommodated without a refactor. It's nice. The latest framework isn't being integrated year after year, there's no microservices, nothing fancy. It's java. It's tested. It works. It makes money. It pays.
- wruza 3y ago
  Interesting, I believe there is something to finance that allows or forces things this way. There’s much less fidget spinning and much more business in it for some reason.
  - lazyasciiart 3y ago
    Regulations, I’m guessing.
    - whstl 3y ago
      Regulations are a good excuse, but there is still a lot of fuckery in Finance apps, especially in the Fintech space. Stability is something that must be culturally hammered and enforced by leadership. If it's done by stakeholders, the app will look simple but still be a juggernaut of over-engineering underneath.
  - SgtBastard 3y ago
    Regulations (as sibling comment mentioned) is one aspect, but also the cost of screwing up is real-world. A status quo system that isn’t screwing up has a much higher bar to replace where the risk that the replacement system will screw up. Much of the same reasoning and even more extremely applied, is medtech - hence why you see many medical imaging setups still obviously running a version of Windows XP.
  - sirsinsalot 3y ago
    Regulation and risk. The same applied to government too. The cost (financial, legal, reputation) of certain classes of bugs is so high that avoiding those risks becomes top concern. One calculation issue, one buggy float operation means millions or billions in damage and the loss of your clients ... never to return ... because your name is tarnished. I actually think this is _wrong_ and we need better resiliency in finance to being able to roll-back transactions and rewind and replay with adjustments.

abhibeckert 3y ago

I work at a consulting firm. Our salary is loosely linked to what percentage of our work is billable (with leniency for inexperienced staff, who aren't expected to be profitable while they're learning their craft). If you spend three hours figuring out why things fall apart on the 31st of the month... that generally can't be billed to the client, and therefore it's bad for your salary. On the other hand, if you spend three hundred hours writing tests and implementing an awesome multi-stage deployment process that avoids one production bug a month? Your manager can totally bill that work (with the right client).

sirsinsalot 3y ago
I would argue the billing model, client relationship and everything else commercial isn't running effectively at that firm. If I were a client, I wouldn't want these perverse incentives to exist. I would want a razor sharp focus on _my_ needs, and assurance that _my_ needs are modelled in the billing. And for that, I would pay more.
MSFT_Edging 3y ago
Why is the bug fix not billable, but the test writing is?