I think that he's right about his facts but not necessarily about the spin he puts on those facts. The thing is, it really is important to get stuff out the door, and it's really not important to have the best quality possible (consider: how many of us have hand-stitched shirts from hand-woven cloth?). Rather than fight those facts, I choose to embrace them: the challenge is to ride the wave, to figure out the most economical way to produce the best quality possible within one's constraints. That's pretty fun.
I'd agree, it's not all evil. As a "politician" I can identify with his commentary though. One thing he got wrong though about technical qualifications not mattering... while true you don't really get to apply the technical skills but they are a must for the credibility you need to deliver the "unsustainable" pace.
To your point about getting software out the door. I've run into a type of developer on more than one occasion that I call "refactoring kings". Invariably, they're on the hunt for commits and how they can make it "better". Of course any 20 lines of code has the possibility of being refactored infinitely to a better state.
That said, the post was pretty spot-on, if a little tongue-n-cheek. The trick is to know what battles to fight. I've recently come aboard a small team where the main developer is more of a DBA than "coder", so there's lots of best practices missing. But we're in a startup mode, and I don't have the time to refactor the whole damn thing. If I see something egregious, I'll fix it, but there's code battles that I'll defer for another day.
I come across these types of "refactor kings" in most areas, not just on the dev front but in architecture, business process improvement, etc. "Better" seems to be like beauty (in the eye of the beholder).
I have tried to change the culture I work in to be more focused on quantifying "better". This is difficult for software people especially, who cannot (or will not) make the connection between their contribution and the overall business.
I enjoyed the post, but I'd like to play contrarian a bit more.
I see way to many developers with absolutely no sense of urgency. I'm not talking about beating the drums of a death march, but at least envisioning the finish line, instead of riding along for the process.
The bottom line is that when we're getting paid to write software, we're doing it for an end-goal and not for the sake of agile/scrum.
5 comments
[ 3.4 ms ] story [ 20.2 ms ] threadThat said, the post was pretty spot-on, if a little tongue-n-cheek. The trick is to know what battles to fight. I've recently come aboard a small team where the main developer is more of a DBA than "coder", so there's lots of best practices missing. But we're in a startup mode, and I don't have the time to refactor the whole damn thing. If I see something egregious, I'll fix it, but there's code battles that I'll defer for another day.
I have tried to change the culture I work in to be more focused on quantifying "better". This is difficult for software people especially, who cannot (or will not) make the connection between their contribution and the overall business.
I see way to many developers with absolutely no sense of urgency. I'm not talking about beating the drums of a death march, but at least envisioning the finish line, instead of riding along for the process.
The bottom line is that when we're getting paid to write software, we're doing it for an end-goal and not for the sake of agile/scrum.