[Because] change in organizations typically involves shifts in the way people work, these may introduce feelings of inadequacy and dislocation that potentially challenge people’s identities as competent workers (Ezzamel, Willmott & Frank, 2001; Kondo, 1990). Organizational changes may also reduce or replace meanings and practices that are central to people’s positive view of themselves, such as when they are no longer allowed to engage in activities or use artifacts that had signaled their prestige or prowess to others (Pettigrew, 1985). Furthermore, employees may consider new tasks and new approaches as affording them with less autonomy, responsibility, or standing in the organization than their previous ways of working (Cox, 1997), and they may interpret this as an overall loss of status and thus as a threat to their professional identify. da Cunha, J. V., & Orlikowski, W. J. (2008). Performing catharsis: The use of online discussion forums in organizational change. Information and Organization, 18(2), 132-156. Page 133.

A book every programmer should read

The Pragmatic Programmer: From Journeyman to Master. Every programmer I hired was required to read this book. It’s a great resource for people managing programmers too. The book is entirely language agnostic, and focuses on how programmers do (or should) think and work. Most programming books do an adequate job of covering syntax, but few actually address the process of programming. My collegiate programming classes typically expected me to already know the syntax and focused more on the theory of the system, but they too offered little advice on how to actually program. This book, more than any other I’ve found, fills those gaps.

This book was so unlike most technical books, the authors went on to start their own publishing house for programming books. (I was fortunate to be a technical reviewer for one of them.) All of their books that I’ve tried thus far have been of high quality.

Another excellent (but less essential) read for programmers is Head First Design Patterns. The book’s example are in Java, but are easily adapted to other languages.

A book every technical manager should read

Peopleware: Productive Projects and Teams, by Tom DeMarco and Timothy Lister. It covers everything from productivity to working conditions and incentives, and explains why programmers are different from “regular” folk. The advice here can be easily applied to all technical and knowledge workers. Highly recommended. Slack, also by DeMarco (which I think is a more recent rendering of some of the same concepts) is on my “to read” list—when I finally get around to finishing it, I’ll comment on it as well.

Two books every manager should read

Influencer, by Kerry Patterson. This book changed the way I think about organizational issues. It begins with the incredible premise that social problems can be addressed by leveraging a single behavior, then delivers example after monumental example demonstrating—with step-by step instructions—how true it can be. From eliminating a parasite in remote Africa, to quelling an AIDS epidemic, to more local and mundane organizational or personal problems, Influencer details in easy language why so many transformation efforts fail, and what to do about it.

Good to Great, by Jim Collins. Despite criticisms I’ve heard from a couple of academic researchers calling it “junk science,” this book is used in many highly ranked MBA programs, and made rounds at several organizations I’ve worked with, including Utah state government. Collins examines the differences between companies that were extraordinarily successful year after year (as measured by stock price) and those that hovered near the industry average. It is an interesting look at many factors that shape the success of organizations.

More worthwhile books

Blink, by Malcolm Galdwell. The book is an easy to read and incredibly fascinating exploration of how we think and, despite our best intentions, are affected by biases. I’m surprised at how often anecdotes and insight from this book were relevant during my MBA courses. If you like Blink and want a more academic and in-depth treatment, I’ve found Judgement in Managerial Decision Making to be similarly facinating.

Once an Eagle, by Anton Myrer. A fictional account of two soldiers spanning most the greatest wars of the 20th century. Through the characters, the author explores the ethics of leadership. I’ve heard it rumored (but don’t know for certain) that this book is required reading at some of the U.S. military academies. An excellent—although lengthy—read.

Others I’ve found worthwhile include:

• Judgement in Managerial Decision Making, by Max Bazerman and Don Moore
• The Goal: A Process of Ongoing Improvement, by Eliyahu Goldratt and Jeff Cox
• The Five Dysfunctions of a Team, by Patrick Lencioni
• Leadership and Self-Deception, by The Arbinger Institute

