Software Engineering
...in literal terms encapsulates two aspects: the series of cryptic instructions in a language consisting of only 0's and 1's, written for a computing machine to execute: the 'software', and, a certain machine-wise elegant and correct 'way' in which it is written, as a consistent and coherent logical representation of the business domain being implemented: the 'engineering'. Sometimes it is not completely obvious that the second part entails a great deal of book-keeping with the help of multiple tools, interfaces, processes and documentation for engineers to be able to maintain their understanding of and agility at the project. Those projects that do not invest in this due diligence invariably end up becoming knowledge silos that are hard to penetrate by anyone outside the engineering team, like product-thinkers, clients, or even new engineers. And this is more often than not the primary reason for their maintenance to turn increasingly expensive that can further morph into what is typical labelled a 'management nightmare'.
At Avadhut
...we avoid this completely by investing due effort in keeping all our actions traceable. It helps with introducing and on-boarding new engineers to the project, communicate with our clients transparently, and in the event that the client should want to have someone else continue our work for them, they should have everything they will need to takeover.
For green-field projects
...we prefer to choose a general-purpose programming language with the best ecosystem-fit with respect to the nature of the project. We also take into consideration any special purpose subsystems that may need a domain-specific programming language. This may seem obvious, however, the emphasis is on not committing to an ecosystem or language merely because of immediate engineer-availability or other near-sighted benefits.
For evolved projects
...we carefully gather all the context: like verifying the existing problem, its scope, the properties and constraints that the solutions should adhere to, and everything else necessary and sufficient to propose and discuss the most frugal set of actions that would mitigate the problem. This could be to optimize parts of a project to meet scaling demands or QoS requirements, or to modernize an old code-base, or even to extend a project's capabilities with more features or enhancements.
Processes
Architecture
We use the C4 Model for the high-level and low-level design of systems. It is currently considered to be the best trade-off betwen design-effort and utility-gain. We also use BPMN and DMN for low-level clarity on business processes and decision mechanisms. We maintain ADRs with sufficient granularity for every project so that years later when a new engineer asks, "why was this particular thing done this way, when they could have done it this-other way", they have a place to look for a clearly explained rationale.
Development
All source-code is maintained in a version-control system such as Git , including tests, documentation and all related assets, like diagrams, that are a product of the architecture phase. We strive to make all source-code adhere to KISS, DRY, YAGNI, SoC, LoD, SOLID, CUPID, GRASP and other principles, that are already well-understood in the industry, as well as those that may emerge out of the nature of a specific project. These emergent principles are also kept well-documented in version-control. We follow domain- or type-driven development whenever applicable.
Testing
We believe that all testing should be automated. For most projects, testing them is at least as involved as implementing them. We consider unit, integration, end-to-end, and property-based testing staple, and ensure that every project has 100% test coverage. For those projects that need it, security testing will also be automated. We benefit most from automated testing when it is granularly runnable and part of the continuous integration pipeline.
Documentation
Our processes are geared such that through the architecture, development and testing phases, we have almost been preparing for this documentation phase. The diagrams and literature from the C4 , BPMN and DMN models, and the ADRs , as well as, the documentation accompying the source code, leave little to be covered in this phase, unless the project requires publishing . Here we simply add to the already produced documentation everything that is needed to complete it.
Auditing
This involves reading all of a project's source-code at a particular version, line-by-line, as well as scanning it with various tools. We uncover potential inefficiencies, accidental complexities, style and maintainability issues, as well as test and documentation coverage concerns. The end product is a comprehensive report with a list of items flagged critical, high, medium, low, or well-done, that reference specific parts of the source-code as a guidance for your engineering teams to improve upon, about your project.
Why hire us?
We are a group of passionate engineers who live and breathe software everyday - not just for putting food on our table, but also as an enjoyable hobby. We are enamoured by its science, and are delighted at every opportunity to apply that science. Spending most of our time developing our craft has made us adept at tackling technical problems and engineering challenges skillfully and efficiently. By hiring us, you provide us an opportunity to be excited, and in turn get a passionate team to work for you. It gives us great pleasure to see our world become more and more efficient with the help of computers.