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.
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.
> The justification is always "speed" but my point is that is wrong.
Not necessarily. Proper architecture takes time and planning and reasoning. If it didn't, we could make a program do it for us. There is absolutely a time tradeoff between coming up with the proper architecture for the application vs just using something that looked cool from a google project. The latter will always be faster at first, but not in the long term.
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?"
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.
100% agree. Though a lot of the churn here could be reduced with the right education and mentorship. There is a mathematics to good architectures -- a mathematics that can be taught. But currently the initiative of us are left to find the way ourselves. We need to find a way to formulate and teach this mathematics to the next generation/s so they can get there faster.
Practice. As well as trying to notice when things work or don't (I have colleagues that see "firefighting" as a normal part of a running system. If something keeps needing attention, it is probably badly written or architected).
Linus said something along the lines of bad programmers worrying about the code, and good ones worrying about the data structures. I think there is truth in this, even though I develop Django database applications most of the time. If I find myself doing too much work at the application level, taking a step back I can usually see a better approach when I rearrange the database.
Good point. How many "rockstar" developers show up at Company X, build the initial versions of a product or architecture, then move on to the next company never to understand the longer term consequences of their choices?
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
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.