Is there something else that should be on the list?

For those wedded to the idea of performance pay and “differentiated compensation” (and not just in public education) may I offer the following nugget from, of all things, an accounting textbook:

Incentive compensation for employees, such as bonuses, can, and probably should, be tied to balanced scorecard performance measures. However, this should be done only after the organization has been successfully managed with the scorecard for some time—perhaps a year or more. Managers must be confident that the performance measures are reliable, sensible, and understood by those who are being evaluated, and not easily manipulated. As Robert Kaplan and David Norton, the originators of the balanced scorecard concept point out, ‘compensation is such a powerful lever that you have to be pretty confident that you have the right measures and have good data for the measures before making the link.’Garrison, R.H., Noreen, E.W., Brewer, P.C. (2008) Managerial Accounting, 12th ed. McGraw-Hill. p 446.
Internal quote references Lori Calabrom “On Balance: A CFO Interview,” CFO Feb 2001, pp 73-78.

Introducing Subversion (SVN) Hooks

Subversion allows for custom scripts to be called when it performs certain actions on a repository. Browse to your repository. The server-side one, not your working copy. In /path/to/svn/repository_name/hooks you will see a list of sample scripts for the five actions subversion recognizes.

start-commit

Run before the commit transaction is created. May be used to stop the transaction and return error messages to clients.

pre-commit

Run when the transaction is complete, but before it is committed. It can be used to require comments to include a bug tracker ticket number, or enforce fine-grained access to parts of the repository. It can cause the transaction to rollback and return error messages to clients.

post-commit

Run after the transaction is committed, and a new revision is created. Often used to send notification emails or trigger repository backups. Errors from this hook are ignored Subversion comes with some scripts for common actions. Read the manual for more details.

pre-revprop-change

Revision properties such as log messages aren’t versioned. If you were to go back and change a log message, for example, the old one would be lost. This hook, and its post- counterpart, offer a chance to reject or log the change.

post-revprop-change

Run after revision properties are changed. There are some security restrictions built in, be sure to read the manual.

Well, that sounds simple. All we have to do is write a script that will log into our bug tracking system and insert a comment on the appropriate ticket. That sounds easy enough, but let’s not make things too complicated. With a few minor customizations, Mantis will do most of the work for us.

Customizing Mantis

The manual for Mantis has two relevant pages. One, titled “Source Control Integration”, provides a list of customizable settings, but offers no directions on where these settings are most appropriately accessed. The other, “CVS integration”, is not terribly helpful either, but it does provide another piece of our puzzle—it tells us there is a command line PHP script included with Mantis that accepts a version control (e.g. SVN, CVS) log message via stdin, and adds comments to any tickets as appropriate.

First things first. Create a new user in Mantis. This is the account the script will use. I called mine “svn”. Make sure the user has permission to add comments and resolve tickets. Don’t forget to add it to your project(s).

Open up /path/to/mantis/config_inc.php. If it doesn’t exist, create it. (If it doesn’t exist, you didn’t follow the installation directions.) This file is used to override default settings. It’s not distributed as part of Mantis, so when you upgrade, it won’t be overwritten. This is where you should have your database connection information, and where you would override the default colors, status/severity options, or any number of configurable settings.

Add the following lines to /path/to/mantis/config_inc.php:

$g_source_control_account = 'svn';
$g_source_control_regexp = '/\b(?:bug|issue)\s*[#]{0,1}(\d+)\b/i';

What does it all mean? (Some credit is due Digitalpeer for helping me through this. I found it just as I was getting the integration working. It would have saved some time.)

$g_source_control_account

This is the user we created in Mantis.

$g_source_control_regexp

