Good catch. Thanks.

If you ask an accountant to audit a ledger, there should be one right answer (I apologize to accounting experts who now will shame me). Not necessarily so for development. Developers, if they are competent, make trade-offs in the design and value different things based on experience, what they heard the requirements were, and gut feelings about how it will work… yes I said “gut feelings”. That should terrify all of us.

Sometimes even a very good developer just goes down the wrong path. It seemed right, but didn’t turn out to be right.

Other times a cowboy coder just bangs something out that is very coupled and difficult to change. But it is WORKING… and it appears to be working software. You find out later that it has problems. Maybe it is hard to deploy, hard to manage, hard to change, or actually has subtle and serious bugs. But how is a manager going to tell the difference?

(Yes this excludes the “developer manager” where the manager in question is supposed to be a mentor/superstar, but even that developer probably reports to someone who is essentially the manager as defined in this article).

Thanks!

Done.

Why don’t you update the article to include this key point? You mention offering suggestions to help with these types of problems, and you have the power to edit the article. Give us five minutes of your time and update the article please. Luckily, I read the comments, otherwise that important information would have been lost on me. Thanks!

I would say developers should write the tests, but should be part of their creation. Really a product owner would be the one who can clearly communicate the acceptance criteria of the customer.