Last week, I spent the majority of my time refactoring and restructuring KnowledgeNow with Martin’s help, either pair programming or checking in with him for what I should be changing and how, then going away and coming back when it’s done. Martin left for two weeks holiday at the beginning of this week, but I was under the impression last Friday that there really wasn’t much left to be done, and that I’d be able to polish it off nice and quickly all by myself. It turns out I was wrong, and one week later if feels like I’ve hardly dented my “polishing off” checklist. The missing tests turned out to be trickier to write than expected, and the extra features that needed adding were a lot more involved than I gave them credit for. The team were really supportive, and were happy to help me crack any particularly tough problems, but not having anybody else working full time on this project with me was a bigger shock than I was expecting. Suddenly I was captain of my own ship, and it was a lot more work than I realised. It’s been a really fun experience though, and the satisfaction of having my web application now report feedback back into service now, seeing those results in the ServiceNow web app itself, was fantastic after all those hours of work to make that happen.
Adding the “Was this helpful?” functionality involved adding methods to the ServiceNow api wrapper (originally written for Fast Track Tickets) that allow new items to be posted to the Knowledge Base Feedback table. This now means that users canĀ report whether or not they found an article helpful and are then presented with a comment box to add extra information if they wish to.
The rest of my week was spent cleaning this code up and adding tests, something that I always seem to underestimate in terms of the time and effort required. Crossing the 50% line for test code coverage shouldn’t have been a huge achievement but it felt like it. My plan for the coming week is to keep the momentum going with writing tests and to try to cover the entirety of the project as thoroughly as possible before refactoring again and requesting a code review from the team.
Estimating is one of the known challenges of software engineering. I am pretty sure that some where in the mythical man month Fred Brooks says take what ever the programmer tells you double it and add half. This is corroborated by Hofstadter’s Law: It always takes longer than you expect, even when you take into account Hofstadter’s Law.
Estimating in pairs helps a lot also planning poker is worth trying particularly when you first start making small estimates regularly.