We’re fans of processes. We believe we have good ones in place for projects and people. While hiring engineers, we look for only two things: ability and attitude. We don’t judge ability by a resume. We do it by asking the applicant to write small programs, using pen and paper. We judge attitude in an interview. We have senior intuitive officers who can do that. (Trouble is, we don’t have enough of them. We’re grooming them, though).

Project management is no different. Our processes are simple and straightforward. We have written-down coding standards which are used for source code control. We use a web-based issue tracking system for all tasks undertaken by all project team members. No developer is supposed to start any task without its issue being defined first. All new projects are designed such that their web UI is completely configurable without having to modify any code or recompile source files. Each developer does his own testing, and test scaffolding is developed and retained with the source repository. Some projects are using JUnit. All source is checked into a repository which is tied to the issue tracking system. CI/CD and automated testing is part of the standard process.


(The hammer, tongs and screwdrivers of our trade)


We live and breathe Redmine. All our projects use Redmine to create detailed tasks lists (burn-down charts, essentially) and then bunch them into sprints. A glance at the Redmine Roadmap for a project tells you the health of the entire project, plus status of the current sprints. We’ve used Jira for one or two projects where the client has insisted.


This repo system is the second half of the Deadly Duo, and works amazingly well with its counterpart, Redmine. All our code and system configuration files go into Git, and each developer commits his code once a day into Git with an update into Redmine pointing to the issue (Redmine-speak for task) he’s working on. A developer’s laptop can crash and we will be set back by just a few hours of work, thanks to Git. Who said Git is only for developing the Linux kernel?

VS Code and Eclipse

Once upon a time, when we were doing a lot of Java work, Eclipse was the favourite IDE for our developers, for some reason. Today, the preference seems to be moving slowly towards VS Code, on Linux. (All our developers use Linux laptops unless they are working on a dotNet system.) A recent poll conducted by a Linux distro showed that VS Code is the highest rated IDE on Linux today. Who would have thought Microsoft can reach pole position in the Linux world with their open source IDE?


The core of our CI/CD stack, and the secret sauce which allows us to maintain a degree of sanity to protect production systems from over-enthusiastic dev teams. The industry standard when it comes to automated build and deploy.


The first line of defence for code quality. We integrate this into our CI/CD stack and ask our dev teams to ensure that their is clean and wholesome, not just in their own eyes but in Sonarqube reports as well. The Sonarqube dashboard is a lovely at-a-glance report to let the project manager know what his team’s code quality is like.


(The real magic of “how”)

Developers, as a breed, hate processes. This is because they have seen too many processes which are just bureaucratic monstrosities imported from the manufacturing sector of the 20th century. We keep our processes light, more like group activities among a bunch of friends. Our flat culture helps.

Super quick mock UI

We started this practice almost a decade ago, and we can’t live without it now. When we get the spec for a new project, we first translate that into a full set of screens which the client can see on his browser or mobile device, so that he knows exactly what he’s going to get when the system is done. The guiding principle: no surprises.

Detailed design and WBS, where rubber meets road

The specification is converted by our architects and designers into a detailed written specification. Our design documentation can actually be read and understood by young developers — we write only what matters. Our Work Breakdown Structure becomes the burn-down chart for sprint based development after the design is done. If you can’t list each nut and bolt in detail, you can’t build it.

Sprint and exhale, sprint and exhale

We do our coding and testing in sprints, based on the Scrum methodology for fixed-spec projects. Each sprint is just 2-3 weeks, and the client gets to see something real at the end of every sprint. No proof of any pudding like the eating, we say. Clients agree. Develop in a brief bursts and course correct each time.

No-nonsense stand-up meetings

The daily stand-up meetings are our reality check for our project managers. Problems are often identified, but are identified really early and are fixed promptly, or escalated without delay. The sprint team keeps, well, sprinting ahead. Conquer the whole project, one day at a time.

Release management through Git

New releases of any system are moments of truth: all the pieces must fall into place just so. We use release tags in Git to track exactly what we are going to release in the next release, and in the rare instance that there is a snafu, we can roll back to any past release. A release is a very critical checkpoint; make it your friend.

Code review, where we take no prisoners

We have code reviews through automated tools (Sonarqube, remember?) and through peer review of code. Each team member spends an hour each day either having his own code reviewed by his colleagues or reviewing a buddy’s code. Works wonders to break silos within the team and spread the good word about best practices. Share your quality thoughts, let the whole team grow, on clean wholesome code.