A new project always starts with a spark, an idea.
In my case, we had an older service that was coming to its peak capacity and needed to be replaced with a more up-to-date and efficient service.
The service is responsible to keep our internal data in sync with our signalling control instance.
I was tasked with this particular project, and faced many challenges.
Starting out on this project, I did not have a full understanding of the service, and was working with an external API so far unknown to me.
Over the course of this project, I used a variety of skills and overcame the challenges to reach a successful conclusion.
In this blog post, I will share six pieces of advice that I learnt throughout this project, which might help you in the future to reach success!
Hint #1: Communicate
I started this project by looking to others and sharing in their expertise.
For example, we have Livio Righetti who is a senior developer and has worked at Comfone for a long time already. He has seen the dusk and dawn of other services and even the build-up of the predecessor service.
He was therefore able to give me an introduction to a similar, older service for the same mechanism that already existed. That helped me to get a grip on what is required or expected by me and to have some raw form of template for my work.
My first piece of advice is to seek help from others. Find people in your company who might have taken part in similar projects, and use their expertise as a template to avoid the same pain points. This will lead to a smoother running project.
Hint #2: Use old sources
The next step was to dive into the older sources, to see how the APIs that I needed to call on now for my intended new service were called in the past and how I could transfer that in a similar – but not the same – way to a Java service.
I found that by doing this, I could gain a better understanding of the whole project.
If you can get hold of some older repositories on the topic at hand, that is always helpful.
Hint #3: Analyse and split up tickets
As a software developer in an agile process, you often run into tickets with a very generic description like “Do A and then B” because sometimes you really just want to quickly sketch an idea.
The problem is that if you start working on that ticket without any analysis you discover that there might also be things C, D, and E to be done. Where you might have tried to save time by sketching an idea, you miss the details lurking beneath the surface of the basic description.
Therefore, my advice on that is: Analyse such tickets first and see what needs to be done and how long it might take. Of course, you are investing some more time for it, but it means that during the sprint planning, you can give clearer estimations which saves time in the long run.
You encounter immediate successes if one of the micro-tickets is finished.
Another benefit of this approach is that if you are working in sprints, it looks better on the burndown chart, too!
Hint #4: Respect and consult the 'gurus'
Imagine your company or your team as a friendly village. In every village there are wise people, just as in every company there are gurus.
These are people that are strong in their field. People like Laurent Freléchoux have seen everything in the industry, and know the trends, the dangers, the pitfalls.
I like to consult these gurus and make good use of their knowledge. They often have the keys to success, they can help you to learn more and, well… it’s free, right?
So if there’s something you are considering doing and you are not sure about it, then ask! It’s a win-win situation. The consulted person can prevent those errors happening at the base level. You have the opportunity to learn a lot and if you are lucky, it even shortcuts the time you spend implementing something.
And who knows, following this advice constantly might even transform you into one of the gurus yourself one day!
Hint #5: Unit tests are like free life insurance
In my opinion, a software project gains a lot from making use of unit tests as long as you don’t overshoot the target. Just doing tests so you can fulfill some abstract code coverage does not make sense.
I like to view unit tests as a type of life insurance.
This is because if I have critical business logic and something goes wrong on the source code, I want to be the first person to know. This prevents me from pushing the broken version of my software into production.
Hint #6: Ask the 'end customer'
What use is the worlds’ smartest or most beautiful car if you just bring it out to the consumer and the consumer makes a lemon face and says ‘meh?’
In the end, it’s the mistake many companies make. There is no point in developing a product just because it’s technically possible, especially if from a user perspective it is super-hard to use, not practical, or just a technical gimmick. It might be ‘there’, but it won’t be used.
Therefore, as soon as I had some first drafts on my software, I asked my colleague from the other department who was supposed to work with my software later to test it.
We had a great collaboration with each other, I tried to pull him into the development process early, showed him the steps I had already accomplished, and got immediate feedback. That allowed me to also already consider some of the decisions that are about to come up for my still-young software service during the implementation.
I really recommend involving the end user early in the process, as it will show up any bugs earlier and will ensure that the development goes in the right direction early, saving time and effort in the long run!
In conclusion...
This project gave me a way to apply all of the best practices and skills that I have developed over my years working in development.
The software is now being used by our internal teams, which ensures the continuous smooth running of our services for customers, without a break in any connectivity.
