class DirtyInformation

Releasing a new product can get a person into a flat spin and make their head hurt like crazy. The last two weeks has been a whirlwind of excitement and nausea. I was thrown head first into the first time I have ever been the person in charge of a production release of something someone else was paying me for.

We set out on this journey almost a year ago. The client has been up and down in what they wanted. We have a lot of crufty code, but things have been looking up lately. Everyone is excited to get something out to the public. The developers desperately want feedback from real users, and a stronger guiding voice than the wishy washy customer we have had.

Monday - the official day we are supposed to release…

“WTF? This has never happened before. What is going on?” Certain interactive data seems to be missing small parts here and there. The worst part is that there seems the be no consistency. When we try to replicate the issue everything is fine. It looks like we are going to need another day to figure this out. I hope that it is just this one day.

Chase down some issues with connecting to the database. We believe this is a hosting company issue. We can let them deal with it, but right now we need to add some logging so we can tell when and where this is happening.

• think about logging before there is a problem

Tuesday - crossing our fingers…

Rushing into the room I shouted, “I understand what happened. Mongoid is not performing atomic operations on arrays so when two users touch an array at near the same time, the second one wins the update.” “That makes no sense,” the others say rolling their eyes. “Have you tested this?”

“No,” I sigh. “I just know that is what is going on. I’m looking through the code, and timestamps and it is only happening when people are both touching the same data. I also looked at the db logs and the queries on array operation are completely overwriting the arrays and not using the atomic operations.”

“We believe that is an issue, but there has to be something else going on. We’ll fix what you are talking about and then see what happens.” No one believes me, but at least they are willing to prove it, and go along with the fix. The tests took some time, but after the first test we flew threw the rest of the code. The code slims down and gets faster with the fixes in place. Now we just have to wait and see.

• test users interacting in parallel
• watch for data that can be touched by more than one user at a time
• don’t say “Your idea makes no sense.” Nicely sound surprised and ask them to show you.

Wednesday - About time…

The beta site is launched. People start signing up and giving us feedback. There are a few tiny bugs found and squashed. We can finally start to plan for the next release, and clean up some of the technical debt we took on to meet this aggressive deadline.

First, make the rescue jobs take in the data they need, and not pull from the db. This will make sure that even if the db is down that the background emails can still go out. This was done quickly, and actually fixed a 404 issue that was coming up.

On second thought we should turn our logging back down, first. Not only do we know it is slowing things down, but it is annoying when we are trying to look at just errors that may appear in the logs.

• too much logging can be annoying
• logging slows things down more than you think
• give background jobs all the information they need up front, and try not to have them touch the db

Thursday - I can’t believe God made it 6 days before resting…

I’ve put in close to 100 hours in the last week and a half. My family is missing me and I should really take a day off. I took Wednesday through Friday off, but of course I can’t keep my nose out of it. I am still talking, planning, and working on the site. Most of the things are not that important, and I know the team is smart and can function without me.

I have a lot of pride in my work, and the work of the team. It is so hard to walk away while they are still hard at it. I know they weren’t working over the weekend, and I was, but this is my team. They need me, or do they.

The team gets through the day, mostly on their own. I only shoved my nose in for my own ego.

• you made sure your team was filled with smart, self motivators for a reason
• let your team shine
• if something goes wrong there is always a way to fix it later

Friday - customers, users, and project managers can be a pain…

The product manager seems upset because people decided to take the day off or to work from home. I’m happy that someone is finally resting. The customers want something changed ASAP, and all the developers are at home.

Isn’t it always ASAP? It is a small change, but was something that they specifically asked for, and now are realizing how misguided the request was. That really is my fault.

One developer working from home can’t get in to the server to deploy. His ssh key is on the jump box, but he can’t get to the production servers from there. Now a team member calls me when they need me. I appreciate that I have had to do very little today.

Little is an understatement. My youngest daughter (3 yrs old) is throwing up and running a fever. Please don’t let me catch it.

• upmanage misguided decisions through the project manager or the customer directly
• the team will call you if they need you
• even success is met with grumpy bosses…don’t be one of them

