agent of change

While taking computer science classes in college, I was taught to distrust a user’s input in all cases. The theory goes that a user’s data can’t be trusted because it could be malicious or just a simple mistake that causes your program to have an error with input it didn’t expect. So you protect your system from incorrect user input and sanitize it. It always felt like one of our dirtier secrets to me, however I fully advocate the practice in code.

My problem comes when the people building software turn from distrusting their user’s input to having a level of disdain for the users themselves. It starts innocently enough with the engineering principles I described above, but can sometimes turn into small things like, “Our users won’t understand that,” and starts to slip into things like, “Our users are dumb, so we won’t do that.” If you’ve started to hate your users, you’ve gone too far. If something is too complex for your users to understand, it’s your job as the developer/engineer/analyst/etc. to make it so that they can understand it. If you think of your users like idiots, your system will reflect that and they will notice.

If your job is to design software for people to use (which, is pretty much all software), make sure you work with the user, instead of against their best interests.

I like to think of requirements as being perishable. They have a certain shelf life before they are developed and then they start to smell funny and eventually go bad as they get out of date. Different sorts of requirements have different shelf-lives.

Master Level Story

The high level stories written at the beginning of a project and turned into a master story list can either have a long shelf life or a short one. If the requirements are not beginning to be broken down and worked on within a week or two, they get stale. Longer than a few weeks, into a few months or more, they should probably be thrown out and at the very least reevaluated. Why? Because your business may have changed in that time. It may not make sense to build those features that made sense a month or two ago.

Release Level Story

Release level stories are good for planning and immediately getting started on detailed analysis and development. They have a short shelf life based on their master level story freshness, plus any ongoing work in an application. For instance, if some implementation was decided on in a release level story and some technology change has made a card obsolete because it is building the wrong thing or makes the wrong assumptions, it’s useless.

Iteration Level Story

An iteration level story only has a shelf life of a few days after it’s been analyzed and not developed. More than a week or so and things can change so drastically in a project that they are not accurate anymore.

Shelf-Life After Development

After development, stories have a much longer shelf life. They can be referenced through various parts in the development lifecycle with the exception of stories that have been overwritten by new ones and those should be tracked as they occur.

Domain documents like systems architecture design, major domain concepts in your app, etc. are useful even longer.

Considerations

Keep in mind that all of these levels of stories interact. Master > Release > Iteration. They flow in that order and if the master level stories are old and no longer good, they need to be reevaluated. Otherwise, spending time to break them down will be a waste of time and even worse, implementing them can cost real money in the marketplace.

Constant prioritizing and re-evaluation will keep stories fresh for use by the development team. Don’t expect to be able to pull bad apples from storage and make some great apple pie.

Have you ever been editing a card in Mingle and you lose your data because the session timed out? Well, if you are comfortable editing a config file in <mingle directory>/config/web.xml you can make the session timeout much longer. Here is what it looks like by default:

  60

You can change it to be something like this:

  6000

That works out to be around 4 days for the timeout, so all you need to do now is restart Mingle on the server and you shouldn’t be bothered by it any more.

I’ve been using Mingle a lot lately, so I’ll be posting some quick tips that I’ve found useful in my projects.

Did you know that you can add a set of quick links in the header of your project?

Mingle’s help pages show how it’s done, but oddly, the help page seems to be hard to navigate to unless you know what you are looking for. It’s under Content > Customizing Projects > Project Environment and Navigation > Setting Up Quick Header Links.

First, you’ll need to create a wiki page called Special:HeaderActions. That’s where you’ll store all of your links. Once you do that, you can enter in links like this:

<a href=”/projects/{{project}}/wiki/Project_Metrics” accesskey=”m”>Project Metrics</a>|

<a href=”/projects/{{project}}/cards/new?properties[status]=new&properties[type]=defect” accesskey=”b”>+Defect</a>

<a href=”/projects/{{project}}/cards/new?properties[status]=new&properties[type]=story” accesskey=”s”>+Story</a>

Save the wiki page with these new links and you’ll see new navigation links for your project that look something like this.

With the access keys we’ve put on the links, you can even use keyboard shortcuts to these new links.

Finally, I’d like to mention that currently Mingle is free for 5 users or less and that academic, open source, and non-profit projects can get a license to use it for larger teams for free too. Contact me directly or talk to the ThoughtWorks Studios team to get set up. We’ve even got people that will help you configure it to your team’s needs.

I just got a support request from someone today for a web application that I helped to write in college. It was my first Rails project and it was made as a senior class project. We had a client who was a professor from another department. We had to write our own version of backgrounDRb, used an early version of Rails, and wrote Flash as the front-end to an annotating engine for documents.

It was a great success for us using Rails and Ruby for the first time. We easily exceeded all expectations set in the beginning of the 10 week class. We had demo screencasts, a professional looking site, a great code/test ratio (first time ever for me), and a very happy customer. Some departments in our school were seriously considering using it for their document collaboration needs, and apparently, the software found its way around the world entirely by word of mouth.

