Comments on: Programming for Maintenance http://www.formatexception.com/2010/02/programming-for-maintenance/ Ramblings on developing in the Windows World Fri, 07 Oct 2011 21:45:11 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: Tyler Coles http://www.formatexception.com/2010/02/programming-for-maintenance/comment-page-1/#comment-155 Tyler Coles Wed, 10 Feb 2010 22:10:12 +0000 http://www.formatexception.com/?p=270#comment-155 Regarding requirements gathering: I would go so far as to say that frequent iterative development/prototyping is the only way to develop. No one ever knows what they want an application to do. If you're lucky you know "what do I want it to do right now?" which can change on a day to day basis anyway. This isn't a fault; it's the nature of the game. If you make the iterations frequent enough, you minimize "lost" effort if the client wants to change direction mid-stream. But I wouldn't even call it lost effort. It's effort that was spent to discover the true needs of the application. I'm also convinced that automated testing (unit- and functional-tests) is the most important piece to make a site maintainable. Especially in large applications, maintainers need to be free to make changes without worrying about breaking a component that has an unknown dependency on the piece being changed. With good automated tests, I should know right away that I broke something and I'll know right away when I've fixed it. This might even point out inherent design flaws. To take that one step further: an application without automated tests is already broken, you just don't know it yet. Unit tests don't stop you from writing buggy code (or buggy unit tests) but they do give you the freedom to make changes. Even better, writing unit tests will point out how terrible your OO design is. You can't unit test procedural code. You can't unit test code that is tightly coupled with other components. I'm not saying development ought to be Test Driven, more like Test Assisted, but I definitely feel like developing without tests is negligent engineering. Regarding requirements gathering: I would go so far as to say that frequent iterative development/prototyping is the only way to develop. No one ever knows what they want an application to do. If you’re lucky you know “what do I want it to do right now?” which can change on a day to day basis anyway. This isn’t a fault; it’s the nature of the game. If you make the iterations frequent enough, you minimize “lost” effort if the client wants to change direction mid-stream. But I wouldn’t even call it lost effort. It’s effort that was spent to discover the true needs of the application.

I’m also convinced that automated testing (unit- and functional-tests) is the most important piece to make a site maintainable. Especially in large applications, maintainers need to be free to make changes without worrying about breaking a component that has an unknown dependency on the piece being changed. With good automated tests, I should know right away that I broke something and I’ll know right away when I’ve fixed it. This might even point out inherent design flaws.

To take that one step further: an application without automated tests is already broken, you just don’t know it yet. Unit tests don’t stop you from writing buggy code (or buggy unit tests) but they do give you the freedom to make changes. Even better, writing unit tests will point out how terrible your OO design is. You can’t unit test procedural code. You can’t unit test code that is tightly coupled with other components. I’m not saying development ought to be Test Driven, more like Test Assisted, but I definitely feel like developing without tests is negligent engineering.

]]>