3 ms·

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

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.
    - gnagatomo 8y ago
      >you can see how a business is being impacted by things that you can see Strongly agree. The biggest barrier between devs and refactors with zero interface impact is AGILE mentality of always aiming to deliver value to the end user with every deploy. Business people just don't understand how much of an impact crappy implementations and error handling does have on the end user. We see 5~6% error rate, which represents hundreds of thousand of people daily, but shipping a new "feature" (that within months will be used by a few hundred people with a very high bounce rate) is always the top priority. From time to time there is a meeting with the following subject: "why are users not using the basic features", and the business people's answer is always "the ui is outdated" or "the menu is confusing the user". Those answers are gathered by talking to some random users on the streets close to the company building (I'm not making this up).
      - bobblywobbles 8y ago
        And then you end up with brittle applications to support. Not fun for devs. Not happy times with management.
      - mgkimsal 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.
  - gnagatomo 8y ago
    >you can see how a business is being impacted by things that you can see Strongly agree. The biggest barrier between devs and refactors with zero interface impact is AGILE mentality of always aiming to deliver value to the end user with every deploy. Business people just don't understand how much of an impact crappy implementations and error handling does have on the end user. We see 5~6% error rate, which represents hundreds of thousand of people daily, but shipping a new "feature" (that within months will be used by a few hundred people with a very high bounce rate) is always the top priority. From time to time there is a meeting with the following subject: "why are users not using the basic features", and the business people's answer is always "the ui is outdated" or "the menu is confusing the user". Those answers are gathered by talking to some random users on the streets close to the company building (I'm not making this up).
    - bobblywobbles 8y ago
      And then you end up with brittle applications to support. Not fun for devs. Not happy times with management.
    - mgkimsal 8y ago