Comment Processes don't affect professionals... (Score 1) 460
Software professionals aren't deterred by software processes; some may B&M that writing test cases for a UI is a PITA and a waste of time, but a professional software engineer doesn't mind this extra work, because it's just part of the job. Architects, Doctors, and structural engineers have processes that they need to follow, and so should software engineers. Software engineering has only really been coming into its own in the last 30 years, so it's still a young engineering discipline, and the entire field is still struggling to come up with a guide-book.
From the stakeholder's perspective: software is crushingly expensive. It takes many man-hours to develop quality software. Project management processes used by "metal-benders" who actually produce a tangible product didn't always map well to software development practices; but 30 years ago that's all anybody had. The last 15 years has seen a huge improvement in software design processes. Much of what was thought to be the last word on the subject (SEI/CMMI, and ISO-9000) turned out to be impractical, inappropriate and/or counterproductive in the real world. Newer mentalities like Agile, and XP are much better suited, but are usually snubbed by middle management tiers because the control gates require qualitative decisions not quantitative. Any idiot can sign off on a status report if X-many bugs per Y-lines of code is met. ---But when decisions need to be made solely on subjective opinion and experience, then suddenly nobody wants to sign off on anything; requests are denied, decisions are postponed, and the project suffers. That's not a problem with processes, that's a problem of ineffective leadership, and it's endemic in the software industry. --But that's the subject of an entire other essay...