Learning from Mistakes

I believe that part of what defines a person is what they do when they fail or make mistakes. This goes for personal mistakes and systemic problems. Everybody makes some mistakes, but what do they do when they realize it?

I recently received an email from a friend who was excited about an upcoming interview. We talked about the company a bit and it sounded interesting. Then he went to the interview and took some notes on how they meet the criteria of the Joel Test and they got a miserable 4.

He was completely distraught and said “How could I ever work for this company!” After letting him rant a bit, I asked if they were taking any steps to improve this. It turns out that from their internal self-assessments, they realized that they lacked basic things like requirements/scope documents, unit testing, formal compilation/deployment methods, and a host of other tools/methods. They wanted this person to come in and help develop these as their first project.

Put aside the difficulties of doing this as the Newbie and look at it. This organization acknowledges that they need to do things better, acknowledges that they need to improve their processes, and acknowledges that they need help. How could the situation be any better!? He has the chance to be a major player in turning the organization around, to evaluate new techniques and tools that fit with the processes, leave a lasting imprint, and – most importantly – improve the organization.

I have been involved in a task like this before. When I joined an organization, they were a miserable 1. The “manager” had Visual Source Safe but there was no concept of requirements, testing, no build process, deployment was a crapshoot, there was no schedule, and a host of other problems. When I got there, projects were classified as “Not Important”, “Hot” or “Very Hot”.

Through sheer force of will, I started to work to change things. I installed Mantis to do bug and requirements tracking. In order to make mysql “less scary”, I used Access to create a few pretty reports for distribution. In order to create a schedule, I installed dotProject on a little P200 under my desk. I started doing weekly deployment of my applications. I wrote my deployment methods to auto-detect which server (dev or production) and auto configure the database connection. After five months, I managed to get my projects up to a 6.

Unfortunately, no one else in the group was interested in these things… and after four more months of trying to convince people, I lost steam. The group steadily drifted back down to a one on half the projects… and then finally a zero on half of the projects. The last time I checked on the group – about three months later – the situation had only worsened.

Being in this role can be a wildly enjoyable and beneficial experience. You get to help people do their jobs better and satisfy your customers better. It can be great.

The other side… is just depressing.

Are you interested in API Design? Check out our new book "A Pragmatic Approach to API Design." In it, we cover the basics on why you might need an API, how to get started on modeling your API, and finally some design patterns and anti-patterns to be aware of. Available soon from LeanPub