…crunch.

So, we had twocrunch releases in a row. It wasn’t quite 80 hour weeks but still stressful.

No so much fun and lots of work crammed in a short space of time means there’s inevitably issues which are going to rear their heads down the line and demand extensive refactoring.

But we got new features working in record time for a demanding client who were jumping up and down for them with a solid architecture which should be maintainable.

Points of note:

1) Identify and complete blocking tasks first. I know this sounds obvious but if there’s new work which can’t be  done because of blocking task- then you’re wasting time.

2) Get prototypes in front of the decision makers as quickly as you can. This is linked to the above.

3) Get real data (or at the very least realistic testing data) on a quickly as you can. Get your testing team and decision makers seeing what the end product will actually be working with.

Typically, there’s a lull of a few days after a release goes out, but when the leftovers of the previous release have to be taken care of as part of the current release, you need to be in high gear from the get go or you’re going to be suffering at the end of the release cycle.

I know, I know, this is all project management 101 but when you’re in the middle of something it’s easy to miss what the real priority is.

The start of this release is tidying up the last release. So I’d better get back to work.

p.s. Not blogging much because (a) I’m very busy at work (b) There’s nothing bitesized to blog about and a lot of the work is financial world oriented (c) I’m very busy at home.

There’s nothing quite like coming back to a development job after two or more weeks out. That feeling of looking at code for the first time and not being able to see the meaning of the lines.

Publicpay ActionResultway Avesay(Odelmay odelmay)
{
 isthay.OpulateRulepay(efray odelmay);

ActionResultway esultray = isthay.EdirectToActionray("Iewvay", odelmay);
eturnray esultray;

}

Three days later my brain has finally recognised that this should be:

public ActionResult Save(Model model)
{
   this.PopulateRule(ref model);

   ActionResult result = this.RedirectToAction("View", model);
   return result;

}

And I know there’s logic in there, but I just can’t focus to carry the thread through. It’s like reading a book, seeing and reading the words without being able to get the meaning from a sentence.

So in future, whenever I’m taking a break for longer than a week I will not leave large abstract tasks for myself when I come back. Maybe a couple of gimmie tasks to get up and running again.

You know what’s worse than getting a defect fix back in your queue?

Getting a defect fix back in your queue, for the second time, when you were very confident of the previous fixes (in fact even proud that you managed to crack that tough problem) and the only place that the problem is presenting is on QA’s side.

I never, ever, want to be the dev who seriously says ‘but it works on my machine’ but when I’ve tried from team mates machines, remote desktopped into QA boxes and I still can’t reproduce the problem it makes me want to pull my hair out.

My first instinct as a developer is to say “they’re doing something wrong” but the fact is that if QA say’s it’s slow for them, well then, it’s slow for them.

It doesn’t help that as a performance issue there’s a whole host of potential other issues which could also be impacting on all of this from computer hardware, anti-virus or other programs to network latency.

Oy Vey.

>edit – 2 weeks later<  
To paraphrase Homer Simpson; "JavaScript! The cause of, and solution to, all of life's problems."
…more…