4 ms·

stop blaming non-developers for the problems created by developers. It's the result of developer who don't have the maturity to consider the long term risk of

stop blaming non-developers for the problems created by developers. It's the result of developer who don't have the maturity to consider the long term risk of their decisions. That has nothing to do with the business leaders. I freelance which means I see a lot of shit. In any given week I can touch/work with 10+ tech stacks across both Windows and *nix. When you do that on a regular basis it gives you a different perspective on things. In particular, you write/design code in the same vein as the code around it. It doesn't matter what your personal values as a developer are. Consistency is more important than that. I have been known to pull people to the side and ask them "I'm about to do X, how do you normally do X in codebase Y? I want to do it exactly the way you do". If you're going to change the way something like a DAL accesses its data you better be able to either do all of it, or you do none of it for exactly the reasons the article stated. That is purely a technical decision, and the blame for that lies with every single developer who chose to introduce a new tech into the stack for no other reason than sensibilities.

oldmanjay 12y ago
Silly question - if we aren't to blame those poor put-upon business folks who hired the incapable, immature developer, then why is the developer accountable?
yason 12y ago
Honestly, we can't really blame the developers either. If you inherit a compilation of different techniques, there isn't much you could do to it. There isn't necessarily a code base that you could build on as the same thing is already been done in a number of different ways. So any way you're going to make changes there isn't going to make the code much better and, thus, the least worst choice would be to start gradually injecting some consistency into the codebase even if that's the fifth layer on top of the previous ones. Maybe, just possibly, the second developer could at least theoretically continue exactly from where the first developer left off (a single person or team == a single codebase that's at least somewhat consistent) but it could often make the mess even worse if the first developer really didn't have much of a clue of what he was doing. The managers are basically the customer who ordered the software and they can't be trusted to know anything. It's a very common case that the customer doesn't know what they need and it's the job of the developers to first figure out the customer's real problem before beginning prototyping.
- chris_wot 12y ago
  Thats fine for the initial stab at the problem. But then someone who does know what he is doing come along and recommends a module be rewritten and management says no, because "it's working". At this point, it's management's fault.
jghn 12y ago
I've used this same argument for why "show me your github" isn't necessarily the best way to judge a developer. My group uses github for all of our code and while it's private that might change in the future. If that happens, there are a lot of places where the answer to "why did you do X this way?" is "that's the way they do it" and not that I agreed with it. That's potentially more harm than good if someone was looking at it.

oldmanjay 12y ago

Silly question - if we aren't to blame those poor put-upon business folks who hired the incapable, immature developer, then why is the developer accountable?

yason 12y ago

Honestly, we can't really blame the developers either. If you inherit a compilation of different techniques, there isn't much you could do to it. There isn't necessarily a code base that you could build on as the same thing is already been done in a number of different ways. So any way you're going to make changes there isn't going to make the code much better and, thus, the least worst choice would be to start gradually injecting some consistency into the codebase even if that's the fifth layer on top of the previous ones. Maybe, just possibly, the second developer could at least theoretically continue exactly from where the first developer left off (a single person or team == a single codebase that's at least somewhat consistent) but it could often make the mess even worse if the first developer really didn't have much of a clue of what he was doing. The managers are basically the customer who ordered the software and they can't be trusted to know anything. It's a very common case that the customer doesn't know what they need and it's the job of the developers to first figure out the customer's real problem before beginning prototyping.

chris_wot 12y ago
Thats fine for the initial stab at the problem. But then someone who does know what he is doing come along and recommends a module be rewritten and management says no, because "it's working". At this point, it's management's fault.

jghn 12y ago

I've used this same argument for why "show me your github" isn't necessarily the best way to judge a developer. My group uses github for all of our code and while it's private that might change in the future. If that happens, there are a lot of places where the answer to "why did you do X this way?" is "that's the way they do it" and not that I agreed with it. That's potentially more harm than good if someone was looking at it.