Eliminating the Moving Button

Slalom Consultant Derek Martin

Slalom Consultant Derek Martin is an accomplished Microsoft systems developer and integrator, experienced in developing and deploying SharePoint and CRM solutions, integrating line of business applications, and leveraging existing infrastructure investments.

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.

Custom code should be introduced into a product where the functionality simply doesn’t exist or the existing functionality is significantly removed from the needed functionality.  The developers should be working in concert with the BAs and the PMs, not merely handed a set of fixed requirements.  Being agile doesn’t mean sacrificing desired end results.  It means that there is a constant communication of the flexibility and needs of the platform so that rapid development can be achieved without massive structural changes to the underlying product.  When those changes are required, they should be designed to be like lasers – targeting precise areas.  They should not be introduced to completely replace large chunks of native functionality.  If they are being introduced like that, an evaluation of whether the original product is the right product for the job should be conducted.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 130 other followers

%d bloggers like this: