Saturday, February 28, 2009

When Is Process Bad?

I've been trying to come up with some rules of thumb as to when putting processes in place probably isn't the correct way to go. I started out trying to pick the tasks that people do day in and day out, but that didn't quite work. For instance, you cannot simply say that a developer writing code should have no processes. That's just foolish. There are some processes that almost all developers should always follow, e.g. use source control, commit early and often, etc.

In that light, my last post was definitely reactionary. Most processes are probably good especially if they're invisible. And if they're invisible, I probably do not even think of them as processes in the first place. At a high level, writing unit tests is part of the process of writing good code. While not invisible, it's definitely a process I don't mind having.

I think processes tend to get under my skin the most when they are used as a management technique when trying to control the results of generally creative, non-repetitive tasks. Writing unit tests is a way of managing change. We always want to manage change the same way so that we know when something breaks before the customer does. But counting lines of code to determine how well the solution to a new problem was written doesn't work. It's hard to put a process in place for non-repetitive tasks because you don't necessarily know what the outcome should be.

The same goes for design. Yes there are certain steps that can be identified as generally good, that you always want to do. You want to make sure that your design solves the users problems. A minimal process for how you go about determining what the users' problems are is probably a good idea. Always observe the user in their natural environment, determine why they are using the software, etc. On larger teams, communicating the final design to many other people probably requires a specific document format so that information is easy to find for all the different teams that need it: QA, development, documentation, sales, etc.

But you can not really put a process around the actual creative design of the feature. Trying to do so usually results in some sort of sign off or management check in that doesn't accomplish what you think it will. It doesn't mean that the best design gets implemented. The manager can't know what is best simply because they don't have the time to do the research and work of their multiple subordinates. Sure they can make observations and recommendations, but the final decision should be the person doing the work. If anything, the only real result is that your subordinates start to feel untrusted.

To boil this all down, I believe that if a manager is trying to control the creative aspect of their subordinates work through processes, they are only getting in the way and sending a negative message to their workers.

Maybe all I've said here is that I dislike micromanagement, that's probably a fair paraphrasing. Regardless, what is the alternative? I said in my last post that there does need to be some sort of accountability and control, where does that come from? If there's one thing I've learned about writing it's to stick to a single topic per post, so you'll just have to wait for my next entry for ramblings on that subject.

Tuesday, February 17, 2009

The Proccess Isn't That Important

I'm not all that keen on process lately. Sure it takes some process to get software written. Process is how we get jobs done. But in the end, within certain limits and circumstances allowing of course, how goals are achieved is no where near as important as achieving the goal.

I have seen teams brought to a standstill because the process indicated that the entire ten member brainstorming group had to come to a consensus on a design before the feature could be started. I have seen stakeholders start witch hunts because an otherwise smooth implementation was not following their imagined process of how software gets written. I've seen teams of otherwise friendly and rational groups of people torn apart because the processes in place did not give individuals the responsibility over how to do their work and put them at odds with each other.

Process should be minimized to the greatest possible extent. Use just enough to keep yourself organized while slowing yourself down as little as possible. There is a slew of policies out there that people believe make their organizations run more effectively which are really only getting in the way. And once again I will admit that some policies can be advantageous and necessary. But even the necessary ones are probably getting in the way somewhat of the real goal of getting the next great iPhone application to market.

Why do people overuse processes? Part of the reason is that workers need to be held accountable for their work. If a manager doesn't know who is responsible for a piece of work, how will they know who needs help when the operation isn't running smoothly? How do you decide if new hires are needed when bottlenecks occur? How do you divide all the work that needs to be done in a way that scales? I can't really argue with any of those motivations.

The part that I do take issue with though is that processes are overused when they are not the best tool for the job. This is probably because small processes are just so easy to create. "Don't forget to CC HR when requesting time off." Simple, easy, not very time consuming considering you were probably already writing the email anyway. But it's a slippery slope and many people don't notice when they start to slide or might not be aware of other options. Also, once a mountain of process is in place, it can be difficult to roll it all back. It's easier just to append another small rule to the process.

I can hear the wags saying, "Chuck, none of that information is really new."

To which I respond, "See the blog subtitle."

"But this post is not particularly useful either. Of more benefit would be recognizing when a process isn't necessarily the right policy and what to put in place instead."

You know what? The wags probably got that one right. And so it will be a good topic for my next post.

Sunday, February 15, 2009

Focus First Form Field with JQuery

It tok me a while to find this little gem and polish it up a bit so I figured I would pass it on. The title of the post should be enough of a desciption of what I was trying to do so here is the code.
function FocusFirstField() {
var topIndex = null;

var fields = $("input:visible:enabled:first,
select:visible:enabled:first,
textarea:visible:enabled:first"); 

if (fields.size() > 0)
topIndex = 0; 

for (var i = 1; i < fields.size(); i++)
if (fields[i].offsetTop < fields[topIndex].offsetTop)
topIndex = i;

if (topIndex != null)
fields.get(topIndex).focus();
}


The first line just defines a variable to hold the index of the control we finally identify as the top most field in the form.

The second line uses JQuery to select the first, visible, enabled of each input, select and textarea html elements.

The third section primes the following loop. It checks to see that at least one element has been returned and sets the topIndex value to 0.

The fourth section of code loops through any other elements that have been returned and compares the offsetTop value of each to determine the top most element.

The last line of the function checks to see if any element of the selector types has been found and sets the focus to the element found to be the top most.

The function is best called from the window load event as the JQuery document ready event fires too early on some browsers:
$(window).load(FocusFirstField);


And the selector can obviously be tailored to fit your needs.

-- EDIT:

One of the things that I just noticed about this is that I tried to make the code smart enough to take just about any CSS into consideration, hence the loop checking top offsets.  What I just noticed is that the ':first' selectors might work against this at times.  I included those selectors to limit the number of DOM elements returned, but it may cause things to not work all the time.

I think in most situations the code should be fine, but if your CSS really moves elements around ala CSS Zen Garden, you might need to remove the :first portion of each phrase in the selector.