A Case for IT Scaffolding (Building Tools)

This post is an unadorned rant. The topic is the lack of software scaffolding I see in my consulting practice.

By "software scaffolding" I mean tools specific to a particular task or project.

 I see managers who are unable to appreciate the utility of such tools and who discourage their creation and use because building tools takes time and energy.

I see programmers reluctant to make debugging and validation easier with a tool because the tool is not on the project plan.

You can't really build a building of any size or complexity without a scaffold and a large part of getting construction done well, done on time and done at or below budget is having the support system in the plan and on the ground. I assert that the same is true of many IT projects.

Furthermore, I assert that this is true of Lab IT projects in particular where validation and on-going audit are so important. I find that many of my  bits of scaffolding live on to support making sure that the software keeps working, after I have confirmed that it worked in the first place.

I understand that some programmers go overboard: instead of creating good-enough tools, they create overly complicated and overly polished Swiss Army knives, which somtimes even get released because the super-tool ends up being the only way to do something.

But keeping this in check should be doable for a competent manager. Why then do I see so much resistance to building data examination tools, dumping reporting, debuggers?