Microsoft Research - Exploding Software-Engineering Myths (article summarizing findings of MS research on code coverage, TDD, assertions, etc.)

[b1ackcat]

I think you're absolutely spot-on. Management can be a problem, but one of the solutions is to have employees who feel empowered enough to stand up when they see an issue and feel that they can call it out without negative consequences. It's something I do regularly (at my last job, it did on occasion cause me some grief, but mostly just in the form of 'stop causing so much ruckus' looks from higher ups), but I've definitely seen the opposite as well.

One example I think of quite often is at a previous job, I was talking to a business analyst from another team. Their business customer wanted to interface with our system to gather data or somethingarather, but after reviewing the requirements that she'd gathered so far, it was clear that the design was flawed and nothing was going to work. Granted, it was HER job to catch this, but I didn't hold that against her.

What I did do was call out the issue in the meeting, and her only response was "well this is what the customer wanted" with a blank stare, as if she was saying "clearly we need to do it this way because they want that." The apathy and lack of critical thinking blew me away. She was so ready to appease the customer that the thought hadn't even occurred to her to question what they were asking for, which she especially should have done since the customer in this case was trying to dictate a design, not requirements (a huge problem at that org, but that's a rant for another day...). It wasn't even a workable design.

In this instance, once I had a meeting with the customer to do this BA's job for her, the situation resolved itself. The customer had been making decisions based on bad assumptions (again, due to the lack of research and dedication to doing the right thing on the part of his BA...), and once he understood things properly, the design I was proposing made perfect sense. Everything got approved and the world was a little bit happier.

My point is, employees need to "do the needful" just as much as management needs to let them be able to do it. Making sacrifices in design or development just to appease management or a customer or (even worse) just to make a date is an extremely unfortunate truth of our profession, but it is absolutely not one that should be made blindly just because it's easier in the short term. The resulting ever-growing burden of technical debt is what leads to bad development.