(Really) back to writing code

A few weeks back I started work on a new module for my current project.  I haven’t done this for quite some time, as I found myself working with other members of the team, so this was really exciting.  Fast forward today and we have the core set of the module in production, and are looking to complete it within the coming release or the next.

Of course, it wasn’t without its share of headaches and points of improvement.  Below are three things I think are worth pointing out, primarily so I can remind myself from time-to-time about them:

It’s high priority for a reason

This module was mostly about computation and had to be right the first time.  And it was marked as “high priority”.  These should have been signals to get this module started as soon as possible.

Unfortunately, that wasn’t the case.  We spent a couple of days into the release sprint before we sat down and ironed out the details.  On the other hand, the positive spin to this was that we really sat down to discuss things which I haven’t seen for some time, so we had something that was well thought of.  Just that more implementation time would have been great.

Get people involved

Especially QA.  I managed to get a sub feature split and implemented by a team mate but the fact that this module had a couple of cases that needed a lot of testing meant that I spent more time than I would have liked verifying and re-verifying things.  And I had to do this without letting my biases get the best of me.

As a side effect, getting people involved meant that I need to review my understanding of the entire thing.  So instead of figuring things out as I go along, I am forced to add a bit of planning to make sure that things made more sense that if I was only involved.

Amusingly, when I got around getting people involved it didn’t really take that much time to explain things.

Focus on quality

So on the implementation side I got to go alternating between adding new stuff covered with tests, and refactoring it when it made sense.  I believe that tests and refactoring should be done along the way so they are fresh in one’s mind and are manageable.  I had to cut some corners when the end of the sprint neared though which, as expected, proved to be hard to address post release.

I think I could have focused a bit more though, since I ended up writing custom stuff such as a utility to format amounts and dates correctly but I guess they simply had to be done.