…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…

Take that! unnecessary table variable! Removed by the power of common table expressions!

I have a table in the form:

But what I really need is a table with an extra column with a sales id for each seller, like this;

In a past life I would have written the alter script to add in the column, with an empty field (null or -1); created a temporary table to iterate over every ‘Alice’ sale and set those values, followed by those for ‘Bob’. And this is what you get when you’re thinking procedurally. Using Common Table Expressions and a Partition makes this far more efficient (at the cost of more complicated code).

WITH cte (ID, seller, sales_id)
AS
   (
      SELECT
         ID,
         seller,
         ROW_NUMBER() OVER (PARTITION BY ID ORDER BY ID)
      FROM sales WITH (NOLOCK)
   )
UPDATE S
SET S.sales_id = C.Pattern_ID
FROM sales S
INNER JOIN cte C
   ON S.ID = C.ID
AND S.seller = C.seller

And hey! a legitimate reason to actually use a <table> on a webpage without designers shaking their goate-ed heads at my foolishness.

Following on from my gearshift analogy yesterday, my personal programming mental block is the syntax of the switch statement. I know how it works, I know what it does, I just can’t get the syntax right without looking it up. Regardless of the programming language. Java, C# or TSQL. I get as far as CASE … before I have to research it. It’s a pain in the ass but I just can’t get it to stick and I don’t use it often enough to memorise it properly. Ah well.

Just for reference, in TSQL this is what you want to be doing:

SELECT
   CASE tab1.col_name
      WHEN 1 THEN 'one'
      WHEN 2 THEN 'two'
END
FROM table1 tab1

Yes it’s trivial, but it just won’t stick. Maybe it will now.

And this is what happens if you’re doing SQL and then get shunted up into procedural code and then back down again.

In C#:

• you have variable names like local_Variable_Name instead of localVariableName.
• The fact that you can call methods without prefixing the name with EXEC seems… just, wrong.

In TSQL

• you keep on forgetting to use SET before variable assignment.
• the fundamental set based versus procedural programming approaches which means that fast running procedures become very, very slow when you get them wrong.

oy vey. The trials of a generalist.

<meta> Having great big images and cleverly formatted text is great for show and all but it does mean that I’m not posting as much as I’d like, so, I’m going to try and set up a separate Articles section for longer/better posts and have a the usual blog style on the front page. </meta>

image from wikimedia commons

Well, 3rd week of January resolution. I’m going to track my time and the task I work on in the office as accurately and honestly as I can.

Currently we’ve got a very rough cut timetable system where everyone fills in their time after the fact using very broad work categories. 99% of the time this works absolutely fine. Last week we had a request to give a total amount of time for a particular project. Of course no-one on the team was tracking this one project distinct from the others so the best we could do was dead reckoning. It’s definitely wrong but it should at least be in the right ball park.

A co-worker turned me on to Grindstone which is a fine granularity recording mechanism for windows. You set up tasks, hit the start button and away you go. At the end of the day/week you can get a bunch of nice reports on the time you spent on the different task.

The only difficult bit is to be honest with it. That time you spend on youtube? You’ll be tempted to mark it as “working on defect” but you’re only tricking yourself.

I would hesitate to recommend it for project managers to enforce it on your employees because it rely’s entirely on the honesty of your staff (which shouldn’t really be a problem) but more than that, it gives the developers a very big brother feeling. It’s not enjoyable working if there’s no wiggle room and if developers can’t even pretend they enjoy their jobs, then they won’t be very productive.

Image is taken from commons.wikimedia.org (resized and resampled)

The days when developers did this sort of stuff, or indeed, this are long gone.

I was going to intro that with a “Sadly” but to be honest it’s only sad for the management who exploited naive, passionate and gifted employees who “believed in the company”. Those hackers who produced work out of love of what they were making rather than for fair payment also allowed themselves to be exploited so it works both ways.

I think (hope?) that developers have become more business savvy. On one hand this is bad for companies because they are more aware of the value of what they’re producing and are less likely to be screwed over. It’s also good for companies because it means that they will focus on creating what is important to the company rather than their own pet project. …more…