This is the regular expression Mantis will match against the log message. This is an optional setting; the default is /\bissue [#]{0,1}(\d+)\b/i.

Using a custom RegExp

You’ll notice I defined a regular expression different from the default. I wanted to not only match the string “issue #1337″, but to be a bit more liberal, matching the phrase “bug #1337″ too. For those of you savy enough to craft your own expressions, the first capturable group must be the bug number, or the script won’t work. (This is hard-coded into Mantis.) Hence the non-capturing group (?:bug|issue).

Automatically closing tickets

These custom settings lay the groundwork for Mantis to automatically add comments to tickets based on SVN log messages. There are additional settings we can use to get Mantis to resolve tickets automatically too, based on a different regular expression. To enable this behavior, add the following lines to /path/to/mantis/config_inc.php:

$g_source_control_set_status_to = RESOLVED;
$g_source_control_set_resolution_to = FIXED;
$g_source_control_fixed_regexp = '/\bfix(?:ed|es)\s+(?:bug|issue)?\s*[#]{0,1}(\d+)\b/i';

$g_source_control_set_status_to

The status to set the ticket to. Use CLOSED if you prefer.

$g_source_control_set_resolution_to

The resolution attached to the ticket. There are constants defined for each built-in resolution. You may use a different one, but FIXED makes the most sense.

$g_source_control_fixed_regexp

This is an undocumented setting. The default is to be equal to $g_source_control_regexp, but I only wanted certain tickets to be automatically closed, so I used a different regular expression. My expression matches “fixes issue #1337″, “fix bug #1337″, or simply “fixed #1337″. (Plus several iterations on those words.) The ticket number must be the first captured group. Altering the expression to also accept the words “solved” and “solves” is left as an exercise for the reader.

Testing Mantis

Before we go further, let’s make sure we implemented the Mantis settings properly. Run the following from the command line (alter the paths, of course)
%> /path/to/php /path/to/mantis/core/checkin.php <<< "My web monkey fixed issue #1337 by accident."

If you’ve configured Mantis correctly, there should be a new comment on ticket #1337.

Connecting the pieces

Now that we have Mantis set to accept log messages from our version control system, we need to connect Subversion to it. Remember the hooks from the beginning of this article? We’re going to write one. I used Bash script. (Be nice, I’m still learning Bash.)

Save the following file to /path/to/svn/hooks/post-commit (no file extension):

#!/bin/bash
 
REPOS="$1"
REV="$2"
 
log=$(svnlook log -r $REV $REPOS)
 
/usr/bin/php -q /var/bugtracker/core/checkin.php <<< "$log"

What is svnlook?

The program svnlook is distributed as part of Subversion. Given a revision and repository path as parameters, it will return various properties of the revision, such as the author or which files were changed. In this case we’re asking only for the log message.

Permissions

Give the file permission to executable by your repository. This will be slightly different for each setup, but something similar to the following should do the trick:

%> cd /path/to/svn/hooks
%> chmod 770 post-commit
%> chgrp svn post-commit

More on post-commit

The post-commit hook takes two parameters: the repository path and the revision number. If you needed to run post-commit manually (testing your script!), it would look something like this for revision 746:

%> /path/to/svn/hooks/post-commit /path/to/svn/repository_name 746

SVN and Mantis in perfect harmony

There you have it. That’s how you integrate Subversion with Mantis. If you have questions, feel free to leave a comment.

• As customers, we search for someone to blame, but only because we want a problem fixed. The person who caused the problem may not be the one to fix it. When working with customers, take ownership; connect the customer to the solution.
• Uncorrected little mistakes can become big mistakes. Responsibility lies with those who made the little mistakes at the beginning.
• Don’t try to hide mistakes. Take responsibility—)but more than that, take ownership of finding a solution.
• Capitulating early won’t provide the emotional win, but in real terms it may be cheaper than arguing. Even if we don’t consider intangibles like a positive brand image, word-of-mouth, repeat customers, or opportunity costs, our time and our employees’ time is valuable. Understand the cost of covering mistakes.
• Empathize, don’t patronize. We do this by taking ownership, sharing information and providing options.

You can see the recurring theme: take ownership.

