3 ms·

I've dealt with lots of code which could be fixed permanently - ie. put in proper error handling and rearchitect to be robust and maintenance free. More so tha

by nikau 4y ago

I've dealt with lots of code which could be fixed permanently - ie. put in proper error handling and rearchitect to be robust and maintenance free. More so than ever with the push for MVP and agile ticket stat chasing.

brigandish 4y ago
MVP's are supposed to be temporary, that's a weird cherry pick. Regardless, code is contextual and relies on so many things other than its own quality at the time of that assessment being made that to say it's been fixed permanently, as if there's some Platonic ideal code that can be written, is, in my view, something I'd only hear from someone new to the industry or not in the industry at all, like Graeber. The job is about solving problems in the clearest way possible over time, not once. Managing change is of central importance. If your product is good, it will change. If it changes, bugs will inevitably be introduced. That's not shoddy practice or the fault of some poor architecture decision. I imagine that the only bug that gets fixed "permanently" is in a product that nobody uses enough for it to need change. Like some failed MVPs.
- nikau 4y ago
  I've been in the industry over 20 years, and in my experience agile steers everything to be MVP in the pursuit of velocity, even on projects where they are replacing an existing platform and there is no time to market benefits to rush it. And it looks great at the start, the project is making great progress until people start to leave and the tech debt starts to kick in. By that stage all the "high performance" agile rock stars have pissed off to another company and left behind their legacy. And then its death by 1000 cuts, things aren't logged correctly, no proper exception handling rather just do a print(e) and falling over, any integrations with 3rd parties aren't documented when they break and its just a mess.

by nikau 4y ago

brigandish 4y ago

MVP's are supposed to be temporary, that's a weird cherry pick. Regardless, code is contextual and relies on so many things other than its own quality at the time of that assessment being made that to say it's been fixed permanently, as if there's some Platonic ideal code that can be written, is, in my view, something I'd only hear from someone new to the industry or not in the industry at all, like Graeber. The job is about solving problems in the clearest way possible over time, not once. Managing change is of central importance. If your product is good, it will change. If it changes, bugs will inevitably be introduced. That's not shoddy practice or the fault of some poor architecture decision. I imagine that the only bug that gets fixed "permanently" is in a product that nobody uses enough for it to need change. Like some failed MVPs.

nikau 4y ago
I've been in the industry over 20 years, and in my experience agile steers everything to be MVP in the pursuit of velocity, even on projects where they are replacing an existing platform and there is no time to market benefits to rush it. And it looks great at the start, the project is making great progress until people start to leave and the tech debt starts to kick in. By that stage all the "high performance" agile rock stars have pissed off to another company and left behind their legacy. And then its death by 1000 cuts, things aren't logged correctly, no proper exception handling rather just do a print(e) and falling over, any integrations with 3rd parties aren't documented when they break and its just a mess.