Movebubble Sprint: Day 9

Today is going to be manic. We’ve got 2 days left of the sprint to fix all of the issues that came out of the bug hunt and I’ve lost my voice to boot. Turns out that Tuesday night hurt me more than I thought; the cold that has been kicking around has come back with a vengeance.

I’m not the only one who is suffering. Jordi has apparently had a back spasm and needs to go a clinic in Angel. He’s unlikely to be in today as a result, or at least not until a lot later. That’s not ideal as he’s in the best position to be fixing bugs in the negotiator app.

After standup, I go through the bugs reported on the wiki page and prioritise them with Laura. It looks like a lot, but actually when we get down to it there’s only really one issue in the renter app that is high priority; the rest are minor styling and copy or related more to the backend code. So she gets started on that while I get started on transferring all the bugs into JIRA and prioritising them.

It’s a tedious task and I get interrupted on a number of occasions – first there’s the issue with SQL replication for chat which we noticed on Tuesday but didn’t get a chance to address and I realise that I haven’t pushed the migration code that applies the correct dates to the chat room. I do that and it seems to sort the issue for Boris. There’s also a call from Andrew who is out in the field, he needs a verification code for a new user of the renter app. I find this for him and get him into the app.

Jordi does make it into the office after all. He went to the clinic but they told him to come back at 2.40pm, and he figured he may as well come in and do a bit of work. So I spend a bit of time going through priorities with him; basically, the priority is ‘fix the router issue’, which was a known problem before the bug hunt and is a show stopper as far as I am concerned.

Once I’ve gotten all the bugs into the system and labelled them so that it is easy for people to identify which ones relate to which bits of the system, there is a question of prioritisation. I reckon I can give a good go at this so I apply a priority to each of them before letting Will know that the backlog is ready for grooming if he has time to do that now. He does. It takes us about 30 minutes to go through and discuss each bug, pull them into a priority order and then work out which ones we’re committing to fix. All in all we pull around 18 bugs into the sprint commitment, leaving the rest on the backlog to be pulled from if we have time.

It’s 12.30pm by the time I can actually start fixing bugs. The first couple are relatively easy – I can fix them just by removing a whole load of unwanted code. Net negative check-ins are always pretty satisfying. It’s like the feeling of achievement you get after a particularly violent cleaning spree.

Next though I need to look at the viewing request endpoint and unpick the event sequence to identify why we’re getting duplicates in some cases and why we’re getting none at all in others. I had suspected the evening before that I was going to have to refactor this code and after about 20 minutes of debugging I’m convinced that that is the right step.

We have a controller method which is around 70 lines of code long, originally written by somebody no longer at the company and then added to by Adrian and myself as we each dodged the bullet of sorting it out, and because of it’s linear complexity it’s pushed us into bad practices elsewhere in the code base where we’re tried to replicate similar but not exactly the same behaviour.

We’ve slowly been trying to improve stuff like this; a couple of months ago Adrian and I sat down to discuss what design philosophy we wanted to apply to the codebase so that when we did refactor stuff like this we could do it in a consistent manner. After we settled on a domain approach one of the things Adrian suggested was a builder pattern, which allows you to write simple, fluent and easily readable code around building complex objects. Or, in other words, 70 lines of ‘if this then that’ becomes:

var viewing = _viewingBuilderFactory
                .NewViewing(request.UserInfoId, request.PropertyId)
                .WithRequestedTimes(timeSlots)
                .ForAllContactsAtBranch()
                .WithChatIfPossible()                                                
                .Build();

The various bits of logic from the controller get refactored into the builder, making it easier to commonise code with other endpoints which may need to build the viewing with a slightly different set of parameters, e.g:

_viewingBuilderFactory
                .NewViewing(userInfoId, propertyInfoId)
                .WithTimeAndPlace(startTime, location)
                .ForContact(contactId) 
                .WithChatIfPossible()
                .Build();

I’m not 100% happy with the BuilderFactory pattern – in order to manage dependency injection and have a single builder instance per viewing, I need some way of managing the more long-lived services that the builder calls into – but frankly today is not a day when I can spend a few hours playing with design patterns until I have something that is more aesthetically pleasing.

Once I’ve done an initial pass of my code I run my ideas past Adrian, partly to make sure he’s happy with them and partly because I always find it useful to bounce these things off somebody. I find that Adrian is quite good at pointing out holes in my thinking as I have a tendency under pressure to rush through something without necessarily exploring all of the angles. My first pass at the build code isn’t quite right, as it includes a number of calls that really should either be refactored into events or belong in a service model, and him pointing this out helps me to refine what I’ve done.

I bury myself in the rest of the refactoring job and try to be careful not to lose focus on the task in front of me. This code has been paining both Adrian and I for some time now and it’s really satisfying to finally have the chance to improve it; however I need to be careful not to let me remit slip to refactoring other bits of the code that aren’t relevant. I’ve done that before and not only does it take longer to do but it also massively increases the chances of introducing bugs. I now try and do refactoring in small steps, even if it means rewriting the same unit test several times, because small iterations are easier to manage and it’s much easier to identify and fix problems when they occur.

It takes me pretty much the whole afternoon to get to where I want to be. It’s 5pm before I know it. In the meantime, Jordi has gone back off to hospital (and is busy complaining about NHS wait times in Slack) and Laura has raced through a number of the easy bugs but is now back onto her nemesis; the badging issue which has been plaguing her since Monday evening. I’d like to be able to help but while my refactoring should have fixed a number of issues that came out of the bug hunt there is still plenty more for me to do; 6 or 7 more tickets that need fixing. Valerio however does have time to help so he brings his chair over and they start to pair on the problem.

That doesn’t solve the problem of the router bug. With Jordi out most of the day and unable to resolve it we need somebody to look at it fast. At the current rate, that somebody is going to be me; however Will suggests that Jack could look at it as he has some time. I often forget about Jack as an option, as we’ve been making a conscious effort to keep him out of our development process over the last two months to ensure that he has the time to focus on more high level stuff. However, he will occasionally step in and in this case he’s probably the best person to take a look at the issue.

Leaving Jack to it, I tidy up the remains of my refactoring and get the code pushed. Then I check the JIRA board to see where we are up to. We have 19 unstarted issues, 13 in progress, 12 in testing. That feels like too many. But of those 19, 4 are unrelated to our sprint work (they’re just there to make sure I nag the relevant person about their status every now and then), 3 are placeholders for documentation tasks, and another 3 I’m quite comfortable not completing. Around 6 of the remaining 9 are things that I can address now that I’ve finished my refactoring. I think if I just push through for a couple more hours I can break the back of what is left.

Which is exactly what I do. I don’t tend to work late nights, but I’ve been short on development time this week and it feels like a bit more effort here will facilitate us hitting our targets. It’s nearly 9pm by the time I leave; no football tonight and my wife is in Brazil, so no particular need to rush home for anything. At around 7.30pm I remember that some friends are out in Soho tonight and I originally said I wasn’t going but maybe I could catch them later; they miss my text messages though until I’m no the bus back home and by then I’m too tired to want to be sociable.

In the end, I get through another 6 tickets on the back of the refactor, and the feature is really starting to take shape. The full flow from suggest a property to request a viewing to book via the app is pretty much there, we just need to sort a few edge cases. At least, so I think.

 

Leave a Reply

Your email address will not be published. Required fields are marked *