I had problem with a major telecom when I last moved. (The other major telecom had caused me some significant trouble, so I switched.) I still had no service one week after it was to have been hooked up. It took eight hours on the phone (much of it on hold) over the course of more than fourteen calls to about five different customer service lines (all with horrible phone trees) before was I finally connected to a manager that promised he would personally make sure it was fixed. I was pessimistic, but willing to trust him. I wanted to trust him. He couldn’t, of course, fix it over the phone, but he did promise to call me back. (Which he did after it was fixed that evening.)

The simple act of someone taking ownership was enough to ease my frustration. I finally felt as if someone cared (empathy), he promised to call me back (information), and he followed through (trust). Why did it take so long to find someone willing to do that?

If you ever have to deal with customers, or manage people who do, head on over and read the whole thing.

Before you ask, yes, I know he’s using a knock-off of my design. Imitation is the sincerest form of flattery. And, he asked politely.

Embracing generality

I argued against laws attempting to cover every eventuality through specific language. The alternative is a system of law based on principles, rather than specific situations. In my mind, the best example of a set of principles in U.S. law is the Bill of Rights. Had the founders chosen to define “speech” in a more specific manner, it might not now include radio, television, or the internet.

Solving an individual’s problems

An example might prove better than an explanation: In 2004, one of our state legislators pushed a movement to split one of the state’s larger school districts. Existing law requires a petition, a public study, and eventually, a majority vote from each of the affected areas. After the study was released, many citizens realized the disparity in property taxes in the two area was too significant to justify the new district, and most lost interest in the idea. (Taxes in the established area would fall slightly, but taxes in the proposed “new” district—a fast growing area—would likely double.) Despite a very clear public opinion in opposition to the new school district, the same representative has since sponsored legislation to alter regulations regarding the creation of new school districts. The bill was defeated in 2005; the same legislator is running a similar bill again this year.

I’m concerned when legislators consider bills criminalizing legal behavior they (or lobbyists) don’t like. A 2004 bill crafted by telecoms and written for the primary purpose of defeating UTOPIA, a municipal broadband project, is a recent example. This year, our legislature is considering a senator’s quest to minimize the teaching of evolution in public schools, against the recommendation of scientists from every major university in the state. (I have yet to hear a single high school science teacher or college professor, including those from private religious universities, speak in favor of the bill, although I’ve heard many speak against it.) The senator has created a problem where none existed, and is diverting public discussion from more important topics.

Locality

Laws should be implemented at the lowest reasonable level. Federal laws against counterfeiting U.S. currency are reasonable. A federal law mandating all public school students achieve a 100% pass rate on standardized tests is not. A minimum state curriculum, which can be expanded and customized by local districts is a common, reasonable approach. A proposed state law requiring elementary school principles to hold back third-graders unable to meet reading requirements oversteps the concept of locality, although successful programs similar to the one proposed exist at the district and even school level.

Last year in an informal meeting with the state legislature Republican leadership, one of the members present recognized that many legislators were criticizing the federal government for infringing on state issues (especially regarding NCLB), while acting in a similar manner by imposing requirements on local school districts. He suggested in a general manner that some legislative restraint might be in order. I appreciated the observation.

Trust

Overcoming the pressure to legislate from too high of a level comes down to trust. If the State Board of Education is asked to take action better left to local districts, it is appropriate to exercise trust in those at the local level. They too are elected, and can often be more responsive to their communities. (Trust in local decision makers was a significant factor in the State Board of Education’s decision to allow Rich School District to pursue the option of a four-day school week.)

The U.S. Department of Education rigidly applied the mandates of NCLB due to an institutional lack of trust in states. This has changed somewhat in recent months as the new U.S. Secretary of Education, Margaret Spellings, has been granting states more flexibility in choosing their approach to NCLB. In the same way, I hope our legislature will have faith that elected officials, more local to the problem than they, are working toward common goals, and that however well-intentioned some legislation may be, situations can and should be addressed at a more local level.

Final thoughts

