4 ms·

It takes a certain amount of time to build a house (that will be durable and to code) no matter how much people want "skill sets". If it takes a longer time th

by pekk 12y ago

It takes a certain amount of time to build a house (that will be durable and to code) no matter how much people want "skill sets". If it takes a longer time than management wanted for something to be built, that isn't necessarily because "skill sets" are lacking. If the product is shoddy, that is probably not because the team lacked the magical ability to make sound products instantly, but because the team was rushed (on the theory that they are not professionals and have to be micromanaged) The odds are that the feature spec was bloated and management was bad at estimation (perhaps because they demanded estimates out of programmers who are also not good at estimation, in a bid to squeeze as much output from them as possible). Hackers aren't the problem. A pogrom on "hackers" is unlikely to solve anything. "Professional" in the sense of wearing this or that, or following whatever you personally consider to be best practices isn't going to fix scope creep, wrong estimation, fundamental facts about project coordination, or the laws of physics. Building serious stuff takes time. It's management's job to handle that without flipping its shit.

Ma8ee 12y ago
The problem is that anyone who know how to attach two boards with a few nails think they know how to build a house.
wellpast 12y ago
I'm not saying that it doesn't take time to build software and I'm not making a case for how to do management. In my decade of experience on different teams and products, the main impedance to productivity has by far been to do with bad code and architectural choices. The justification is always "speed" but my point is that is wrong. It's not speed that is at fault, it's that most software engineers don't know how to properly engineer software -- they haven't been taught nor had the time to learn it. It's absolutely an issue of skill sets. Yes, management and project estimation are other issues to work out. I'd say we're actually much further along on these fronts than we are on the technical skill sets front. That is, the skill set of building architecturally sound systems.* * Note: I do believe there is a time trade off between features and feature flexibility -- but there is no time trade off necessary for achieving architectural soundness, again so long as the right (presently rare) skill sets are present.
- curiousHacker 12y ago
  Describe good architectural choices?
  - einhverfr 12y ago
    That's a product of context is it not? And of course part of the context is the rest of the current architecture. I think in the end the best architecture is that which is thought through from a contract-oriented approach, rather than a buzzword checklist.
  - thisGuysAccount 12y ago
    There are three types of "good architectural choices" The first: The ones that can be made after the original, bad ones. The second draft, which is an improvement in the first draft, in every field. The second: His (or her) own. We all know there are developers out there who think they're the greatest thing to ever write code, and that everyone else's decisions are bad. The third: The ones that really should have been made, in place of the ones that really shouldn't have been made. As in, "You wrote your own SQL parser using hardcoded strings and no grammar parsers?"
    - tragic 12y ago
      > As in, "You wrote your own SQL parser using hardcoded strings and no grammar parsers?" (Shuffles away sheepishly)
  - maigret 12y ago
    There are some methodologies for this: http://en.wikipedia.org/wiki/Architecture_tradeoff_analysis_method http://en.wikipedia.org/wiki/Architecture_tradeoff_analysis_...
  - wellpast 12y ago
    You've probably heard it as ones that lead to low-coupling and high-cohesion, which is correct. But in my experience this needs to be made more concrete -- many people can say these words, but couldn't tell you accurately to what degree a system was cohesive and uncoupled.
zenogais 12y ago
This is exactly my experience. The vast majority of software failures are the results of dysfunction outside of the software team - this is why more best practices or process rarely fix the issue, it was an organization one to begin with. In my career there's been a strong correlation between healthy functional organizations and healthy functional software

by pekk 12y ago

Ma8ee 12y ago

The problem is that anyone who know how to attach two boards with a few nails think they know how to build a house.

wellpast 12y ago

I'm not saying that it doesn't take time to build software and I'm not making a case for how to do management. In my decade of experience on different teams and products, the main impedance to productivity has by far been to do with bad code and architectural choices. The justification is always "speed" but my point is that is wrong. It's not speed that is at fault, it's that most software engineers don't know how to properly engineer software -- they haven't been taught nor had the time to learn it. It's absolutely an issue of skill sets. Yes, management and project estimation are other issues to work out. I'd say we're actually much further along on these fronts than we are on the technical skill sets front. That is, the skill set of building architecturally sound systems.* * Note: I do believe there is a time trade off between features and feature flexibility -- but there is no time trade off necessary for achieving architectural soundness, again so long as the right (presently rare) skill sets are present.

curiousHacker 12y ago
Describe good architectural choices?
- einhverfr 12y ago
  That's a product of context is it not? And of course part of the context is the rest of the current architecture. I think in the end the best architecture is that which is thought through from a contract-oriented approach, rather than a buzzword checklist.
- thisGuysAccount 12y ago
  There are three types of "good architectural choices" The first: The ones that can be made after the original, bad ones. The second draft, which is an improvement in the first draft, in every field. The second: His (or her) own. We all know there are developers out there who think they're the greatest thing to ever write code, and that everyone else's decisions are bad. The third: The ones that really should have been made, in place of the ones that really shouldn't have been made. As in, "You wrote your own SQL parser using hardcoded strings and no grammar parsers?"
  - tragic 12y ago
    > As in, "You wrote your own SQL parser using hardcoded strings and no grammar parsers?" (Shuffles away sheepishly)
- maigret 12y ago
  There are some methodologies for this: http://en.wikipedia.org/wiki/Architecture_tradeoff_analysis_method http://en.wikipedia.org/wiki/Architecture_tradeoff_analysis_...
- wellpast 12y ago
  You've probably heard it as ones that lead to low-coupling and high-cohesion, which is correct. But in my experience this needs to be made more concrete -- many people can say these words, but couldn't tell you accurately to what degree a system was cohesive and uncoupled.

zenogais 12y ago

This is exactly my experience. The vast majority of software failures are the results of dysfunction outside of the software team - this is why more best practices or process rarely fix the issue, it was an organization one to begin with. In my career there's been a strong correlation between healthy functional organizations and healthy functional software