Can we burn the boats AFTER we have disembarked?

In 1519 AD, during the conquest of Mexico, the Spanish commander Hernán Cortés ordered the destruction of the ships that had brought him and his troops to the shores of Mexico.

He did this to give a clear sign to his troops - they would have to conquer this new land, or die.

There would be no way for them to retreat. No way to return to their homes.

They had to succeed.

Fast forward to the modern world; I see the same approach being used in business.

This "no going back" is being used as a motivator for teams.

As an example, one of my clients was embarking on a "big-bang" migration between critical systems.

A "big-bang" migration is rarely a good idea - but I'll come back to that in the future.

To provided added "focus", the client made it clear that there would be "no going back" to the original system. The new system had to succeed at all costs.

To underline this point, they greatly ramp down the teams that support and manage the original system.

Personally I find this an incredibly risky approach.

At that point the new system was not ready. It hadn't been completed - yet alone proven to be an effective replacement.

To me this is the equivalent of Cortés setting fire to his boats before even sighting the Mexico coastline.

He could only hope that his ships make it before they sink. And assuming he does make it to land, he then has no options if he finds it to be less than hospitable.

So for my client to reduce the necessary investment in the originals systems was an incredibly risk approach.

Those original systems underpinned their business. If they failed, they would find that they are unable to make it, as a business, to the golden beaches of the promised land.

So, while I have a certain sympathy with the "focusing" effect of burning the boats, I would certainly caution against doing it too early.

Keep your options open.

Attitude towards custom software development survey

During September, I'm running a short survey to establish UK Executive's attitude towards custom software development survey.

Does it return ROI? Does keep pace with business? Is it difficult to recruit or retain staff? Does it have sufficient quality? Is it predicable?

I'd welcome any participation or sharing of the survey.

Please have your say at here

#55: The Programmers Oath: I will make frequent, small, releases so that I do not impede the progress of others.

In this episode I continue to look at professionalism in software development.

I take the fourth oath from the Programmer's Oath by Uncle Bob Martin, introduced in episode #51, to explore further:

"I Promise that, to the best of my ability and judgement: I will make frequent, small, releases so that I do not impede the progress of others."

Listen here

About the author:

Mark Taylor is an experience IT Consultant passionate about helping his clients get better ROI from their Software Development.

He has over 20 years Software Development experience - over 15 of those leading teams. He has experience in a wide variety of technologies and holds certification in Microsoft Development and Scrum.

He operates through Red Folder Consultancy Ltd.