Controlled Flight into Terrain or CFIT is a type of accident where an aircraft with no apparent mechanical problems is flown into some obstacle like a mountain. Couple of days ago I used this acronym to explain some situations that happen during software development, but first let's understand better CFITs.
These can be caused by a large amount of reasons; poor visibility, confusion in the cockpit, wrong navigation maps, poor capability to operate the aircraft and so on. Usually what happens is that given these factors the aircraft is put in collision course and when alarms go off there's little time for the crew to react or the crew is so confused that doesn't understand what is happening and take the wrong measures. Running the risk of adding one more acronym to the large set we have in IT I propose the usage of CFIT for some situations.
In Software Development sometimes we have situations similar to these, when information is so bad that we end up coding the wrong solution and this is a factor for a CFIT. We might also have poor visibility and make the wrong calls i.e. poor performance, because the real load was never shared with the development team. Infrequently but still of note is poor directions given by someone responsible for the solution, like a senior developer or an architect, that instead of sharing the inputs (business problems) only share the outputs (decisions made) leading the team steer the software into a collision course. And by collision course I mean once gets release it fails in some way.
We can deal with such situations adopting some practices, like fast and better feedback and good visibility. A GPWS (Ground Proximity Warning System) for software development is nothing more than good monitoring, if metrics go off chart we can correct the course before is too late. And a good CRM (Crew Resource Management) is good and honest feedback, of the product, of the code and where the team is headed, poor CRM is a Command Control environment which is a great way to provoke a CFIT. I believe we could draw some more parallels but in fact what I'm looking for is lessons learned and how we can adopt them to Software Development.