title: This is why we have teams link: https://onemoretech.wordpress.com/2009/02/03/this-is-why-we-have-teams/ author: lembobro description: post_id: 386 created: 2009/02/03 17:50:28 created_gmt: 2009/02/03 17:50:28 comment_status: open post_name: this-is-why-we-have-teams status: publish post_type: post

This is why we have teams

Just had another reminder of why we have, or at least used to have, teams to do various things in Information Technology. A good friend and colleague was stumped by a problem with their code and asked me to take a look. Of course his code is way more sophisticated than my pathetic attempts at programming, so I had a hard time following it (he’s one of those guys who can do in a single line what it takes me a block of 5 to accomplish).

It was your basic add uniquemembers to an LDAP group kind of problem. With a twist. To keep his app within licensing limits my co-worker had come up with this clever audit routine that checked on actual usage patterns so that he could remove those who didn’t need access to a particular thing any more. On the LDAP side the program would do an unqualified LDAP delete on the uniquemember attribute in each access group and then repopulate with an LDAP add that had all the members who the audit routine determined still needed the access provided by a group.

The problem was he kept getting an LDAP error 20, “Attribute or Value Already Exists”.

After checking the obvious (LDAP access controls, app user dn and password) with LDAP browser, we started talking. Looking over the code I noticed that he had some “static” group members hardcoded into the script: guys who would always be included in a group even if they didn’t make use of the privileges it conferred often enough to avoid being purged.

“Let me check to see if there are any duplicates in that list,” I said.

Lightbulb over the head moment.

Of course. If this static list were added to whatever was discovered by the audit routine you could easily wind up with a duplicate. If that happened the LDAP server would fail the add operation with an Error 20, because at least one of the dns being submitted for uniquemember was already in a slot before it on the list (uniquemember is a multivalued attribute, its values stored as an array, or unordered list). Once we figured this out it was easy to fix by making sure the list submitted contained only unique values.

Moral of the story? Sometimes it takes a team to get things done. A lone wolf programmer could easily spend hours, days, on a problem that a relatively quick discussion with a colleague could resolve. Two (or more) heads are always better than one. Although this may cause some consternation for the bean counters in corporate finance, in today’s incredibly complex world of information technology no man, or programmer, is an island. We simply can’t do it alone.

This is why we have teams.

Copyright 2004-2019 Phil Lembo