I haven’t touched the code in several years and the machine that housed the subversion repo is long gone. It got me thinking about how software never really dies. I had no idea these people were using it to this day, but it still lives out there. I don’t even have the original site up anymore, so there’s no place to download the code.

It’s sort of cool and strange knowing that something that I wrote as a class project is being used by people to actually get work done. Maybe I’ll pick it back up and polish off the old code and breathe some new life into it someday. It’s just weird to think of a Flash/Rails app I wrote a few years ago as “old.” There’s going to be more of that in the future and it’s a refreshing reminder that everything old is new again and software never truly dies.

MacPorts is my preferred way of installing, managing, and upgrading much of the software I have on my Mac.

I’m setting up a new work machine today and I need to install ruby 1.8.5 on my machine for Rails to be happy.

Unfortunately, you can’t do something simple like specifying the version of the port you want to install unless it’s in a local repository.

Fortunately, my friend Stephen Chu had this problem about a year ago and has a nice procedure on how to do it. I’m going to update it for MacPorts and ruby 1.8.5 here.

1) Find out the svn revision number of the Portfile that has 1.8.5 by looking at:

http://trac.macosforge.org/projects/macports/log/trunk/dports/lang/ruby/Portfile

In my case it is 21127.

2) Set up a local port repository. In the file /opt/local/etc/macports/sources.conf, add this line before the rsync line:
file:///Users/Shared/dports and create that directory.

3) Install the port into your local repository.

cd /Users/Shared/dports && svn co --revision 21127 http://svn.macports.org/repository/macports/trunk/dports/lang/ruby/ lang/ruby/

4) Run portindex so that ports now finds your new (old) version of ruby.

portindex /Users/Shared/dports

5) Now you should be able to see ruby @1.8.5-p12 in addition to @1.8.6 by running:

port list

6) Install Ruby

sudo port install ruby @1.8.5-p12

You should be up and running now, so to check, run:

ruby -v

You will see something like this:

ruby 1.8.5 (2006-12-25 patchlevel 12) [i686-darwin8.10.1]

Now, if you want versions of ruby that MacPorts doesn’t have (later patchlevels for instance), you can modify the portfiles by hand, but I’ll leave that for another post.

Update: There is an “official” MacPorts HOWTO on installing older versions of ports here. It may be updated in the future, so I’m linking to it here: http://trac.macports.org/wiki/howto/InstallingOlderPort

Is anyone out there interested in some one page tech summaries? I had several occasions where they would have been useful this week and I am ready to write some if they don’t already exist.

They would have basic terminology and usage info as well as pros and cons for an organization.

Comment with what tech you would like covered in the comments.

Another consultant recently told me that she doesn’t believe Agile works for backend-type projects. She said that Agile just introduces too much change and she can’t keep up with the process. She also mentioned that there were studies emerging that said as much, but when pressed, she couldn’t find any.

Now, I’m all for Agile taking criticism. It’s about People over Process, so if there’s some process hurting people in that equation, then it needs to be examined and possibly fixed. I also believe that building working code iteratively is vastly better than talking about it for months and then sitting down to write code.

Our client, like all clients, likes to change their mind about what features they want in the application we are building. This other consultant and I are on two different teams within the project and she’s doing legacy integration work and we’re doing essentially greenfield development that will have to hook into her systems. As our client changes their mind, it’s pretty easy for us to keep up while she struggles to make changes to database models, ETL processes, and other bits of code in her work.

Thinking about what’s going on, I think I’ve come to the reason why it’s hard for her to change and easy for us. We’re using tools and processes that allow us to change rapidly. Her tools are hindering her from making rapid and iterative change and her processes might be too rigid.

Notice that I’m not telling what tools each of us is using. I don’t want to get into a debate about what tool is better, only the type of tool that allows people to be empowered to change at a moment’s notice and then change their minds back again. My hypothesis is that her tools are hindering her from keeping up with our clients. She’s certainly capable of doing the work, but I feel like processes that her tools make her go through are getting in her way.

What advice can I give to someone in that position? I’ve mentioned stronger scope control to her, greater communication between our teams, and getting another analyst to help with the workload of deciphering the legacy systems she has to integrate with. These are all people processes because I’ve seen other consultants use the same tools in my Agile projects and fit in with the process relatively comfortably.

Agile may not work for all types of projects, but I believe it can work here. It may just be that we need better tools.

I was reading an article by Robert X. Cringely today called Lean and Mean noting that IBM Global Services is laying off thousands of workers and possibly up to 150,000 in the US.

Go ahead and read the article. It makes me really glad that I work for a company that extols virtue and taking care of their people before making money. At ThoughtWorks, we don’t have this level of employee count, so I can’t say what would happen if we did.

We’re also trying to become more lean, but we are doing it in a different way. We’ve already adopted agile as core to the way we work a long time ago. This time, we’re applying lean to our processes and tools, not to our people. That’s the important point. When you treat your employees like family, you do things differently.

Hundreds of thousands is a big family and I’m sure that the execs at IBM GS don’t know the large majority of them. I guess that makes it easy to cast them aside in the name of pleasing Wall Street.

