Saturday, April 11, 2009
How low quality is the software your enterprise writes?
Has anyone ever ran across high-quality internally-developed enterprise software? When software isn't consumed by third-parties, then quality can be order of magnitudes lower in quality...
So, if quality can be lower in enterprise inhouse software, then that allows for lower-quality resources from Indian outsourcing firms to maintain it. Remember that good is good enough and it doesn't make sense for architects to expend such energy churning on better ways of developing higher quality working software.
Indian outsourcing has caused many to lower their standards and therefore the opportunity to abuse is rampant. Methodologies such as extreme programming encourage merciless refactoring while indian outsourcing has taught us that refactoring is nothing but overhead as you have to write comprehensive documentation in order to get working software. Sometimes the effort but into documentation makes refactoring a non-starter.
Refactoring in code isn't overhead, any more than writing a first draft is overhead in writing a book. It's an inherent part of one of the best ways of producing good code, just as writing drafts is an inherent part of one of the best ways of producing a good book.
American IT professionals have lost the battle because they argued the quality front which no longer matters...
| | View blog reactionsSo, if quality can be lower in enterprise inhouse software, then that allows for lower-quality resources from Indian outsourcing firms to maintain it. Remember that good is good enough and it doesn't make sense for architects to expend such energy churning on better ways of developing higher quality working software.
Indian outsourcing has caused many to lower their standards and therefore the opportunity to abuse is rampant. Methodologies such as extreme programming encourage merciless refactoring while indian outsourcing has taught us that refactoring is nothing but overhead as you have to write comprehensive documentation in order to get working software. Sometimes the effort but into documentation makes refactoring a non-starter.
Refactoring in code isn't overhead, any more than writing a first draft is overhead in writing a book. It's an inherent part of one of the best ways of producing good code, just as writing drafts is an inherent part of one of the best ways of producing a good book.
American IT professionals have lost the battle because they argued the quality front which no longer matters...
