3 ms·

There's lots of talk in there about office space and perks like ping pong tables and beer on tap and the like. I wonder however if "frugality" might extend to

There's lots of talk in there about office space and perks like ping pong tables and beer on tap and the like. I wonder however if "frugality" might extend to software development practices - for example, we're not going to rewrite the frontend in ReactJS this month because it's working fine as it is and we need to concentrate developer time on new (profitable) features. In other words things like "JS fatigue" (not pointing at JS in particular) are symptoms of over-staffed, over-funded teams looking for things to do.

leetrout 10y ago
I would caution a counter point that this wouldn't be a bad thing if it were reducing technical debt or improving automation. Of course, you did say avoiding it if it were working fine, but sometimes things that work fine still end up having a lot of impact on day to day routines and ability to get work completed. I'm focusing a bit more on devops so naturally I would defend my point of view and job security but I think if you have some balance in there with regards to rewriting something to reduce technical debt in some fashion would be OK. But I'd venture a guess that lots of organizations have to find that middle ground between building constantly vs remodeling / improving the foundation.
- zeemonkee3 10y ago
  "Rewriting something to reduce technical debt" is the kind of nuclear option you would use if you had money - or developer hours - to burn. Technical debt is better managed through gradual refactoring as part of the normal development processes. Of course there's still going to be a struggle between taking time to maintain code quality and sales wanting the next feature yesterday, but it's a different argument than "we want to rewrite this in shiny new framework X because someone on Hacker News said so" (not that this exact argument will be used, of course). Automation I'd see more as a sensible move, if it reduces costs in the long term. Again it may take a back seat to short term priorities, particularly when cash is short.
  - leetrout 10y ago
    Yes, indeed, I agree with all your points. And in pretty much all cases I would opt for "gradual refactoring" (and hopefully with lots of tests before starting).
  - ArkyBeagle 10y ago
    What's fun is when bitrot in the automation sets in. It's hard to gauge the long term liability of it.
- jldugger 10y ago
  > But I'd venture a guess that lots of organizations have to find that middle ground between building constantly vs remodeling / improving the foundation. > I'm focusing a bit more on devops Shiny object syndrome can affect all fields. A dev story: One of the new projects at work is an invoice automation system. For whatever reason, the initial design called for Redis as a key value store, and pgsql for their relational data. Ops already supports a ton of services on a shoestring budget, and Redis isn't currently on the list. I only found out about it when I saw a PR documenting the dependencies; they're now researching whether Postgres's hstore is compatible with their needs. Unconstrained, it's easy to end up with lavish designs that spread ops too thinly. An ops story: Containers is the big one some ops members won't be quiet about. AFAICT, it provides us no real advantage over VMs, and we're likely to deploy containers on top of openstack VMs anyways. Of course, we deploy a number of open source apps like Drupal, WordPress, and MoinMoin that would need to be re-architected to support things like immutable infrastructure. And it's not like the dev has time to support those, they'd be busy auditing and fixing their own software.
  - tixocloud 10y ago
    Very familiar with the dev story and if new technologies on the dev side make it into production, it's yet another new technology that the ops team needs to support. I can't imagine the gazillion things that one might need to know as an ops person. There definitely needs to be a balance and a negotiation between dev and ops on what can be supported and whether these new shiny objects really make a material impact.
logicfiction 10y ago
I've seen this exact case of trying to replace the front end with React. Then the recent economic climate lead to pretty much the entire team getting axed since the pre-existing codebase was working, just messy and not cutting edge.

leetrout 10y ago

I would caution a counter point that this wouldn't be a bad thing if it were reducing technical debt or improving automation. Of course, you did say avoiding it if it were working fine, but sometimes things that work fine still end up having a lot of impact on day to day routines and ability to get work completed. I'm focusing a bit more on devops so naturally I would defend my point of view and job security but I think if you have some balance in there with regards to rewriting something to reduce technical debt in some fashion would be OK. But I'd venture a guess that lots of organizations have to find that middle ground between building constantly vs remodeling / improving the foundation.

zeemonkee3 10y ago
"Rewriting something to reduce technical debt" is the kind of nuclear option you would use if you had money - or developer hours - to burn. Technical debt is better managed through gradual refactoring as part of the normal development processes. Of course there's still going to be a struggle between taking time to maintain code quality and sales wanting the next feature yesterday, but it's a different argument than "we want to rewrite this in shiny new framework X because someone on Hacker News said so" (not that this exact argument will be used, of course). Automation I'd see more as a sensible move, if it reduces costs in the long term. Again it may take a back seat to short term priorities, particularly when cash is short.
- leetrout 10y ago
  Yes, indeed, I agree with all your points. And in pretty much all cases I would opt for "gradual refactoring" (and hopefully with lots of tests before starting).
- ArkyBeagle 10y ago
  What's fun is when bitrot in the automation sets in. It's hard to gauge the long term liability of it.
jldugger 10y ago
> But I'd venture a guess that lots of organizations have to find that middle ground between building constantly vs remodeling / improving the foundation. > I'm focusing a bit more on devops Shiny object syndrome can affect all fields. A dev story: One of the new projects at work is an invoice automation system. For whatever reason, the initial design called for Redis as a key value store, and pgsql for their relational data. Ops already supports a ton of services on a shoestring budget, and Redis isn't currently on the list. I only found out about it when I saw a PR documenting the dependencies; they're now researching whether Postgres's hstore is compatible with their needs. Unconstrained, it's easy to end up with lavish designs that spread ops too thinly. An ops story: Containers is the big one some ops members won't be quiet about. AFAICT, it provides us no real advantage over VMs, and we're likely to deploy containers on top of openstack VMs anyways. Of course, we deploy a number of open source apps like Drupal, WordPress, and MoinMoin that would need to be re-architected to support things like immutable infrastructure. And it's not like the dev has time to support those, they'd be busy auditing and fixing their own software.
- tixocloud 10y ago
  Very familiar with the dev story and if new technologies on the dev side make it into production, it's yet another new technology that the ops team needs to support. I can't imagine the gazillion things that one might need to know as an ops person. There definitely needs to be a balance and a negotiation between dev and ops on what can be supported and whether these new shiny objects really make a material impact.

logicfiction 10y ago

I've seen this exact case of trying to replace the front end with React. Then the recent economic climate lead to pretty much the entire team getting axed since the pre-existing codebase was working, just messy and not cutting edge.