4 ms·

I feel like there's some parallel lurking here with software development. I've never seen a production codebase that doesn't have it's own share of clutter, mis

I feel like there's some parallel lurking here with software development. I've never seen a production codebase that doesn't have it's own share of clutter, mismash and rough edges similar to a disorganized desk. Moving business requirements, obscure edge cases, performance concerns all seem to creep into an "orderly" codebase. I don't think this applies to all software, things with a very long release/feedback cycle(aerospace, medical, etc) necessitate planning and careful deliberation but there's certainly a tension between order and shipping code.

mmazing 10y ago
I had no idea that I would see this parallel as well when I started reading this article. I'm in a similar situation at my current job, we've got a few guys that want to go really crazy with OOP concepts (design patterns, going overboard with new technologies) from the first sign of a new issue/feature. It really causes a lot of problems though, when your business requirements change (or you encounter an edge case) and you need to redesign the entire codebase to account for it. They are literally grinding everything to a halt with this stuff, and I think their issues arise from a need to categorize everything in the codebase prematurely, before the solution has "evolved". Thoughts?
- vvanders 10y ago
  Yeah, that's a tough one since you're dealing with a culture issue and not a technical problem. The only thing I've seen effective is prototyping a feature 2x and then taking the 2nd/3rd iteration. Finding time for that in a normal schedule is pretty hard though. Another approach if you have the option is to build the feature as rapidly as possible(within reason here obviously) and deliver it out of band. It doesn't win you an immediate friends(and may even burn a few bridges) however if you can pull it off 2-3x then you can build a reputation of getting things done. This has the potential to backfire pretty significantly though if you can't get the rest of the dev team onboard so I would be very careful about employing it.
  - mmazing 10y ago
    I'm probably in the backfire mode, as I've proven I can get things done in a good way, quickly, so I was promoted and someone else demoted (so we've effectively switched positions). 3/4 of the team is on-board with the getting things done in a good way, and the other 1/4 wants to be a slow pain in the ass.
    - vvanders 10y ago
      Yup, sounds like you're squarely in a dev culture war which is usually a bit above my pay grade. Hopefully you can find a way to bring them around since it seems you have somewhat of a consensus. Unfortunately the times I've seen that it was usually only solved by splitting the teams onto other projects or the minority leaving the company.

mmazing 10y ago

I had no idea that I would see this parallel as well when I started reading this article. I'm in a similar situation at my current job, we've got a few guys that want to go really crazy with OOP concepts (design patterns, going overboard with new technologies) from the first sign of a new issue/feature. It really causes a lot of problems though, when your business requirements change (or you encounter an edge case) and you need to redesign the entire codebase to account for it. They are literally grinding everything to a halt with this stuff, and I think their issues arise from a need to categorize everything in the codebase prematurely, before the solution has "evolved". Thoughts?

vvanders 10y ago
Yeah, that's a tough one since you're dealing with a culture issue and not a technical problem. The only thing I've seen effective is prototyping a feature 2x and then taking the 2nd/3rd iteration. Finding time for that in a normal schedule is pretty hard though. Another approach if you have the option is to build the feature as rapidly as possible(within reason here obviously) and deliver it out of band. It doesn't win you an immediate friends(and may even burn a few bridges) however if you can pull it off 2-3x then you can build a reputation of getting things done. This has the potential to backfire pretty significantly though if you can't get the rest of the dev team onboard so I would be very careful about employing it.
- mmazing 10y ago
  I'm probably in the backfire mode, as I've proven I can get things done in a good way, quickly, so I was promoted and someone else demoted (so we've effectively switched positions). 3/4 of the team is on-board with the getting things done in a good way, and the other 1/4 wants to be a slow pain in the ass.
  - vvanders 10y ago
    Yup, sounds like you're squarely in a dev culture war which is usually a bit above my pay grade. Hopefully you can find a way to bring them around since it seems you have somewhat of a consensus. Unfortunately the times I've seen that it was usually only solved by splitting the teams onto other projects or the minority leaving the company.