I have been doing a bunch of interviews lately. My second one this week (thanks recruiting!) was tonight and it didn’t go as well as it should have.

Here’s my typical interview strategy for when I am interviewing Business Analysts for ThoughtWorks and some tips to help you if I ever get picked to interview you.

1. Show Up On Time And Be Ready

I know that you are busy, but this isn’t college. You’re such a hot shot Analyst that you could land a job anywhere, right? Well, first you are going to have to show me that you want _this_ job. Our recruiting department sends out a confirmation to you usually 3 days in advance of my call. I also get a confirmation sent to me. If I can’t reach you on the phone number you give on the day of the call, I’ll usually try again about 15 minutes later. If I can’t reach you, I’ll send a note back to recruiting to reschedule the call. However, if I reach you and you are not ready to take my call and don’t have a good explanation (I’ll understand if the house is on fire or something), that’s an automatic *No Hire*. My reasoning for this is simple: it takes nearly an hour to do an interview with you and you know about it in advance, so you should have that time blocked off. If you don’t treat that time as important, it means you won’t treat our clients that way.

2. Prepare

Do your homework on ThoughtWorks. Find out how we like to work; our company culture. Read our website, learn about agile, visit some blogs, talk to us at conferences. I’m going to ask you some questions about what you know about the company, so show me that you did a little bit of work and I’ll be happy.

On the flip side, I do almost no preparation for my interview with you. All I know is your name, phone number, and what position we are hiring you for (that determines my questions, more on that later). I get all of your information like your resume and notes from other interviews you’ve had with us, but I don’t look at a single bit of it before the interview. This is by design. I don’t want to know anything about you that will influence my decision to hire you.

3. The Interview

I have a pretty consistent interviewing style that helps me be more objective about your skills. ThoughtWorks has a set of questions that they like me to ask and I also mix in some of my own. Here’s how the interview typically goes:

1. Ice Breaker
2. ThoughtWorks Questions
3. Domain Question From Your Most Recent Position
4. Random Domain Question
5. Questions For Me
6. Wrap Up

Ice Breaker
I start off by letting you know how the interview is going to go. I care more about your thinking process than you getting everything 100% right on my questions. By this time, I still haven’t looked at anything about you.

ThoughtWorks Questions
The ThoughtWorks questions are mostly softball questions so that I can go over some logistical things about the job. Are you alright with lots (and lots) of travel? Have you worked with Agile professionally? Why do you want to be a BA? There are a bunch of questions, but they give me an idea of what to ask you further. I’ll go into something in detail if I get the sense that you are stretching the truth. While you are answering my questions, I’ll pop open your resume and look at your most recent job and title.

Domain Question From Your Most Recent Position
By now, you should be warmed up and I have a good sense of what I am going to ask you. From your most recent position, I’ll ask you something about the business domain. This way, I get a sense of how well you can understand what a business does. If you’re a TWU candidate, meaning you are just out of college, this question changes to ask about some of your classes. I’m looking for a deep understanding of what you are talking about. I’ll dive into small details to make sure you really know your stuff.

I may also ask you about some things you have done for your previous job (or school). Special projects, clubs, whatever. I want to see that you haven’t simply gone to work or school and taken the minimum to get by. It’s for your own good because you’ll get burned out quickly at ThoughtWorks if you aren’t into the work.

Random Domain Question
This is my favorite part of the interview. I’ll ask you about a domain that has nothing to do with business and run through a few exercises with you to see how well you can understand what I am talking about. It’s always something off the wall and will have nothing to do with what you have done before, but that is the point. I’m looking to see how well you can adapt to a new situation and think on your feet. I’ll play customer roles and ask you to elicit questions about things I want to do. I’ll try to trip you up and see how you recover. This way, I can get an idea of how you will do with our clients.

Questions For Me
This is the part of the interview where you get to ask me anything you want about ThoughtWorks. Some people trip up here because they think the interview is over. If you are really serious, you will have some questions about how we do our work, what our people are like to work with, etc. I also get to sell you a little bit on what it’s like to work here.

Wrap Up
The whole process takes 45 minutes to an hour. I let you know about the next phase in the interview process and that our recruiting department will be getting back to you within a week or so. After that, I hang up and write the last of my notes about you and read them over again. I make them readable by someone other than myself and then I make a decision about whether or not to pass or pursue.

4. Pass Or Pursue?

After the interview, I have a pretty good idea of how I am going to recommend you. I ask myself lots of questions like: Is this person smart and do they get things done? Would I want to work with them? If the answer is no, it’s a pass. If I wouldn’t work with you, then I wouldn’t expect anyone else at ThoughtWorks to. If I feel like you aren’t smart enough to walk into a client and immediately start to figure out what is going on, that’s also a pass. If I have a good feeling about you, I’ll mark you as a pursue and send you on up the chain for our intense face-to-face interview process.

I hope this was helpful to future candidates. I’m looking for aptitude and attitude in the way that you present yourself to me. If you’ve got both, you’ll have no problem being a ThoughtWorker. Good luck.

UPDATE: If you are looking for a referral, please email me at jhoms at thoughtworks dot com and I’ll point you to the right people.