In any case, yesterday I went to talks by two legends: Ted Neward and Brian Goetz. I’m sure I don’t need to give either any form of introduction (and if I do, leave my blog now, go do some Googling, learn a bit and come back ;) ). I listened to Brian talk about concurrency and memory models and I heard Ted talk about classloaders and give the keynote called Iconoclasm. I’ll spare you reading many paragraphs. They were all excellent. When you go to a Brian Goetz talk, it’s like being back in college. You have the expert on concurrency and how Java works at a low level geeking out on topics he loves. Even though his topics cover hard stuff, he does them with passion. Ted is just an all around cool guy who is a great speaker and also incredibly knowledgable about languages in general (He also does Microsoft stuff…no one’s perfect). Overall, I was pleased with the sessions yesterday.

With that being said, looking ahead to today, I’m honestly lost. After going through the slides for some talks with potential, they seem to have less potential. We’ll see what happens. As always, let’s hear from you! Questions about sessions or speakers, let me know in the comments!

Let’s take a step back. How do you currently track the status of a project? Microsoft Project or some related piece of software? Excel (*gasp*)? There are a number of issues with this approach:

1. Project status is not publicly available.
   When the progress of a project is stored in a software product like Project or Excel, it is easily hidden or is at least difficult to access. This encourages things to be hidden. Things to be changed.
2. It’s hard to use
   The implementation of project planning is, in essence, a very simple process. It is the alignment of resources and tasks against time (the hard part is the alignment piece). Why do project management tools need to be so complex to essentially display timelines?
3. Developers can’t take ownership of what they work on.
   Typically when projects are tracked using software products as stated above, they are maintained by a lead or manager cutting the developer out of the process of delegation of tasks.
4. Collaboration across tasks doesn’t occur.
   Developers don’t use Project. Developers despise Excel. Because of that, they usually don’t look at it. So they don’t get a big picture of the project flow and prevents the implementation of operational efficiencies that could occur with simple reordering of tasks.

Card walls attempt to address the above issues.

Project status is not publicly available

A card wall is the ultimate way to communicate project status to the entire team. You have a wall of cards divided into three or four categories: Ready for development, in development, in QA and in production (with the fourth one optional. There are some other nuance options that you can add in, but we won’t go into that here.). To obtain project status, all a person needs to do is look at the wall. If the card isn’t in the ready for development yet, the story has not yet been written (it’s in the BA’s hands). If it’s in development, typically you’ll have a picture or name associated with the card. This makes it quite clear who is working on the functionality. If it’s in QA, development is complete and it’s being tested. If it’s in production…well, I’ll let you figure that one out.

Project software is hard to use

Well you could go to Excel or Project training and spend thousands of dollars. However, I prefer spending that money on better things, like high quality developers. Instead of paying for licenses for Project and training, etc. Cards are intuitive. People get the card wall. When the BA has completed a story for development, they put a card on the wall with the name of the story. When a developer is prepared for a new story, they choose the card to take and move it into development under their name or picture. When they are complete with the story they turn the story over to QA by moving the card to in QA. Once it moves to production, typically the project manager will move the card to production. Developers don’t need to worry tabout what drive the Project file is on or if someone else is in the Excel file. Cards, scotch tape and a wall. If you can’t figure that out, you probably can’t write the code to implement it anyways.

Developers can’t take ownership of what they work on

This is one of the most important in my opinion. The traditional way to assign tasks was exactly that. A project manager assigned tasks to developers and they worked on them. However, which are you more likely to work your hardest on:

• A list of things your spouse gives you to do.
• Something on the list that you created that needs to be done.

You are more likely to put your all into things you choose. By allowing developers to work on things that they choose as they complete tasks empowers them to learn more about the application. This prevents the funnel problem. The funnel problem is when there is one person that knows how to work on a particular part of a system. Developers tend to spread their knowledge around the application which benefits everyone. Finally, there is an empowering psychological event that occurs when someone take a card they were working on and moves it. The job well done. The beginning of a new endeavor. We don’t experience this enough at work and this is a simple way to do so.

Collaboration across tasks doesn’t occur

I consider this reason a tie with the previous one with regards to importance. When we use Project or Excel or most other project management tools, the people in the trenches loose site of the big picture. If you are a project manager that is working on a project that is expected to last a year with 30 developers, you may pass out copies of the project plan to each developer. But what I’ve seen in most cases is that project managers pass out the piece of the task list that pertains to the person you are giving it to. By doing this, blinders are being put on the team with each person being forced to focus on their own small corner of the world. But what if developer A worked on something that developer B will be working on in two weeks and developer A knows that he had to do something unusual to get things to work. If he knows that B is going to be working in his old code, he can share the knowledge he gained when working on it the first time. This cross task collaboration has huge productivity benefits that should not be ignored.

So how do I do it where I work?

