Contract Retrospective

So, my 3 month contract turned into two and a half years.  What to make of all of it?  I'm sure that this will not be a 'proper' retrospective in the Scrum sense, whatever that is.  But it will serve.  I'll focus on the things that worked and the things that didn't work quite as well.  Without getting into confidentiality details, it was essentially an ETL project.


The things that didn't work as well:

  1. Lack of properly scoped requirements
    1. Seemed simple enough.  Vendor had product A which was used to bring data into internal systems (in a very brittle, painful, time consuming way).  Vendor had a better product B.  So, just make sure you get the same data from product B that you did from product A. 
    2. No one checked to see how easy/difficult it would be to get the 'same' data.  It was never clear to me if this was the vendor's fault, the client's fault, both, or neither, but whatever the case, by the time I came in, the conversion project was ready to roll.  As it turned out, it was not easy at all to get the 'same' data.
    3. In certain cases, it was clearly the vendor's fault.  You'd ask them for a rule to convert data value X to data value Y.  They'd give you a formula.  You'd implement it and discover it only covered 85% of the cases and you'd bring it to their attention.  They'd respond "Ok, how about this one?"  Iterate dozens of times.  There was a lot of humor in the process.
  2. Not adequately unit testing
    1. I didn't get onto the testing bandwagon till recently.  You live, you learn.
    2. Because of the nature of the project, vast portions of it were untestable.  I had arguments with people about this, but it is true.  A large number of 'bugs' and problems were only visible by looking at a large dataset and comparing it over time (sometimes a week or a month were needed before you would see data that was problematic).   There is no way that I know of to unit test actual data in situations like this.
    3. Having said that, it would have been greatly productive to create a C# test suite that could test basic outputs of UDF calls and other things such as that.  And some of them wouldn't be 'pure' in some sense of the word, but setting up integration-type tests of problematic data situations could have been done.
  3. Corporate Politics
    1. This is one of those 'it was not my fault' sort of things, but there was quite a bit of politics involved in getting the work we did promoted.  It was, in retrospect, a *huge* change for the end users what we were doing (no ETL conversion project can achieve 100% data symmetry so the changes were noticeable), but the fact remains that the actual coding work done took 30-50% of the time to complete, the rest of the time was involved in convincing the important players that the changes were correct.  People *really* don't like finding out that a certain portion of their data has been incorrect for many years, and so no matter how well you describe that fact, prove it beyond reasonable doubt, there is an inherent resistance to accepting it.
  4. Talking more, listening less
    1. This is actually more important for other contracts down the road because the people I worked with liked to be challenged, liked strong opinions, etc.  But, this is something to keep in mind.  As my last project manager (more on him below) described it, "Working with jdn is pretty easy.  Ask him his opinion about whether something will work or not.  After he says 'No', ask him again and maybe he'll listen to what you said in the first place."  Now, he was exaggerating.  How much is open to debate.  But it is important to do everything you can to listen to the client, what it is they are trying to achieve, how they want to get there, etc.  Give them the opportunity to explain themselves as fully as possible, remembering at all times that it is their business, and you are there to help them.
    2. And then after all that, tell them 'No' if that is the correct answer.
  5. Remembering I'm a contractor, not an employee
    1. A friend of mind reminded me a long time ago about a very valuable lesson to remember as a contractor.  I was all ticked off about something, because what was being implemented the way I wanted it, was going to cause further work down the road, something along those lines.  And he said "Are they going to pay you any more to do it better?" 
    2. This isn't to say that you don't provide the best services you possibly can at all times.  But, it is important to remember that, as a contractor, you basically are providing the client what they want.  If the client wants something unethical, you walk away, but otherwise, if they want to implement something you don't agree with completely, that is your job.  To give them what they want, even if you don't think they should want it.
    3. More times than necessary, I would find myself forgetting this.  This wasn't a career path in the same way as being an employee is.  The last project manager I worked with was notorious for being difficult to get along with.  He was a control freak, he didn't want developers meeting with end users (even though they liked me better), he wanted to be involved in every phase of the project (architecture, development, you name it).  Most every employee on the team who worked with him asked to not have to do it again. As an employee, I wouldn't have worked with him as easily.  Once I remembered to 'know my role', he was actually quite fun to work with.  He was very intelligent and had a good sense of humor, and so we accepted our roles.  As a contractor, I didn't really have much say about many things (though since he was intelligent, if I felt strongly about something and argued it, he would accept my judgment, begrudgingly...which make it that much more fun when he had to admit I was right).  On the other hand, as a contractor, I had a certain amount of freedom to say things you couldn't really say to someone if you were an employee.  Especially since our boss was an interesting sort who believed that good-natured insulting built camaraderie, it was open season, and he'd toss it right back at me, and we'd both enjoy the exchange.
    4. To bring it back to a slightly more serious and less cynical level, it is important to remember that as a contractor, you are providing services for a fee, and while your expertise is being requested, your work will carry on long after you are gone.  Sometimes, you implement something less than 'ideal' in your mind because it is politically expedient.  Idealists of the world will get upset about this, but really, in the end, it's their business, and corporate politics often times makes the world go round.  And sometimes, you are simply flat out wrong about the best way to implement something.


