Five questions we ask ourselves in order to identify the right product and technology
As Neebal is expanding quite fast, we are looking to hire experienced laterals to lead our tech teams. One thing is quite clear to us, we don’t want to lose our culture with this rapid expansion. As a result we came up with a list of questions we were going to ask during interviews to identify cultural traits. One of them was “What technology will you choose for ‘X’ case study and why?”
This question helps us understand if the candidate can adapt into our ‘Be the Doctor’ methodology. It helps us learn whether one makes a decision based on their expertise or the product's needs. It’s not about the right answer, it’s whether one has the desire to learn and grow.
In this blog post, I am going to talk about five questions we ask ourselves while deciding the the product we want to build for our clients.
Whether it is a need for high performance or an unprecedented scale, we capture non-functional requirements that help us identify our list of suitable technology choices. We first start with the customer’s existing technology solution for re-usability and map with capability to deliver. This gives us a prioritized list of technology choices which becomes easier to take our architecture decisions.
This is where we measure the effort we have to put in, in terms of adopting ‘X’ technology and what value it will bring to the clients to their short term roadmap as well as long term vision. This is also helpful to capture investment required to build in-house capability or hire a consultant. We also look at affordability for the platform in terms of licensing, support plans, and team structure. We believe that a technology choice should help businesses directly or indirectly to increase the topline (revenue, userbase, touchpoints) or decrease in bottomline (support assistance, resource utilization, etc).
The ‘You Aren't Gonna Need It’ test helps us understand whether we really need to build a layered architecture or will a simple function suffice. To achieve this, we identify the value of each technology choice and identify where it falls on the MoSCoW scale. Identifying the technology capability / value between ‘Must Have’, ‘Should Have’, ‘Could Have’, ‘Would Have’ helped us immensely.
What you need > What you should > What you want
We make decisions on the basis of ‘Must Have’ & ‘Should Have’ and don’t build things that are not needed.
This is where we decide whether this technology is single use or if we can reuse it in the future. Also we ensure that we utilize the full capability of the technology instead of using only a part of it. For instance, we see some clients utilizing middleware tech as an extension to the product rather than using it to its full potential. This is something we educate clients about and suggest reusing existing technologies as far as possible if they are the right fit.
Supportability for a system plays a critical role in our decisions. We don’t use technology just because one of the architects wants it. It’s important for us to know if a technology is easy enough to be understandable and if we can build knowledge on top of it. We always ask ourselves how easily one can pick up if someone leaves the team. We have survived many waves of soda techs using this model.
Every year we invest in adopting 3 new technologies within Neebal. We do proof-of-concepts and run it internally on non-critical systems and adopt it across the team only when we are satisfied with our capabilities.
Last year we placed our bets on JHipster, Flutter in place of React native & Kubernetes. These not only helped us and our clients achieve increased quality but also decreased our time-to-market.
This year we are targeting adoption of technology choices for self-healing DevOps, left shift testing & codified architecture to deliver quality. I will discuss them in an upcoming blog.
Irshad Chohan is Neebal Technologies' Chief Technology Officer. As CTO, Irshad focuses on setting up and implementing technology practices and efficient processes for organizations and adopting new technologies while increasing optimization with re-usability and automation. Irshad believes in creating technology leaders within organizations. Reach out to Irshad at email@example.com
In large enterprises, business workflows often require distributed components for seamless scaling and maintenance. Hence it is essential to develop effective connectivity and communication between such elements. Event-driven architecture plays a...
What is serverless architecture?
AWS defines serverless architecture as “building and running applications without thinking about servers''. Developers can now build and deploy the6ir applications without thinking about the backend infrastructure....