So now that you have an understanding on why you would want to use a card wall, how do you get one past the IKEA Police on your team? You don’t have a wall you are allowed to use. You don’t run the project so you can’t get others to maintain cards. As with anything in life, work with what you can control. In this case, you can control how you work.

A little background. I work for a large IT organization (about 1000 employees out of about 2000 total for the company) in a very old school, risk adverse company. Until very recently the word Agile might as well have been a four letter word. It was crazyness. I work in a cube. The typical cubical with a desk on two sides, a tall cabinent for hanging my jacket and a cabinet above my desk along one side.

So with Agile and any of it’s practices viewed as insanity, I decided to change what I could and that was how I worked. I had a list of tasks that I knew I had to complete. I purchased a deck of index cards and setup a makeshift card wall on the doors of the over desk cabinet. Since I was the only person the cards were for, I didn’t need a large amount of real-estate. I put my tasks into the ready for dev section. The card I was working on moved to the in dev section and any cards I completed were moved to complete.

So I worked like this for the life of a three month project. It didn’t take long for managers to notice the wall of index cards hanging in my cube. Some of my co workers made fun (I was out of the office one day due to food poisoning….I came back to a card in the complete section that said “food poisoning”). Managers, however noticed. Anytime they asked what my status was, I directed them to my card wall. I made sure to point out that any time they wanted to know exactly where I was on the project, all they had to do was take a look. You know what happened? They stopped asking.

They stopped asking me what I was working on or where I was on something because they already knew. They knew how fast I was moving cards, they knew how many and which cards I had moved. They knew exactly where the project was in a glance.

The manager I directly report to loved the idea. We started expanding it by creating a tech debt wall. Now, I have to come clean here. We still are not 100% past the IKEA Police. Our building operations staff still doesn’t want the cards to be visible in the office. So instead of putting them on a wall, we have ours on a window. In fact, if you stand outside our building and look up, you can see my boss’s cube because the window in his cube is covered in index cards.

From the tech debt wall, we have finally expanded it to full project management. The project I am currently working on is scheduled to go live in April. The card wall is not the only reason for this success, but it has contributed to it, but we are months ahead of schedule. Many months (5 to be exact). The agile principals discussed here and what I will covered in the future posts are the primary reason for that.

Conclusion

So that’s it. Over this post, I covered why a card wall is useful for project management as well as how I took a small amount of rebellion and harassment and proved that it can be a very valuable resource management tool. What are your experiences with card walls? Do you have your own version of the IKEA Police? Share your experiences in the comments!

I’m sure you’re thinking, “Yeah, right. I’ve read tons of those articles before and they work about as well as something I would buy from Billy Mays.” Everything we will talk about over the coming weeks are things I have seen be effective in a large, Fortune 500 corporations. However, before we dive into the specifics, I wanted to spend this post defining what I said we were going to talk about…agile practices in the real world.

“Agile practices”. That means paired programming and writing on the walls and stuff, right? Wrong. For this blog, agile stands for four main principals (from the Agile Manifesto):

• Individuals and interactions over process and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

This blog will discuss how to implement the above four tenants in a large corporation.

“in the real world”. This means that the CIO has not come down from on high and decreed that agile is the new required practice and all projects shall be agile going forward. This rarely happens (and would make adoption much more easy) so let’s assume it hasn’t happened for you (if it had, you wouldn’t be reading this anyways). No, instead we are going to assume that you, Joe dev or other lower level employee can see where agile can be useful and want to apply it to make your life and your customer’s lives better.

I have gone both routes. I have had buy in from the very top and I’ve had management that disdained the word “agile” much less supported a test project. In both cases, you can be successful with agile. I’ve also seen the same approaches fail horribly because those implementing the process didn’t know the why behind what they were implementing. I will be sure to cover this as well. Please note, implementing practices without knowing why you are implementing them is a recipe for disaster. Any practice you implement should start with “What problem is this change attempting to solve?”.

A word of caution. Change the way I will describe is slow. However, with each step, the next becomes easier. I look forward to sharing my experiences with you. I also look forward to the comments you leave.

I’m currently working on a project to move batch processing from the mainframe to Java. I’m actually very excited about it. We’re playing with some very cool technologies (Spring Batch, Terracotta for some grid computing, etc). However, I currently am a bit ahead of schedule so I don’t have specs (*gasp). Since I spent my former years working in COBOL (including my internship at ComEd), I asked for the program that I will be converting first so I could sift through it myself. 303 dead trees later, I have alot of reading ahead of myself.

Printing out the program made me a bit nostalgic for the days of college so I did some quick Googling to see if they still use MVS Batch. They do and I found the documentation for it. Very impressive. It starts with turning on the computer! Check it out: http://www.cs.niu.edu/mvs/mvsbat.html.

