Emric – product company
There is a quite common question when it comes to choosing job these days: Is it better to work in company where there are smaller projects, constant changes, possibility of different technologies, or to be a part of big project with a lot of implemented processes, standard way of working, team that cooperate together for a couple of years?
In my not so long but various carrier, I had a chance to work in both types of companies. Even though I thought that often changes are bigger challenge for me and that I can learn more in that way of working, now I cannot imagine to work in any other way but on bigger project, with well-known team, and many implemented processes that makes our development easier, safer and faster.
Developing and handling large solution is enormous challenge. We have to be very careful when choosing way of doing something, because any development is much harder and has much bigger impact on entire solution than on any smaller solution. Also if we want to change or improve any part there are a lot of investigations, decisions and reviews that we have to do first.
First big decision that we had to make is how we are going to handle manipulation with database. Use existing framework or create new one? In less complex projects people are daring to try something new, to experiment with some popular but not yet properly tested framework, to try new technologies which can be good practice and self-improvement, but there is one big problem that many developers thirsty for new technologies are missing: there is no already developed framework that can fulfill all of project needs. Also technology is changing so fast, that something that was popular 2 years ago, now is completely obsolete and avoidable because it has shown as not such good solution. That is why we choose to develop our own way of communication with database. Using runtime compiling we got amazing results in speed, memory and CPU usage.
The very important part of every development is testing. Many companies take tests as less important process, and in IT we often use joke: “User is the best tester”. But that is not luxury that we can allow our self on our project. As I said, every change is a risk, and since project exist for more than 20 years, there is always parts to be improved, things to be changed, we MUST have very strict testing routines.
Base part of that routine is continues delivery. We have all code and database changes checked in during the day, build and delivered to test for testers and BAs. This allows them to have development changes every day so they can check correction on bugs that they reported very fast and easy, and also communicate with developer on daily bases. This also allow developer not to worry about his/her changes getting to tester and being reviewed as soon as possible.
Manual tester are one way of testing project, but we can’t imagine our work without automatic tests. With more than 250 automated tests, we can be sure on daily frequency that none of our new code or changes will affect any of the current functionality.
Delivering massive and complex project to production is always a challenge, but also a risk. We cannot make corrections as fast as we want, and every change in production has its own life, that can take up to a couple of days. That’s why we must have carefully created and followed routines in every release. The whole process from customer requirement to delivery has steps that are followed by every member of the team, and supervised by Project Manager. After customer give us requirement, Business analyst writes specification that is send to customer for an approval. Specification is something that is main guide for developer. During the development test team is creating automated test that will be used in every release, as a guarantee that new functionality will work the same until the next change. After development is done we deliver code for internal testing that is going to be done by testers and BAs. Next phase is stabilization. During that time customer is testing all changes that we have made and we call that phase UAT – user acceptance test. During that phase development is forbidden, we are only focused on already developed functionalities and bringing then to perfection. When UAT is done there comes the most challenging part – production. Delivery its self is very complex routine in IT, and we made all effort to make it as automatic as we can. By running build script, we are creating versioned dlls that will be delivered. Since we are delivering database also we have to compare schemes and data, in order to be sure what we are delivering and how that will affect current database state. Final part of delivery are database scripts. We are using standard format of writing scripts, to be sure that all of them can be delivered to any database without errors. Since we have a lot of customer and their request, but also some of product changes and improvement, we must divide scripts per customer, and of course handle product scripts implementable to every customer.
After delivery to production is done and smoke test has passed, we go into post go live process. That’s the time when support and development team are working together on common goal: make customer satisfied with new solution. That is also time where support team is getting familiar with all new features and slowly taking control over project from development team. Post go live period depends on number and size of changes. When we have pretty much stable version, release is done, and we can start all over, from specification to another post go live period.
I mentioned processes, but how to talk about processes in IT without scrum. Since we are handling teams that cooperate between Belgrade and Stockholm, scrum is something that keeps us together every day and make our communication as easy as we are all here. The most fun is review of every sprint, were we are always trying to be better, give some new ideas, and look back at what we have done. And it is a great feeling to see that we are not just planning, we are actually making our plans come true.
We have a lot of clients, and as we all know every client is specific with their demands. It is hard to handle all customer needs, and on the other hand have stable and recognizable product. We manage this with Modular architecture. Every user request is a new and independent module. In that way we have very flexible and easy to implement way to fulfill all customer demands, but still have our base product.
Every release is new opportunity to learn and improve not only software but also our knowledge. We have so many processes designed to make our work safe and quality, but there is also always a challenge to make processes more efficient and adjust them to new release. We are always reviewing our work and making effort to grown even more. Working with familiar teams, with colleages that understand each other and way of working is something that make our job interesting and give us a lot of satisfaction. When you are able to focus on your work only and create something useful, when everyone know their position and responsibilities, that makes working in EMRIC the best decision I have ever made. I have tasted the dark side, and I am never going back. J