4 ms·

Coders can only code, so that's what they do. Even if there's no new features needed or the old software is working fine as is, they will keep refactoring. Gott

Coders can only code, so that's what they do. Even if there's no new features needed or the old software is working fine as is, they will keep refactoring. Gotta keep up with the trends.

Hendrikto 8y ago
That does actually happen. Just look at the JS ecosystem.
- austincheney 8y ago
  As a JavaScript developer I can say that does happen, but its usually due to bad decisions from insecurity coupled with chasing trends rather than any overt act to justify thy existence.
oftenwrong 8y ago
I'd agree. Given the opportunity, programmers will often work without regard to business needs. For example, rewriting an old codebase using their favourite new stack.
- brobdingnagians 8y ago
  Totally agree, and for managers who have programmers on staff they will keep making up features without thinking about whether it is a good idea. You start getting "features" crammed in because they have to pay the programmers to do _something_.
  - calinet6 8y ago
    This is such a real thing that happens, yep. It's really hard to get people together to make good software. I think that's something everyone can agree on.
- mgkimsal 8y ago
  > For example, rewriting an old codebase using their favourite new stack. Sometimes that is a business need, but the rest of the business doesn't recognize it (or won't until it's too late). Yes, having your website running on coldfusion 5 isn't actually a problem - data comes in, data goes out, orders are filled (ecommerce, for example). If the actual business needs didn't change ever... there would not be a need to ever refactor/rebuild. And yes, I've seen "needless" refactoring, without regard for business needs. But there are folks who do understand some of the needs of the business before the other business units may realize it themselves.
  - gnagatomo 8y ago
    >Sometimes that _is_ a business need, but the rest of the business doesn't recognize it (or won't until it's too late). This. I work for a big payment system company. They had to buy another Exadata, reaching the maximum plan offered by Oracle. The refactor was delayed so much that now we have little more than one year to rewrite everything. If we don't make it in due time no more transactions will be processed. Some devs who pointed the need for a refactor left the company in the last two years and said it feels like a time bomb ticking with every git commit. Meanwhile the UI/UX guys are trying to create a design system whilst redesigning the internet banking system and app, backed by the CPO and CTO (!?). I mean, I'm not the one calling the shots, but neither a deisgn system nor redesign should be a priority for a least two years.
    - mgkimsal 8y ago
      Yep. I can't say I've worked on data at that scale, but the 'every commit is a time bomb' - had that feeling on things. What has bugged me in the past (and why I don't like being just a 'coder') is that... hey - people in my position have a perspective few others have. Sometimes we can see things that others can't, and generally we're smart enough to understand the business impact. If you're being asked to implement 'business logic' all day, for months or years, at some point, whether you want it or not, you can see how a business is being impacted by things that you can see. Raising a flag like "hey, xyz should probably be a priority..." and being dismissed because you're just a coder and don't understand the business - besides being insulting, sort of doesn't really jive with reality. In many cases, the software team are the only people that actually have a strong understanding of 'the business' - how many of the pieces fit together, etc.
dsego 8y ago
I actually agree. In my experience though, since the design is more visible to business people, it's easier to convince them it's needed. Tech debt gets attention when development grinds to a halt and productivity takes a toll. The other thing in my experience is that usually the dev is last in line when it comes to decision making, unless you have a strong tech person who can take control of the product vision and push back. But those people are rare since they have to wear multiple hats. Usually I see that designers make the design first based on some use case or story and the devs then get to code it.
jgaa 8y ago
That's the beauty of free Open Source projects. Code is written when it's required. When the project does it's job, coders move on to other useful projects.

Coders can only code, so that's what they do. Even if there's no new features needed or the old software is working fine as is, they will keep refactoring. Gotta keep up with the trends.

Hendrikto 8y ago

That does actually happen. Just look at the JS ecosystem.

austincheney 8y ago
As a JavaScript developer I can say that does happen, but its usually due to bad decisions from insecurity coupled with chasing trends rather than any overt act to justify thy existence.

oftenwrong 8y ago

I'd agree. Given the opportunity, programmers will often work without regard to business needs. For example, rewriting an old codebase using their favourite new stack.

brobdingnagians 8y ago
Totally agree, and for managers who have programmers on staff they will keep making up features without thinking about whether it is a good idea. You start getting "features" crammed in because they have to pay the programmers to do _something_.
- calinet6 8y ago
  This is such a real thing that happens, yep. It's really hard to get people together to make good software. I think that's something everyone can agree on.
mgkimsal 8y ago
> For example, rewriting an old codebase using their favourite new stack. Sometimes that is a business need, but the rest of the business doesn't recognize it (or won't until it's too late). Yes, having your website running on coldfusion 5 isn't actually a problem - data comes in, data goes out, orders are filled (ecommerce, for example). If the actual business needs didn't change ever... there would not be a need to ever refactor/rebuild. And yes, I've seen "needless" refactoring, without regard for business needs. But there are folks who do understand some of the needs of the business before the other business units may realize it themselves.
- gnagatomo 8y ago
  >Sometimes that _is_ a business need, but the rest of the business doesn't recognize it (or won't until it's too late). This. I work for a big payment system company. They had to buy another Exadata, reaching the maximum plan offered by Oracle. The refactor was delayed so much that now we have little more than one year to rewrite everything. If we don't make it in due time no more transactions will be processed. Some devs who pointed the need for a refactor left the company in the last two years and said it feels like a time bomb ticking with every git commit. Meanwhile the UI/UX guys are trying to create a design system whilst redesigning the internet banking system and app, backed by the CPO and CTO (!?). I mean, I'm not the one calling the shots, but neither a deisgn system nor redesign should be a priority for a least two years.
  - mgkimsal 8y ago
    Yep. I can't say I've worked on data at that scale, but the 'every commit is a time bomb' - had that feeling on things. What has bugged me in the past (and why I don't like being just a 'coder') is that... hey - people in my position have a perspective few others have. Sometimes we can see things that others can't, and generally we're smart enough to understand the business impact. If you're being asked to implement 'business logic' all day, for months or years, at some point, whether you want it or not, you can see how a business is being impacted by things that you can see. Raising a flag like "hey, xyz should probably be a priority..." and being dismissed because you're just a coder and don't understand the business - besides being insulting, sort of doesn't really jive with reality. In many cases, the software team are the only people that actually have a strong understanding of 'the business' - how many of the pieces fit together, etc.

dsego 8y ago

I actually agree. In my experience though, since the design is more visible to business people, it's easier to convince them it's needed. Tech debt gets attention when development grinds to a halt and productivity takes a toll. The other thing in my experience is that usually the dev is last in line when it comes to decision making, unless you have a strong tech person who can take control of the product vision and push back. But those people are rare since they have to wear multiple hats. Usually I see that designers make the design first based on some use case or story and the devs then get to code it.

jgaa 8y ago

That's the beauty of free Open Source projects. Code is written when it's required. When the project does it's job, coders move on to other useful projects.