project epilouge

It’s time to sum up my work for one of the biggest companies and employers in Northern Ireland.
As you may have read in my previous posts, I worked on a rather big project as the sole programmer. This way I had the chance to re-evaluate my knowledge in software engineering and (again) learn what’s important in a project like that.


Don’t be fooled by the numbers in the picture above, roughly half of the files belong to libraries I use, the rest is what I’ve written for my project. Sounds like a lot of work and functionality, right?
Well, it was a lot of work indeed but a lot of functionality? This is something that depends on your perspective and is probably something every developer, writing software that is more like a framework than an application, has to face.
That’s something that has to be taken care of before you start the project, i.e. making sure there will be a working use case to show what your software can do. I’ve been focusing on the software to be as flexible as possible to allow a company wide usage no matter how the data gets fed into the system, as long as it meets the requirements of my database model.
Having worked on a data consolidation project before, I knew that it’s the best thing to let people already involved in the data acquisition process do the data definition and formatting for you, otherwise you end up with doing data forensics instead of programming(I’ve spent over half a year working on a project and the result of it is my contribution in making the scientific publications/library of my employee in Germany available via the new web site which is a joint effort of a lot of people as well as en external agency developing the frontend).
Lessons I’ve learned, difficulties I’ve encountered:

• Starting a project without a detailed requirements specification is simply insane. Not having any functional requirements as a consequence leads to lots of code which is rewritten or simply never used in the end product. I know this sound obvious for every software engineer but the temptation of „trying something out“ is just too big sometimes. In the end you do not save any time by skipping a proper definition phase.
• Writing a framework, without taking care that the source data you need in order for your framework to display something actually exists or is available in a processable form, might lead to forgetting about the users who are supposed to use the system. Basically (again) something which seems fatal at the first glance but hoping (read: being naive) that the data will be somehow supplied without you leading the way and showing the access to the database model is outright careless. I basically omitted the principle of developing test cases and acquiring the resources I need to run them before even writing the first line of code.
• Having done lots of presentations in between the project development phase I lost lots of time for context switching. This means for instance: While developing the database model, quickly code another branch for your project that generates some GUI elements for the user to see and understand where the project is going to. Switching from working with a database to GUI design and back is something that slows down development progress a lot. It would have been a good thing to have someone to develop the presentation/milestone demo branches while continuing work on the main project trunk, especially because I was using a versioning system supporting exactly this kind of workflow.
• My boss here in Belfast quoted Voltaire once saying „The better is the enemy of the good.“ which pretty much described what I was doing. Instead of just being good enough and providing a user oriented prototype system I was aiming at properly developing every single aspect which lead to a prolonged development time of every single module. In the end, only what works and can be used, matters. So that’s where I could’ve excelled even more be making the behemoth of software I created more user accessible so you don’t need a computer science degree in order to get started.
• Switching to a new API in the middle of the development cycle might be something which is not that wise to do. I was lucky I got used to jQuery pretty fast so I still could benefit from the time saving effects while using its framework.

In the end I’m quite confident that even if my framework won’t be used, it gave enough insight to the problems still present and paved the ground for a proper approach in getting this thing finished as well as something to look back at and learn for future projects.
I am sure it would be beneficial if I could stay a bit longer in order to implement more user accessible interfaces as well as to participate in the full automation of the data injection process for the database model, but that’s what you have to learn to live with if you’re singlehandedly doing a project in just two months.

Another aspect I have to stress here for everybody who might want to complain that I have posted far too many articles about my travels and such, than things regarding my work. Well, guess what, I am working with confidential business data and I can only give you general insight into what I was doing but no specific examples because this almost always involves business intelligence of some kind.
It helped me to gain deeper insight into the structure of my company by „going native“ and travelling, using as many of Translink’s services as possible. I am sure my involvement with my work as well as my employer here in Northern Ireland was above average and I truly enjoyed it.
I would like to thank all my colleagues from Translink for helping me wherever possible and a special „Thank You!“ to: Seamus, Tommy, Paul and Steven