3 ms·

Short of more details, this sounds like organizational failure as a whole versus the failure of one developer. Was this one developer the founder or something?

Short of more details, this sounds like organizational failure as a whole versus the failure of one developer. Was this one developer the founder or something? It doesn't make sense they got away with so much and no push back from the team? Should it be one developers job to do more than 20% of the job when it comes to shipping an entire companies products/services? It feels like you're poo-pooing the idea of a Lone Ranger coder, while being annoyed the person didn't do 100% of the work? If it's supposed to be a team effort, why should they do more than 20% of the job. The rest of the team should be contributing the other 80%. Sounds like they were there and fired before you even started. So I'm going to have to /dev/null this post as hearsay. Having a hard time understanding how this isn't downvoted to oblivion. With all the rhetoric here about quality content and posting only that which moves conversations in a constructive way, this ends up being full of holes and after the fact blame gaming. Rarely useful.

partycoder 10y ago
20% of the work meaning implementing only functional requirements and neglecting non-functional requirements. Error handling, monitoring, security, configuration, maintainability, unit testing, performance, scalability, etc. I think that is a personal responsibility to some extent. Even if you are doing agile or your team is small. If you don't plan to engage those requirements immediately, they need to be communicated to your stakeholders (e.g: in the form of a task in your backlog, though many of these might require refactoring/rework). Stakeholders should be aware of their completion status to make informed decisions around priorities and risk management. In an analogy, a non-functional requirement is not "adding a room to a house", it is "the construction material and construction standard to build a room". It is not something that can be added later on without rework. If they mindfully decide to accept the risks of neglecting functional requirements, it's fine, but that's their decision to make. It should not be a surprise later on that those requirements are not implemented. Then, yes, it was an organizational failure. The person was one of the first hires. But I am talking from the perspective of the article being discussed. Management put the character of the individual over skills in their hierarchy of relevance at the moment of hiring, with the results I mentioned. Then, it's not "hearsay". Evidence left: tickets, code, etc. Reading code that reflects someone not understanding CS fundamentals is not hearsay.

partycoder 10y ago

20% of the work meaning implementing only functional requirements and neglecting non-functional requirements. Error handling, monitoring, security, configuration, maintainability, unit testing, performance, scalability, etc. I think that is a personal responsibility to some extent. Even if you are doing agile or your team is small. If you don't plan to engage those requirements immediately, they need to be communicated to your stakeholders (e.g: in the form of a task in your backlog, though many of these might require refactoring/rework). Stakeholders should be aware of their completion status to make informed decisions around priorities and risk management. In an analogy, a non-functional requirement is not "adding a room to a house", it is "the construction material and construction standard to build a room". It is not something that can be added later on without rework. If they mindfully decide to accept the risks of neglecting functional requirements, it's fine, but that's their decision to make. It should not be a surprise later on that those requirements are not implemented. Then, yes, it was an organizational failure. The person was one of the first hires. But I am talking from the perspective of the article being discussed. Management put the character of the individual over skills in their hierarchy of relevance at the moment of hiring, with the results I mentioned. Then, it's not "hearsay". Evidence left: tickets, code, etc. Reading code that reflects someone not understanding CS fundamentals is not hearsay.