These observations apply to any type of organization, not just our government. Implementing successful laws can be a difficult task, but I find that whenever I have a concern about about a rule I’m considering, or legislation I’m asked to take a position on, that concern can often be reduced to specificity or locality.

As the legislative session opens, I wanted share some observations on law, discuss what makes good law, and explore ways to identify poor laws. In many cases, I believe “poor law” is often based on commonly held principles, but however well-intentioned is held back in its success by poor scripting, poor planning, or poor implementation. In this article I list items I consider to be some indicators of poor law; no single item purports to be a definitive identification, these are merely lenses I use in evaluating legislation. (I believe these same principles hold true for evaluating the rules of any organization or business, not just our laws.

In summary these indicators are 1) being overly specific, 2) being individualized, 3) the absence of consequences and 3) the violation of locality.

Specificity begets specificity

The more specific a law is, the more specific it needs to be. Once a lawmaker attempts to predict alternatives and possibilities, the need to expand the law to include all eventualities is inevitable. As more specifics are generated, the possibility of loopholes increases, resulting in further legislation. Additionally, an over-specific law replaces reasonable judgment at the “front lines,” or most local level, robbing affected parties of flexibility.

A hypothetical situation

Let us assume a state wishes to define a process for soliciting contractors for public works projects. All involved agree the process should be fair and equitable. The law is written to require a committee to review bids. In order to be impartial and avoid the appearance of political rewards or cronyism, the committee must be removed from the department actually requiring the service. Proposals must be made public for some period before being considered. Such a system would seem to be fair.

Well intentioned lawmakers may then further “refine” the process by appending provisions giving preference to local businesses or companies owned by minorities. An appeals process might be instituted to ensure any party can challenge the fairness of a decision–in order to by worthwhile, such a provision would require the bid process be halted, or reversed and reconsidered. At risk of offending some party, a process to challenge the project’s necessity (by reason of the environment, racial equity, cost concerns, etc.) might also be instituted. As the department requesting service and the fulfillment contractor are separated, a series of regular status reports might be required to ensure the contract is being filled appropriately. The list of possible refinements in the interest of fairness is extensive.

This “hypothetical” is a too common practice around the country. Examined in part, each additional requirement seems reasonable; as a whole, it is a cumbersome processes costing additional resources at every step. Process similar to this “hypothetical” are the reason many contractors bid for government projects at a significantly higher rate than they would for non-government customers.

Micromanagement In Action

A relatively new California law (Government Code 12950.1, which has spawned a host of training and consulting companies) requires companies of more than 50 employees to have sexual harassment training programs in place for all supervisors. The law replaced a much simpler one which simply stipulated employers were expected to take “reasonable steps.” The new version imposes requirements regarding the type and frequency of training, questions the experience of instructors, defines course content, and prescribes the method of instruction to a level that would embarrass even the most devoted micro-managers. Yet, the law provides no insulation from liability if complied with. It’s specificity is a burden to businesses, and provides no additional benefit (to citizens or business) over the law it replaced.

Hate crimes

The listing of specific protected classes causes me to question many so-called hate crimes legislation—or any other anti-discrimination law. (Some may argue that Utah does not have hate crimes laws; this is half-truth. See Utah Code 76-3-203.3.) The trap of specifying groups introduces the possibility of excluding some group. Such a list might include ethnicity, culture (not the same thing!), religion (does this include atheists?), sexual preference, income level, family or marital status, employment (or lack thereof), disability or handicap, education level … the list goes on. Our current law, which has been on the books in some form for more than a decade, upgrades misdemeanors intended to “intimidate or terrorize” to felonies. It’s simple and adequate, focusing on principles rather than contingencies.

Will be continued…

The discussion was timely, as I had spent several hours the previous evening reading articles on interviewing strategy, starting with Joel Spolsky, and following links to a slew of sites including techinterview.org, and Malcolm Gladwell’s site (author of Blink and The Tipping Point). The one point from my browsing that stays with me several weeks later is the thought from Gladwell, quoting Frank Bernieri, a psychologist at the University of Toledo:

