20% of the work meaning implementing only functional requirements and neglecting non-functional requirements. Error handling, monitoring, security, configuratio

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.