Sometimes when developing I forget some of the basics as I go along. This time and many times in the past I have forgotten to follow the Single Responsibility Principle. I always forget it in the same place, the User object.

The User class always appears to be a place to take care of login and logout, but it does so much more. Everytime I need to change the User or expand to multiple types I end up dealing with login issues. It is easy to think that the responsibility of the User is to handle all things related to the User, but logins are not part of the User. The login is the responsibility of the Credentials.

What happens when I need multiple logins to act on behalf of the same user, or when I have multiple user types, but I want to use the same login system. In the past I've always created a User and an AdminUser, with separate logins. Why?...It just felt right, and the AdminUser had different properties than a regular user. Now I have multiple user types that should share some common code. Sweet, a module will do that for me. It still doesn't solve all of my issues. I have to separate logins. What should I have done?

A Credential class should be created and can link to a profile. This allows my Credential class to only change if the login system changes. Each user type can be a separate Profile class. This eases the burden of the user class and allows greater future expandability.

Why didn't I do this in the past? I've run into this problem many times, but never really got it. Now I'd just like to say, "I GET IT!!!"

I've been working with some javascript lately and wanted to see if it made a difference if I was changing the class or inline style of an element. I had heard that changing classes was faster, but can it really make a big difference?

YES!!!

I coded up a quick example. Here are the results in ms(all on osx):

• Safari 5.0.2
  • changing style:123
  • changing class:15 - 87.8% faster
• Chrome 7.0.517.44
  • changing style:115
  • changing class:16 - 86.1% faster
• Firefox 3.0.15
  • changing style:333
  • changing class:99 - 70.3% faster
• Firefox 3.6.12
  • changing style:261
  • changing class:60 - 77% faster
• Opera 10.10
  • changing style:554
  • changing class:111 - 80% faster

I really didn't expect those kinds of results. Kind of amazing!

I've been doing some playing with MongoDB lately. I've grown very fond of the platform, and am looking forward to using it in some of my future projects. My first gift back to the community is a cookbook recipe. I'm hoping that soon I will be able to give some code contributions.

The other night I spend forty-five minutes on the phone with a friend talking about what agile is. He hadn't been exposed to the ideas behind agile. When I started talking I don't think I really hit on what agile IS. I talked about practices and the way my team works. He had many of those methods in his experiences but not all of them, and not really in what I would consider agile. After I got off the phone I noticed that I only talked about practices and not about principles. So I thought to myself, "What IS agile?"

This is a hard question for me to answer. Every time I start to think about it I go back to the practices that I use in order to achieve what I consider agile. That isn't right. Agile isn't a set of practices, is it? No it can't be. The Agile Manifesto specifically states "Individuals and interactions over processes and tools." If it isn't about processes what is it?

The more I thought the more agile seemed to be nothing more than agility. Every methodology that I talked about had to do with the ability to change direction at the drop of a hat. Agile is about reaction. Not just any reaction, but ones that cause positive change and outcomes. Agile is about feedback and learning. After all this...Am I agile?

I am agile. I am constantly learning from every source at my disposal. I go looking for ways to improve myself and my product. I adapt to change. I am always trying to push the envelope further. Yet, I can't help but feel that I missing something? What am I missing?

The one thing that I didn't mention above. Is it in there somewhere? Delivering a useable project at any point in development. That is it. That is what I'm missing. This has got to be the hardest part of agile. No matter what we do it always seems that we are one step away from delivering that product at the drop of a hat. If the customer says, "I want to deploy now." I should be able to happily say, "Already done." Not that I don't have software that I can deploy all the time, but what really makes a project "useable?" Can I deliver something that can be let out into the world every week?

That is my goal. From this moment forward I'm going to try and guide my project and my customer so that we are always moving forward with usable software. Not a half done feature at the end of an iteration. I'm going to try and guide the story selection for my projects so that at the end of each iteration we have something to "useable" to deliver. Is it possible?

What is useable? Is this really possible, or is it an ideal that we strive to achieve knowing that it doesn't quite work that way. Once we have the app in production it is easy to keep that way, but is continuous deployment really possible from day zero? Can each commit still be tiny yet completely deployable? What are your thoughts? Also did I miss anything that defines agile, but isn't a practice/methodology?