So with the help of Google I discovered the -verbose:class JVM parameter. Ever wonder what classes are being loaded in your JVM? Ever wonder who is loading that mysterious class? This is the parameter for you. This option outputs a list of classes loaded and from where. In my case, PowerMock was loading Log and so was a copy of the commons-logging jar file I had in my project. What are some debugging tips you’ve used in the past that may not be every day knowledge? Leave it in the comments!

• Automating of issue solving.
  
  As technologists, we face scenarios on a regular basis where we have to work through something that we haven’t done before, haven’t done in a while or just aren’t sure what the best way to do it is. When this occurs, our productivity can come to a crawl as we research the solution. With two developers, the likely hood that: a) one of the devs knows the answer or b) they can research the answer quicker cuts down on the time spent churning on a single issue.
  
  
• Knowledge transfer automation.
  
  This is related to the item above. When you work side by side with someone, you learn together. If one person knows something, they teach the other and vice versa. By rotating pairs, this transfer of knowledge happens automatically across your team. This limits the creation of SMEs and prevents bottle necks that occur when only one person knows a particular technology or part of the system.
  
  
• Automatic distraction repellant.
  
  When was the last time you were working in your cube and someone walked up just to talk? Unfortunately, (although no one will admit it) this happens way to often in the business world. This painful disruption of thought as well as the time taken away from development is a huge drain on productivity. However, when two or more people are already working together, people become less likely to interrupt. Those casual “Hey, did you catch the game last night?” conversations seem to just go away. People, by nature, are less likely to interrupt a pair of developers working than just a single developer. Just another place where there is power in numbers.

So how about it? On paper this makes sense. Those who have tried it seem to agree. However, why is it that this practice seems about as likely to go mainstream as cutting overtime (which many studies have proven actually makes developers less productive…a topic for a different day)? What are your experiences with paired programming? What’s good, what’s bad? Share your thoughts in the comments!

function upOption() {
  if(!clicked) {
    clicked = true;
    options = $('selectId').childElements();

    for(var i = 0; i < options.length;) {
      element = options[i];
      if(element.selected && (i - 1) >= 0 ) {
        options[i].remove();
        options.splice(i, 1);
        Element.insert(options[i - 1], {before: element});
      }

      i++;
    }
    clicked = false;
  }
};

Where I got stuck was on the Element.insert. The documentation (as found here) states that “Inserts content before, after, at the top of, or at the bottom of element, as specified by the position property of the second argument. If the second argument is the content itself, insert will append it to element.”. What does that mean?!?!

I’ll tell you what it means. Element.insert takes two parameters, the element to insert the new content ajacent to and one of the following:

• The content to be inserted
• A Hash with a single key that dictates where to put the content with the content as the value

The example above is an example of the option with the hash. What this does is it takes options[i - 1] and places element into the DOM as the first sibling above options[i - 1]. What each option does is as follows:

• before: Places the element as the first sibling before the identified element in the DOM
• after: Places the element as the first sibling after the identified element in the DOM
• top: Places the element as the first child under the identified element in the DOM
• bottom: Places the element as the last child under the identified element in the DOM

If we use the example Element.insert($('myList'), {XXX: new Element('p')});, the new p element would show up in the corresponding place:

<div id="container">
     before
     <ul id=”myList”>
          top
          <li>element 1</li>
          <li>element 2</li>
          <li>element 3</li>
          bottom
     </ul>
     after
</div>

So there you have it. Please feel free to point out any optimizations I could do in my method. One I already know about but was unable to get working was removing the line element = options[i]; and just use the element returned from the remove() function. Unfortunately, I was unable to get that to work (as tested in IE7). As always, I look forward to the comments!

Partial Mocks are concept provided by EasyMock’s Class Extension package. They allow for the mocking of a method over an entire class. A tutorial coming soon.

Once again, I’d like to say great job to Joe and thanks for the free advertising ;)

The first was the blogging platform Journalspace in January (they have since been picked up by a new owner…hopefully they have heard of off site backups). Journalspace was using RAID as their backup. The thought was that if one drive fails, we have a copy on drive two, so all will be good. Fine in theory…if the only failure that occurs is a hardware one. In Journalspace’s case, the data was wiped via software. If you delete a file on purpose from drive one, it will be deleted as well from drive two. A backup strategy, RAID is not.

Now we have the social bookmarking site Ma.gnolia. Today they announced that their attempts to recover from a database server crash have been unsuccessful and all data has been lost. In this case, instead of not having a backup strategy at all, they just had one that didn’t work. I would now consider them poster children for testing your backup strategies.

Am I missing something? As a user of services like these, these should serve as examples of why you shouldn’t trust your service providers and do your own backups. Backup your WordPress or Blogger blogs. Backup your del.icio.us and digg links. What methods do you use to backup data that service providers store for you? Let us know in the comments!