“[Tricia Prickett, an undergraduate researcher,] took fifteen seconds of videotape showing the applicant as he or she knocks on the door, comes in, shakes the hand of the interviewer, sits down, and the interviewer welcomes the person,” Bernieri explained. … Prickett got a series of strangers to rate the applicants based on the handshake clip, using the same criteria that the interviewers had used. … “On nine out of the eleven traits the applicants were being judged on, the observers significantly predicted the outcome of the interview.”

Malcolm Gladwell, “The New-Boy Network “
Referenced Tue, 13 Dec 2005 23:47 (MDT)

Gladwell emphasizes the point from his own experience. He was meeting with a Harvard student, and asked several questions. He relates the following regarding one of the answers:

Because I had decided, right off, that I liked him, what I heard in his answer was toughness and confidence. Had I decided early on that I didn’t like [him], I would have heard in that reply arrogance and bluster. The first impression becomes a self-fulfilling prophecy: we hear what we expect to hear.

Malcolm Gladwell, “The New-Boy Network “
Referenced Tue, 13 Dec 2005 23:47 (MDT)

I’ve seen this as I’ve sat on both sides of the interview table. While working at a private university, I was asked to hire and train 21 employees in just over a month. It was just prior to the start of the semester, so we had numerous candidates to choose from. I can still recall several candidates who made an impression one way or the other within the first few minutes—and their technical responses made little difference in the final outcome.

Asking Technical Questions

While at the CTO Breakfast, another participant expressed some frustration in finding developers locally. He was asking technical questions to his interviewees, and was disappointed none had thus far answered at a level he preferred. Others present suggested the question might be too specific, and that more general questions might be more worthwhile. If we ignore for the moment the suggestion that interviews may be decided in the first twenty seconds, what questions are appropriate?

When applying for a data reporting position at a major internet retailer, the interviewer tapped the director of software development to ask me technical questions to verify my knowledge of SQL, which were mostly related the effect of null values on data sets. I didn’t feel like I did terribly well, despite several years experience in the field, but he gave me high marks. (We’ve both since left the company, but are still friends, which takes me back to the the thought that the first impression may prove stronger than the quality of answers.)

What kinds of questions prove valuable? Those present at the breakfast suggested several:

• What blogs do you follow, or what web sites do you read regularly?
• What did you Google before this interview?
• Have you contributed to an open source project?
• What programming projects have you completed primarily for personal use (e.g. just for the challenge or fun of it)?

After being hired by the internet retailer, I got to talking with the development manager about the questions he asks developers. He likes to ask candidates to perform some simple string manipulation without using any of the standard C libraries; it serves as a stepping stone to software architecture questions, asking candidates to justify their solution from different perspectives, such as process speed or memory conservation. When interviewing at other companies I’ve been asked about the benefits and hazards of multiple inheritance in object-oriented languages, or what kind of quality controls are appropriate for evaluating data sets. Only once have I been asked a puzzle question (”How many barbers are there in the U.S.?”), which I found to be not only completely out of left field, but also rather useless as an evaluation of my problem-solving ability.

A Realistic Environment

Another question from the CTO Breakfast was whether we (unintentionally) make the interview environment limiting or artificial. If we ask programming questions, do we provide access to Google, or online manuals? I spend much of my time programming in PHP—and I wouldn’t be nearly as effective without the ability to regularly reference the online documentation to verify function names, return values, and attribute order.

The very nature of most interviews (chairs on opposing sides or a desk) also lend to a somewhat restrictive setting. I’m more comfortable when I can pace in front of a whiteboard with a marker in my hand, erasing my first several ideas as a solid solution is built piece by piece. An interview is rarely as forgiving as a whiteboard.

I haven’t had a chance to put into practice the ideas I gleaned from the discussion. (The most recent applicant never showed.) I’m sure I’ll get the chance soon—I still need to hire several web programmers!