3 ms·

I was working for a company, where the engineering team was doing this kind of refactoring, test development and what not mainteinance coding with large team fo

I was working for a company, where the engineering team was doing this kind of refactoring, test development and what not mainteinance coding with large team for about 2 years. Meanwhile not many new business features were being developed and the competition took over, and eventually everyone got fired. I think the leadership was just too lazy to actually push the development of the product, but let the engineers do this pussy work of endless refactoring was big part of the problem. Not only one of course.

jacquesm 3y ago
That's exactly it: you need balance. Not so much focus on tech for tech's sake that the competition gets to bury you but also not so little that you end up burying yourself.
- aero142 3y ago
  When senior leadership is non-technical, they can't tell when non-customer visible changes are useful or they just have mediocre engineering. They also can't tell when their software stack is such a mess it's beyond fixing.
  - blackoil 3y ago
    That's the most important job of a CTO. Communicate the cost and implications of any development done by tech team. This could be feature required by product/sales/CEO or internally by tech team.
bloopernova 3y ago
That's a great point! We don't have commercial competitors because we're an inhouse project, but there's still a balance to be made, you're right.
IshKebab 3y ago
IMO the best way is just to spend part of your time refactoring and part of your time adding features. It basically solves all the problems. You still deliver features so your company hopefully doesn't go under. And you can reduce technical debt without having to awkwardly justify not delivering features. In my experience in the medium term (~2-5 years) it doesn't even slow down feature delivery since high technical debt can have an absolutely catastrophic effect on development speed. At the previous company I worked in I'd say we delivered work at about 50% of the potential rate because the infrastructure they'd developed was so janky. A big Python/YAML/Makefile mess with zero static types. CI time was over 2 hours and used hundreds of CPU-hours, even for fixing a typo.

jacquesm 3y ago

That's exactly it: you need balance. Not so much focus on tech for tech's sake that the competition gets to bury you but also not so little that you end up burying yourself.

aero142 3y ago
When senior leadership is non-technical, they can't tell when non-customer visible changes are useful or they just have mediocre engineering. They also can't tell when their software stack is such a mess it's beyond fixing.
- blackoil 3y ago
  That's the most important job of a CTO. Communicate the cost and implications of any development done by tech team. This could be feature required by product/sales/CEO or internally by tech team.

bloopernova 3y ago

That's a great point! We don't have commercial competitors because we're an inhouse project, but there's still a balance to be made, you're right.

IshKebab 3y ago

IMO the best way is just to spend part of your time refactoring and part of your time adding features. It basically solves all the problems. You still deliver features so your company hopefully doesn't go under. And you can reduce technical debt without having to awkwardly justify not delivering features. In my experience in the medium term (~2-5 years) it doesn't even slow down feature delivery since high technical debt can have an absolutely catastrophic effect on development speed. At the previous company I worked in I'd say we delivered work at about 50% of the potential rate because the infrastructure they'd developed was so janky. A big Python/YAML/Makefile mess with zero static types. CI time was over 2 hours and used hundreds of CPU-hours, even for fixing a typo.