In too many environments, engineers will say “that’s not a defect, it meets the requirement” when a defect report comes from system test. The engineer will then point to a document that lists the requirement. The problem here is that the requirement — as written — is WRONG. The “real requirement” is something totally different.

This is part of why agile environments do not focus so much on written documentation and insist on having access to customer representatives so they can figure out what the “real requirements” are more readily.

To me, this illustrates exactly the pain that principles and practices such as “Clean Code”, S.O.L.I.D., TDD, continuous integration, are designed to help with. (My apologies to those who dislike acronymns!)

I’m asking my team to read this. Thanks for a super post, Derick!

“where do you draw the line, at what point do you stop trying to figure out the optimal solution to your problems, and implement a workable solution?”

now that’s the $64,000,000 question! :)

I don’t know if I have a complete answer for that, yet, honestly. So far, my experience is telling me that it’s far more important to create a system that is ‘just right’ for the circumstances at hand. We have to learn how to balance everything that you said without compromising our ability to extend and enhance in the future. We need to write code that is not ‘gold plated’, but code that is flexible, small, and easy to work with – decoupled, highly cohesive, and properly encapsulating our system’s need.

I know that’s vague and wishy-washy. I think I’m able to put this answer in practice better than I’m able to explain it in words, at this point.