Doug, a developer in Illinois, has written an interesting article on how difficult it is to get management to understand the importance of testing.
"To the average, well educated CIS grad programmer, well engineered software is the apex, the driver, that keeps their brains chugging. How can I automate this? How can I create a more elegant, extensible object hierarchy? How can I create tests for this code so I know it is sound and risk free to release? These questions are the cool stuff of development. The ability to answer these questions and implement solutions that embody this sort of ‘core geekery’ is the essence of being a software engineer as opposed to an amateur hacker...The rub is that if you’re writing code in a business setting, then for sure somebody is trying to figure out how to make money off this great software."
Hearing this cry from other development teams makes me proud. There was a time when this was true at our company—and some would argue that we still have a long way to go—but compared to other teams, I've found we are quite lucky.
Today, I have little trouble convincing the rest of the leadership team regarding the importance of developer unit tests, traceability, automated Quality Assurance scripting, and the like—and this is due to no extraordinary effort on my part.
Three of the management team started our careers as coders. We understand that rework is more costly than correcting problems up front. We understand—because we've learned the hard way.
No comments:
Post a Comment