Finally – it is done. The core ODR platform, as of Sunday 29th March, is more or less complete.

I had hoped to get to this point quite a while ago, initially by Friday 13th, before mid-project-demo week. I then postponed this to Tuesday 17th, which was the day of my demo. At this point I still needed to add mediation – and hoped to have that done by the end of the week (Friday 20th), then Sunday 22nd (which I still classed as “end of the week”), then middle of the week (Wednesday 25th), then end of the week. And here I am.

I’m surprised that it took so long to get to this point, and I’d like to briefly examine the reasons why, especially as I actually managed to negotiate some simpler requirements (removing formal resolution “offers”, etc) to help reach my deadlines.

It is partly down to my busy schedule: company work, company administration, family, friends. However, there must be more to it than that.

I believe that coding in a test-driven way has slowed me down – not cripplingly, but by a pretty significant margin. Having to write integration and unit tests, fix them when they break, wait several minutes for Travis to build my project and inform me when things have broken, having to refactor my unit tests when I refactor my codebase – these have all factored into a more drawn-out development process. As an estimate, I think I probably would have been at this same stage a week ago (22nd) had I not disciplined myself to write tests throughout.

Of course, there’s no way of knowing how much time I would have spent manually testing, and fixing complicated bugs that start at one point and proliferate throughout the system. It is very possible that, without tests, I’d be even further behind than I’d like to be! Regardless of time, I’m very, very happy to have this collection of tests that cover every aspect of my codebase. I can refactor hundreds of lines of code and automatically validate that everything still works. The development overhead on writing tests is easily worth it for the ability to code with no anxiety.

That aside, TDD isn’t the only culprit for a bloating deadline. The stakeholders added things to my initial requirements, such as a file upload facility, the ability to view user profiles, and so on. Occasionally I’ve also added my own self-imposed requirements, such as automated AWS deployment. Each requirement adds at least a day to the development phase.

Finally, it’s worth re-iterating that this is a pretty major project! In the past I’ve worked on small, self-contained features for the BBC, or personal web projects which are, again, quite small in scope. Developing a fully-functional, BDD-driven, enterprise-level piece of software as a single developer is hard. Perhaps I underestimated the difficulties of actually implementing the code, even with a pretty well thought-out up-front design.

I should keep in mind that what I have so far is an achievement to be proud of (this is echoed by the 91% I achieved in the mid-project demo). I didn’t meet my arbitrary deadline, but what I’ve built so far is a worthy major project in itself, even before introducing the other exciting components I hope to introduce. I must be code-complete by 25th April; it’s the only way I’ll have time to write a thorough enough final report. This gives me just under four weeks to accomplish as much as possible.

My wish list for the next four weeks

This is what I hope to accomplish, in rough priority order:

• A prototype of the maritime collision module, and, by implication, developing the underlying platform to provide hooks and be fully extensible, and the corresponding developer documentation. I think this part is the most important to achieve, as it is what will set my platform apart from the other (proprietary) ODR platforms that already exist. The AI logic in the module doesn’t even have to be very clever. What I’m hoping to provide is a “plausible promise” – something that gives a non-technical person a fair idea of what the system is capable of, and gets them excited!
• As part of this module development, I hope to develop a WordPress-inspired admin panel so that the SmartResolution administrator can create an admin account, log in to the system, and install/uninstall/activate/deactivate modules through an admin dashboard. What I hope will follow on from this is a SmartResolution Marketplace. The software will communicate with smartresolution.org and allow the admin to download and install modules from the marketplace, to the SmartResolution software, through the software itself. To begin with, the marketplace will have the maritime collision module and one or two simple test modules. Later on, this would contain both free and proprietary modules, and is ultimately where SmartResolution developers could make money.
• Tying up various functional loose-ends, including the ability to download a “dispute report” at the end of a dispute, to manually verify that the mediator did not break any confidentiality agreements in their discussions with the other agent. I also need to implement basic housekeeping stuff, like email validation, the ability to restart the mediation instigation process, and so on.
• The site could do with sexing up a bit. Early ideas:
  • JavaScript countdown timer on dispute dashboards, counting down each second to the start/end of a dispute.
  • Progress bar timeline on dispute dashboard, showing at what point in the dispute lifecycle mediation was proposed, dispute was resolved, etc, and giving an even more visual way of showing how much of the dispute lifecycle has elapsed.
  • Icons on the dispute list page, showing at-a-glance whether a dispute is open, closed or in mediation.
  • AJAX-loaded notifications, like on Facebook, and notifications that “go grey” rather than disappear entirely.
  • Paying attention to detail and deliberately making the site fully responsive.
• Then there are various developer-centric improvements, such as adding Javadoc-style comments where appropriate, creating and making publicly available various class diagrams, improving the back-end directory structure (as the number of models has grown substantially), setting up cronjobs to poll the server at set intervals, and so on. You might argue that these are more important than the front-end improvements outlined above, but even at my age I’m aware that a good-looking site builds trust and credibility. People won’t use a naff-looking site. They’d sooner have a visually appealing, parallax-scrolling site with little substance than a robust, backwards-compatible site that looks a little dated.

I’m particularly interested in the marketplace integration; my entrepreneurial eye has been very much caught by this. However, I committed to the maritime collision AI at the beginning of this project, and the modular platform is what makes my software stand out from the crowd, so I’d be mad to overlook that.

This week I’m hoping to do 2-3 days of BBC work, and next week I’m in Durham with my girlfriend for Easter, so my not-quite-four-weeks remainder of coding time is already looking strained. I will try my very best.