4 ms·

You try to explain the importance of testing and good code quality to your higher ups only to be retorted with "but we need this to be out in X weeks!". And th

You try to explain the importance of testing and good code quality to your higher ups only to be retorted with "but we need this to be out in X weeks!". And then when a production bug is revealed, they then angrily ask "why are these errors occurring?"

RikNieu 6y ago
I have PTSD just reading this.
monksy 6y ago
Or when you tell them to get to that in X weeks that you can't guarentee it against breaking bugs. Later "WE CAN"T PUT THIS IN FRONT OF A CUSTOMER"
adriancr 6y ago
I've seen the reverse happen at some companies. Managers getting taken advantage of by allowing people to do anything in the name of 'technical debt' 'code quality', resulting in more bugs, lots of needless refactoring, tons of layers of abstraction and tests that actually do close to nothing. Result is they are then surprised it takes a long time to develop new features where competitors do it faster and eat their lunch. There needs to be some sort of balance, companies need to make money to allow for proper code to be developed, second is also valuable as long as it makes sense financially as well.
- watwut 6y ago
  > allowing people to do anything in the name of 'technical debt' 'code quality', resulting in more bugs, lots of needless refactoring, tons of layers of abstraction and tests that actually do close to nothing. This heavily points to dysfunctional development team with fault being primary on tech leads making more and more mess the more they code. > companies need to make money to allow for proper code to be developed, second is also valuable as long as it makes sense financially as well. This one is merely about putting less resources on development. I don't think it fixes the dysfunctional team above, it is just avoid the issues. There is nothing that would make developers write useful tests. Nothing that would change tech leads, nothing that would prevent unmaintainable code appearing again. Had the constantly refactoring team ended with very good code for too much of price, then cutting resources is likely to lead to better trade off. But that is not their case, their case is that they don't know how to write good code.
  - adriancr 6y ago
    > This heavily points to dysfunctional development team with fault being primary on tech leads making more and more mess the more they code. You are correct. > I don't think it fixes the dysfunctional team above, it is just avoid the issues. Sometimes avoiding the issues is good. My point is that some developers cry wolf too often, focusing them on solving problems and shipping features may yield better results.
- deleted 6y ago
  [deleted]
searchableguy 6y ago
I have always wondered if there can be an AWS for employees. X1 dev, X1 designer, e2 manager, etc. You can autoscale your company through jira integration. You will save on health insurance, benefits, unproductive time, salaries etc. Only aws will need to cover that but those employees can work and scale for hundreds of companies monthly. You can have your own college and production line for people out of school so you can grade.
- illirik 6y ago
  "dev", "designer", "manager", etc. aren't interchangeable machines in the same way that compute instances are; they're human beings! Would you personally work for this "AWS for employees", with no job security, with no consistent working relationships with other people, with no knowledge of why you are doing the things you are tasked besides "the algorithm said I must do it, so I do it"? I know I wouldn't. Fortunately, this is a horrible idea that has essentially zero chance of becoming reality, as things like stable work relationships and a sense of purpose boost productivity, making employees more productive per unit labor cost than a Mechanical Turk for making more Mechanical Turks.
  - ido 6y ago
    Isn't it basically outsourcing outfits?
    - paledot 6y ago
      Yeah, but "outsourcing outfit" won't get you billions in VC funding the way "AWS for employees" will.
- joquarky 6y ago
  This sounds like the story Manna [1] by Marshall Brain. In the first half of the story, employees are increasingly micro-managed by a centralized software program which becomes more sophisticated and ubiquitous over time until humanity becomes fungible. [1] https://marshallbrain.com/manna1.htm https://marshallbrain.com/manna1.htm

RikNieu 6y ago

I have PTSD just reading this.

monksy 6y ago

Or when you tell them to get to that in X weeks that you can't guarentee it against breaking bugs. Later "WE CAN"T PUT THIS IN FRONT OF A CUSTOMER"

adriancr 6y ago

I've seen the reverse happen at some companies. Managers getting taken advantage of by allowing people to do anything in the name of 'technical debt' 'code quality', resulting in more bugs, lots of needless refactoring, tons of layers of abstraction and tests that actually do close to nothing. Result is they are then surprised it takes a long time to develop new features where competitors do it faster and eat their lunch. There needs to be some sort of balance, companies need to make money to allow for proper code to be developed, second is also valuable as long as it makes sense financially as well.

watwut 6y ago
> allowing people to do anything in the name of 'technical debt' 'code quality', resulting in more bugs, lots of needless refactoring, tons of layers of abstraction and tests that actually do close to nothing. This heavily points to dysfunctional development team with fault being primary on tech leads making more and more mess the more they code. > companies need to make money to allow for proper code to be developed, second is also valuable as long as it makes sense financially as well. This one is merely about putting less resources on development. I don't think it fixes the dysfunctional team above, it is just avoid the issues. There is nothing that would make developers write useful tests. Nothing that would change tech leads, nothing that would prevent unmaintainable code appearing again. Had the constantly refactoring team ended with very good code for too much of price, then cutting resources is likely to lead to better trade off. But that is not their case, their case is that they don't know how to write good code.
- adriancr 6y ago
  > This heavily points to dysfunctional development team with fault being primary on tech leads making more and more mess the more they code. You are correct. > I don't think it fixes the dysfunctional team above, it is just avoid the issues. Sometimes avoiding the issues is good. My point is that some developers cry wolf too often, focusing them on solving problems and shipping features may yield better results.
deleted 6y ago
[deleted]

searchableguy 6y ago

I have always wondered if there can be an AWS for employees. X1 dev, X1 designer, e2 manager, etc. You can autoscale your company through jira integration. You will save on health insurance, benefits, unproductive time, salaries etc. Only aws will need to cover that but those employees can work and scale for hundreds of companies monthly. You can have your own college and production line for people out of school so you can grade.

illirik 6y ago
"dev", "designer", "manager", etc. aren't interchangeable machines in the same way that compute instances are; they're human beings! Would you personally work for this "AWS for employees", with no job security, with no consistent working relationships with other people, with no knowledge of why you are doing the things you are tasked besides "the algorithm said I must do it, so I do it"? I know I wouldn't. Fortunately, this is a horrible idea that has essentially zero chance of becoming reality, as things like stable work relationships and a sense of purpose boost productivity, making employees more productive per unit labor cost than a Mechanical Turk for making more Mechanical Turks.
- ido 6y ago
  Isn't it basically outsourcing outfits?
  - paledot 6y ago
    Yeah, but "outsourcing outfit" won't get you billions in VC funding the way "AWS for employees" will.
joquarky 6y ago
This sounds like the story Manna [1] by Marshall Brain. In the first half of the story, employees are increasingly micro-managed by a centralized software program which becomes more sophisticated and ubiquitous over time until humanity becomes fungible. [1] https://marshallbrain.com/manna1.htm https://marshallbrain.com/manna1.htm