June 15, 2010 Leave a comment
I use this term to describe the tendency of enterprises to look at products not for what they offer but for what we need to move around.
It’s like fitting square pegs into round holes; spending untold sums of money and time to make changes to native functionality that turn out to be more simply solved by minor business process adjustments. There are many examples of what could be a more agile and rapid development process instead taking some off the shelf product and beating the crap out of it. Doing that, however, requires restraint on the part of the Business Analysts and Project Managers that develop rigid requirements at the expense of practical, native functionality.
Eliminating the moving button leads to more robust, better and cleaner code when you do have to write something new. By not re-inventing the wheel in every case, identifying what can be flexible and what cannot and learning to give and take against what the product does vs what one can make it do, development can be easier and faster. Releases can go quicker. The introduction of regressions are reduced. The notion that ‘custom dev’ rules the day is removed – it is used, not as a first option nor as a last resort, but as a smart option.