AnthillPro Blog - Chaperoning Promiscuous Software

Re: Chaperoning Promiscuous Software

Anonymous — Tue, 09 Feb 2010 21:18:25 GMT

Very timely article. We're well on our to making this real without really getting in the way of development too. Wolfram sounds like a developer to me ;-)

Re: Chaperoning Promiscuous Software

Eric Minick — Mon, 08 Feb 2010 15:07:48 GMT

Thanks for the well thought out response! I agree that implementing this whole system can be heavy handed. It's very extreme for a mission a simple CRUD application. Teams I know who are writing shrink-box applications take any change to their tool-change or dependency graphs very seriously and test any new version of a component they are upgrading to extensively.

I would also argue that part of the goal is to facilitate developer productivity not hamper it in favor of control. By creating a set of approved components in a well know, easily accessible (and ideally searchable) place, developers don't need to hunt down various components online, and perform whatever validation they would do on them (usually none). This helps at component finding time, it also helps in a large enterprise as developers switch projects. When they move from one project to another, they find the same XML parsing libraries in place. The same logging technologies in place, etc, etc. Enterprise IT, in reality has quite a lot of friction caused by people moving between projects. If some level of consistency between those projects is facilitated, that friction can be reduced a little bit.

That said, I can see where the testing and the seperate approval organizations can be too much rigor in some teams. At very least, have a central place to store the components and track what you're using. It's truly frightening how many teams have no idea what components their using.

Re: Chaperoning Promiscuous Software

Wolfram Arnold — Sat, 06 Feb 2010 01:42:17 GMT

That seems like a heavy-process and heavy-handed approach to me. Also the reward structure is all backwards. IT managers and tools that need to "prevent" developers from doing things which are easy and get their job done fastest probably will never be able to tap their developers' full potential. The incentives are mis-aligned. To change behaviors, the organization, culture and practices must be arranged such that the desired behavior is also the easiest thing to do for developers.

And the idea that some in-house test team is supposed to verify 3rd party libraries strikes me an inversion of responsibility as well. This is like hiring a test driver to check that the car I just bought actually is safe to drive. For open source components, why not insist that all libraries have test suites, verify test coverage with your Anthill tool and reject those that don't pass their own suite or don't have coverage. For 3rd party proprietary libraries the same applies. The vendor should test it, ideally show this by demonstrating their own test suite. Or else you better check the fine print in the support contract.

Perhaps this sounds too utopian for the Enterprise Java world, but it is standard practice in the Ruby-on-Rails community.