5 ms·

> No engineer is paid extra for keeping the codebase without growing too much. I am. I'm paid more than most developers to run a team doing just this. We make

> No engineer is paid extra for keeping the codebase without growing too much. I am. I'm paid more than most developers to run a team doing just this. We make minimal change, have an absolutely non-negotiable focus on stability and minimalism and reject any change that isn't absolutely driven by validated majority user need. Even then, the bar is high. I'm not saying this is a common situation, but it certainly isn't rare in my experience. Software is a vastly wide scope of software types and requirements. I'm paid to be ruthless, and to know what ruthless looks like in terms of delivering consistently without downtime/data loss/critical issues.

kylelahnakoski 3y ago
Minimal change, or minimal code? Refactoring code can make code smaller but depends on good testing. Applying minimal changes results in redundant and complicated code, but less likely to break existing functionality.
- sirsinsalot 3y ago
  In the first instance, both. However, i'd take more code that was better reasoned and easily understood over less verbose code that was smaller for smaller sake. In terms of minimal change, we refactor when there's a clear business case to permit taking on the risk. Otherwise, we make the most minimal, most stable, least risk change to the existing code even if that code isn't optimal/pretty/well-structured/has-errors/... Like most other engineering in the world really.
  - paulryanrogers 3y ago
    IME this can be hard if built on a platform or dependencies one doesn't control, which is common at early stage companies. Because often the dependencies require surfing latest, or close enough, versions to maintain a secure system or avoid stalls for jumping major versions. Sometimes even core languages and standard libraries may require staying at least near latest versions.
    - sirsinsalot 3y ago
      This is true, but in our case all dependencies are vendored and frozen. We _do_ have instances where target systems for deployment become ABI/API incompatible with the libraries, which is rare and happens roughly every 5 years. The project was structured to put stability at the core, rather than being cutting edge.
thirdusername 3y ago
I’m also I’m a similar situation, but I get the call when the thing has been on fire for a while so it’s a lot easier. I can’t imagine a software engineer developing an interest defensive software engineering will be very visible until after there has already been a crisis to screw people’s heads on straight. A lot of people seem to see “Do things that don’t scale” and think that’s a phrase meant for engineering.
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.
jtriangle 3y ago
Bless you man, you're doing the lords work
- deleted 3y ago
  [deleted]
- sirsinsalot 3y ago
  It ain't much, but it is honest work ... ... and well paid.
wruza 3y ago
For that to happen, two things must match: a product guy who knows your job and you who know how to make products. It doesn’t even have to be stable/featureless, in my experience. New developers tend to worship some new paradigm that focuses on “how” instead of “what”, which is all paradigms can do. And once they’re in, it goes downhill because the how dominates the what. Add a clueless product guy into the mix and it loses all limits, including budget. In the end they proclaim “software is hard” and move on.
- sirsinsalot 3y ago
  I'm fortunate enough to be both the lead engineer and the person making product/design/feature decisions with the engineering team.
- whstl 3y ago
  I'm not GP but I'm in a similar situation, and yeah, this is how I do it. My Product Manager is competent both in technical and product/design matters and is also able to call BS on complexity for complexity sake. I ensure that the development part is focused. New developers have to prove with technical and business arguments any new paradigm or random refactoring they want to do. If there is no immediate need, we just skip it.
Aeolun 3y ago
> I'm not saying this is a common situation, but it certainly isn't rare in my experience. I think your experiences may be skewed by the position you find yourself in?
siilikuin 3y ago
Confirming a hypothesis I put forth in a different comment: Would you say you and your team have ownership of the product? That is to say, there isn't one team doing what you're doing and then another separate team trying to graft new features on all the time, is there? Maybe there is, and maybe that causes issues down the line.
- sirsinsalot 3y ago
  We do have ownership, and I try and structure the development such that every engineer has ownership, decision making power and accountability. I aim for a flat responsibility structure as much as possible. We have lots of work to do, lots of changes in process and despite the constraints we have a steady stream of features we do add. The trick is to ensure the culture of solid engineering goes right through the organisation and informs everything from commercial/financial through to QA.
  - solomonthewise 3y ago
    Are you guys hiring. I pride myself on writing short, simple and readable code.

kylelahnakoski 3y ago

Minimal change, or minimal code? Refactoring code can make code smaller but depends on good testing. Applying minimal changes results in redundant and complicated code, but less likely to break existing functionality.

sirsinsalot 3y ago
In the first instance, both. However, i'd take more code that was better reasoned and easily understood over less verbose code that was smaller for smaller sake. In terms of minimal change, we refactor when there's a clear business case to permit taking on the risk. Otherwise, we make the most minimal, most stable, least risk change to the existing code even if that code isn't optimal/pretty/well-structured/has-errors/... Like most other engineering in the world really.
- paulryanrogers 3y ago
  IME this can be hard if built on a platform or dependencies one doesn't control, which is common at early stage companies. Because often the dependencies require surfing latest, or close enough, versions to maintain a secure system or avoid stalls for jumping major versions. Sometimes even core languages and standard libraries may require staying at least near latest versions.
  - sirsinsalot 3y ago
    This is true, but in our case all dependencies are vendored and frozen. We _do_ have instances where target systems for deployment become ABI/API incompatible with the libraries, which is rare and happens roughly every 5 years. The project was structured to put stability at the core, rather than being cutting edge.

thirdusername 3y ago

I’m also I’m a similar situation, but I get the call when the thing has been on fire for a while so it’s a lot easier. I can’t imagine a software engineer developing an interest defensive software engineering will be very visible until after there has already been a crisis to screw people’s heads on straight. A lot of people seem to see “Do things that don’t scale” and think that’s a phrase meant for engineering.

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.

jtriangle 3y ago

Bless you man, you're doing the lords work

deleted 3y ago
[deleted]
sirsinsalot 3y ago
It ain't much, but it is honest work ... ... and well paid.

wruza 3y ago

For that to happen, two things must match: a product guy who knows your job and you who know how to make products. It doesn’t even have to be stable/featureless, in my experience. New developers tend to worship some new paradigm that focuses on “how” instead of “what”, which is all paradigms can do. And once they’re in, it goes downhill because the how dominates the what. Add a clueless product guy into the mix and it loses all limits, including budget. In the end they proclaim “software is hard” and move on.

sirsinsalot 3y ago
I'm fortunate enough to be both the lead engineer and the person making product/design/feature decisions with the engineering team.
whstl 3y ago
I'm not GP but I'm in a similar situation, and yeah, this is how I do it. My Product Manager is competent both in technical and product/design matters and is also able to call BS on complexity for complexity sake. I ensure that the development part is focused. New developers have to prove with technical and business arguments any new paradigm or random refactoring they want to do. If there is no immediate need, we just skip it.

Aeolun 3y ago

> I'm not saying this is a common situation, but it certainly isn't rare in my experience. I think your experiences may be skewed by the position you find yourself in?

siilikuin 3y ago

Confirming a hypothesis I put forth in a different comment: Would you say you and your team have ownership of the product? That is to say, there isn't one team doing what you're doing and then another separate team trying to graft new features on all the time, is there? Maybe there is, and maybe that causes issues down the line.

sirsinsalot 3y ago
We do have ownership, and I try and structure the development such that every engineer has ownership, decision making power and accountability. I aim for a flat responsibility structure as much as possible. We have lots of work to do, lots of changes in process and despite the constraints we have a steady stream of features we do add. The trick is to ensure the culture of solid engineering goes right through the organisation and informs everything from commercial/financial through to QA.
- solomonthewise 3y ago
  Are you guys hiring. I pride myself on writing short, simple and readable code.