The things that did work well:

  1. Knowing the right technology to use in the right situation
    1. The client had committees, lots of them.  Which produced standards, lots of them.  Where appropriate, we ignored all of them.
    2. Most everything was supposed to use C# as much as possible.  We used pure T-SQL.  They loved web services.  We used none of them.  On the SQL side, you had to use surrogate primary keys.  We didn't (and it was right not to use them, in just this case).  You needed to enforce referential integrity.  We didn't (and it was right not to enforce them, in just this case).
    3. We needed our own hardware, isolated from the rest of the production environment.  We forced this.
  2. Having the ability to work freely
    1. Except for a few hiccups, I was able to code what was needed to fulfill the requirements, as I saw them.  There were code reviews, but mainly, I could write the code I felt was needed.  Not having to look over your shoulder constantly as you work is tremendously valuable.
  3. Working with like-minded co-workers
    1. My main boss was one of the best I've ever worked with.  He was/is one of the more interesting people I've gotten to know, but he let you do what you needed to do without needing to change everything.  If it worked, he liked it.  How you did it was left up to you as a worker.  He felt that people should be motivated by their paychecks, and not need to be baby-sat all the time.  He also cursed like a trucker, which I can relate to.
    2. For the most part, the group that I worked in had very intelligent and humorous members.  Fun to work with, highly skilled.
    3. Though I only worked tangentially with a number of them, I got to meet a number of highly skilled people.  The DBA team was awesome.  One other developer in particular was one of the best I've ever had the opportunity to work with, even though we only officially worked together a day or two, as he was on another team.  I learned a tremendous amount from him, annoying him about development practices and much inane bullshit.  Even if he didn't grasp the worth and integrity of Canadian bacon.


Things to focus on for the new contract:

  1. Listen
    1. Figure out who the important players are.  Figure out exactly what you are expected to do.  If the gig is a bad one, there's not much you can do, but if it is a good one, as I expect, you will find a sweet spot where you can provide high quality services.
  2. Learn
    1. Never under estimate the ability to learn from others.  I'm smart, arrogant, opinionated, and all that, but begin receptive to highly skilled co-workers and how they do things is one of the best ways to grow as a developer/architect/person.  I think I'm good at a number of things, but except for a few things, I *know* I'm not as good as others.
  3. Remember, it's a contract
    1. Provide the client what they want, guiding them where you think they should go, but remember, it is their business.
posted on Tuesday, July 17, 2007 7:17 PM Print
# re: Contract Retrospective
Aaron Erickson
7/17/2007 9:24 PM
If only all post mortem exercises were as thoughtful as this one... good work.

I hope you get a chance to give this feedback, the good, then, and only then, the bad, to the people at your previous client. I would love to hear how that goes.


# re: Contract Retrospective
7/17/2007 9:32 PM
Our bacon is a little more square since you left. You will be missed.

Post Comment

Title *
Name *
Comment *  
Please add 6 and 4 and type the answer here: