What goes Behind the Scenes – The Fedena Engineering Process

When it comes to process, as in most of the organizations, there happens to be a time of complete absence, experimentation and trial and errors. So was once Foradian. While developing Fedena, we had a streak when we were trying out processes which we saw in text books or internet or sometimes from past organizations. Waterfall, Y model, XP, Agile, requirement analysis, design, development, testing, releases and more, all of these and many other priorities kept us in the queue for a better plan. And in the end, like it’s the time which defines anything, we are at a point where our engineering team has structured a process, which we think is the best, at least at the moment.

History: Agile, the Holy Grail

We were advocates of Agile Methodology(we still are). You might be knowing Fedena is built on Ruby on Rails. Rails people like most other modern programmers, speaks agile, and it was considered as the remedy to their questions.  And that trend at the time lead us to go agile (or was it a conversation between our CEO and CTO where one of them said, ‘lets  go agile!’). At that time Fedena were already in the market and in its infancy. The development comprised of customization, and feature enhancements. And yes, its true that the Fedena engineering team had this prestigious privilege  on deciding what new features has to be built, when to build it and when to ship it (we share it, to be honest). So the process is iterative, we define the requirement X, we designed and developed X in parallel those days, then we test X and release X. If X had some trouble after getting into clients, we iterated the process. And yes we did pair programming, on each module there will be a pair of developers. It went on for long, and the result was fruitful, Fedena grew.

Evolution is true

So Fedena grew, our client base changed. In past there came a time when we had to customize the base application, for many of larger customers. So when it became a pain to manage those intermittent changes, developers taking time to catch on what a particular custom Fedena undergo in previous release and so, we evolved the then followed style. We started keeping a pair per customer, which helped us again in faster delivery, and meanwhile a pair waited for changes from tasks, they where given tasks, which enhanced the core Fedena. At the time we had some 4 pairs. So pair working on a particular customer won’t have to struggle for keeping with the changes.

As of today, Fedena had underwent changes in its business and technical aspects. We now have plugin systems with larger number of features, multi-school environment and even have a SaaS application, more supported languages etc. Engineering team grew bigger. The frequency of change is faster, and these changes has to reach large base of customers across the world. So whenever we thought something is slowing down the whole process, we find that hole and fix it. After so many trial and error process, necessities and discoveries, we came to a more structured process which we follow now.

The Team

The Fedena core engineering team consist of the CTO at its head, then a development team, testing team, support team and R&D. Players of these teams at times play double roles. Development team is even divided to two, the Enhancement team and the Quickie team. The Enhancement team deals with the new features enhancements to existing features, new plugins etc. Whereas the Quickie team bug fixes and quick small features. And its not necessary that everyone stays at the position.

The Process

Mostly the work done on Fedena now are the feature enhancements, bug fixes, app refactors, and internal tools. Each one of these will be a consider as a module unit. So about the process. As I said before, the engineering team has the luxury to take decisions on what has to shipped and when, unless there are unfavorable cases. So the feature enhancement requests can come from three sources, the support, the sales and the R&D, and again there will be other stuffs like I said before. And the requests are picked out, then its planned accordingly, analyzed, designed, developed, tested and locked for release. I will break down those shortly.

Analysis

The source module will be mostly a simple write up, which gives a creamy overview to what has to be done. The write up is handed to the developer pair. They analyze the write up and based on the analysis, submits a requirement document. Once the document gets approved it moves to next phase. This usually is short but iterating process.

Design

This is the most important phase, involving developers, UX team, managers, sometimes even CTO (most of the time) and CEO comes into scene. In this phase the developer breakdowns the requirement and creates user stories out of it. If UI is needed, the docs are shared with UX team. The technical specs are then planned along with this. In between we find anomalies, the we go back to phase 1 and repeat. The final result will be docs defining the user stories, UX/UI design and technical specs.

Development

Once we feel the design phase is over (because it doesn’t end like that, iterates mostly) we proceed to the development. Development as I said earlier is paired, but contrast to the usual pair programming, here one developer will be full time and the other one will be assisting with everything. This helps us in increased delivery in shorter time, as the one assisting will be developing fulltime in some other module. Above that it also helps us to overcomes many of the pair programming nightmares, still retaining the best of it.

So it was about the people involved. We had problems in the past. We develop test and deploy, only then we know that we missed some things, it might be some language keys, or an RTL style, may be a db index or a precision of a column. It happened many times until our CTO came with this miracle recipe of development. It is a checklist that a developer must check before its forwarded for testing. This is now working great. Also at times we feel there is something wrong with the design, then we iterates, go to the requirement which lead to the design, fix it if needed, then fix the design, and come back and fix it in code.

UI/UX Report

The UX person checks the module, and comes up with a report, on whether the design they made is what it appears. Any issues are reported and redone until the team approves it. This is a mandatory process if module contains UI.

Testing

Module testing proceeds in two steps. In first step the test is planned. This step is done along side with the development and after the design. Testing is done by single person. It is in the second step the actual testing occurs. During testing the whole team designers, developers and testers come the scene. The bugs are fixed real time, if parts does not keep up with design again that is raised and fixed. And again if they find problems in design itself as I said, the circle happens again. For a module to go for release, the OK from tester is the first thing.

Code Review

This is one place the second of the pair comes in scene. The code review begins with development but not frequent. And once the development is said complete, the complete code review report is being done. The developer will work towards the point when the reviewer thinks the code is fine.

Release

The left part is the release. We have control over what to be released. Based on that we might stage or lock some modules and release some. These are based on priorities most of the time. And as said before critical issues, which has higher priorities, are released through quick releases. Fedena is installed over multiple client servers, as well as our own servers. So releasing to this huge base of instances itself used to be a very complex and time consuming task. And that lead us to a new invention, an internal tool what we call as Continuous Delivery System. It handles the clients, their business plans, the modules they own and according to theses information, releases to the large base of client installations are done through this system. The system itself is little complex and is piloting internally, so details another time.

So this is the process we follow at the moment. The fact is, there are no perfect process. At the moment this workflow is working very well for Fedena. We still have other plans of additions and changes, one of which being the scrum.  And as I said making a process itself is an evolutionary process. We don’t know which is good until we experiment it and what we use is subjected to constant change. So what we follow is a hybrid of many of models we knew, or we can call it the Fedena Process.

This article is written by:

Ismathullah Aman

Coding makes most his life and when he is not busy with coding and decoding, Ismathullah Aman likes training his super human self and much reading! For Aman, “Life is either a daring adventure or nothing”

Share your comments in the comment section below. For more information on Fedena click the contact button below.