The topic of building software was always an intricate one – way before disruptions induced by COVID-19 set in. From keeping all stakeholders happy, to ensuring security remained tight, much needs to be considered in order to call success to a piece of software. However, we have to accept the fact that lockdowns and a subsequent increase in dependency towards digital products have turned the tables for many technological nuances – software development included.
It was at the startup level that most of the magic happened; entrepreneurs shaking hands with developers to create a one-of-a-kind product that will redefine the way users perceive and engage with a particular service. But then there were also the challengers – the ones that aimed to disrupt the status quo with unique solutions that would give users speed, ease, value and everything else in between. Either way, there was always one thing in common between all these differing use cases – the drive to offer a high-value software product.
So what changed in the wake of COVID-19? While prior software objectives focused on creating brand new experiences, the pandemic has ushered the concept of business continuity. In other words, ensuring work carries on as normal, and focusing on keeping the bare essentials up and running – before anything extra can be done. This includes remote collaboration tools (such as video conferencing or document sharing) or other cloud-based services (such as storage and databases). This is all what the first couple of months following the lockdown were all about. How about right now, though? Are things starting to shift back to normal?
The answer is yes and no; with complete normalcy yet to be achieved in the wake of this pandemic, our technology demands are still here, but with significant changes. While business owners are gradually bouncing back to build their ideas into reality, it is factoring in the many variables that the virus has created. From maintaining social distance to cashless payments, even the most ingenious strategies are now being developed with a twist.
While many of us may be aware of the software development lifecycle at its base level, it’s not a bad idea to revisit its many rules once again. Yes, the same rules apply when it comes to building the right applications for our businesses, but this drastic change in the world’s economic climate presents caveats to this foundation. Add to this a number of other factors which can enhance the otherwise basic foundation that we call the software development lifecycle – and we have a strategy that is poised to deliver results even in the wake of challenges such as the one we are in right now.
As with any project, the building of any software product also begins with an initial brainstorm session or two. The main goal is to decide what the best course of action is to problems that have been brought to light. Gathering the right team members for this purpose (both from within the agency that will develop the software, as well as stakeholders from the client organization) will help in inviting multiple perspectives. Thereafter, the technology agency will then have sufficient information to understand what the underlying problems truly are, and devise solutions accordingly through the right software product.
Some key questions that can be asked in due course of discussion may include but aren’t limited to:
These questions can be great starting points to help team members articulate what problems they face currently, so that your technology agency can get a good gist of what’s wrong – and what’s needed in order to solve it.
Once your team is familiar with the problem at hand, it is now time to suggest viable solutions. Many options may present themselves, but it is necessary to shortlist these to only a few, and finally to one. Perhaps multiple solutions can be tied together to deliver a multi-faceted solution, but that depends on the problem at hand, as well as the resources available to make it possible. One important factor to consider is whether the suggested solution is feasible; is it worth the initial cost, and will it incur good return on investment in the long-term? If increasing sales is one of the main objectives from the application being developed, will this be attainable? If so, can it be quantified?
Mulling over these questions with the right team members is important to ascertain how a steady ROI can be obtained from an all-new software product. This can then lead to creating a detailed brief, which can then be passed to design and development teams for building comprehensive software architecture.
At this point, the nature of the application that needs to be developed has been confirmed with all members of the team. The design team is also well versed with what is required, and it is now time to create mockups of what the application will look like. The aesthetics of the software product need to be designed with many factors in mind, particularly the fact that it needs to be functional, in addition to being easy on the eye. UI/UX once again matters on both the front and back-end, and low fidelity mockups may run many drafts until the final design is approved by the entire team. Although a given in today’s multi-device technology age, responsiveness is also an important factor, making it a prerequisite in any design endeavor – even the smallest ones.
After designs are drafted and approved, it’s time to create a workable software product – through coding. This is the most time-consuming phase of the whole lifecycle by far, and for good reason. Codes need to ensure that the product functions through and through, and is also self-sufficient to accommodate advancements such as AI and machine learning. Conventionally, most codes were custom-made from scratch. But it’s at this point that such a tedious task can be circumvented, through nuances such as microservices architecture. While this helps in easily and quickly building an application, it also makes bug-fixing easy too, since only the affected part can be replaced while the rest functions as normal. This isn’t possible in a custom coded interface, as codes are deeply interlinked and a malfunction in one area can severely cripple all other areas too.
Software development in Sri Lanka is mostly Agile, and there’s a good bunch of reasons for that. Allowing flexibility in timelines and in the interest of building a truly viable product, an Agile development methodology provides space for updates well after the initial planning phase is over. Add to that bite-sized tasks and goals, and you have a working product that is ready well before one that is made based on the conventional waterfall method. Therefore unlike before, the development stage, although the longest and most complicated, is also versatile.
Once the application has been built, it’s time for testing. After the quality assurance team checks for bugs, it is ready to be released to the main users of the application. This can include employees or customers. While both can deliver feedback depending on ease of use and navigation, releasing a first-time software application out to your target market can seem like a rather ominous task. At this point, it is highly recommended to release an MVP (Minimum Viable Product) which has been designed to only offer the bare minimum, as its name suggests. Since it’s a working product, gradual feedback from the masses can then be used to layer on more features and functionalities, thereby making the product more intricate, but more importantly, only including items that are absolutely necessary.
This alleviates the need for building a product with features that may never be used, since one-on-one feedback will ensure only the very needful will go into subsequent versions of the application. Although the aspect of an MVP doesn’t directly relate to the testing phase of software development per se, it can still go hand-in-hand with user feedback, which can then follow with improvements that your target market can truly resonate to.
Once testing is concluded, releasing your software product to the masses is the next step. Depending on the nature of your application, deployment strategies will vary. For example, custom-developed ERP systems need to fulfil comprehensive data migration, before the software itself is put to use. If not, the entire system can fail. Implementation can also happen wholly or partially, with many companies opting for partial implementations since that may put less shock on employees who will be using the system. Again, implementation also closely ties in with the concept of MVPs, and how a basic software product isn’t just easy to implement, but is also easy to troubleshoot lest something happens.
Ultimately, you want to make sure that what you are releasing (whether it’s to your employees or customers) is something that is well received and most importantly, useful for those who use it. The right implementation strategy should be able to divulge the viability of your new system, but it should also be capable enough to administer patches to any bugs that are revealed in due course.
Now that your system is up and running, what do you do? If your brand new software has been well received by the masses and is contributing to the business objectives you had in mind from the very beginning, that’s a massive milestone achieved. But in order to keep the mill running, it has to be monitored and updated regularly. For one, security is a high-profile issue with digital products and services these days. You need to make sure that your application, as well as the sensitive customer data that it collects is stored safely. Cyber breaches have become all the more common as most depend on the digital medium for their day to day lives, and you want to give your customers the assurance that their data and transactions are 100% safe with you.
A DevOps cycle comes in handy here, as this collaboration between software development and IT is ideal to maintain optimum functionality and security at the same time. As soon as there is the opportunity to enhance and upgrade, a stringent DevOps cycle can bring the right people together in order to move an idea from planning to production fast enough. This way, your software can be improved in record time, without having to depend on old-school management and approval methods in order to deliver better.
The software development lifecycle was always a topic of interest among tech-savvy individuals. But now, it has become even more so, thanks to the pandemic. COVID-19 and its lockdowns have introduced a host of new variables to the applications that are being developed right during this minute, making the aspect of software development more complex than it already used to be. The basics still remain – from planning to deployment, the foundation that has been followed by both small and big projects alike is here to stay, but with some changes here and there.
For one, advancements such as microservices architecture have increasingly simplified the manner in which applications are developed and run. This not only makes it faster to release software, but also easier to troubleshoot in case one of the components fall into disrepair. Adding to this a flexible Agile project management methodology can further streamline operations, as smaller goals can be achieved with workable applications and big results. On the maintenance side post deployment, a strong DevOps cycle is also useful to curb bugs and ensure the very latest of improvements within your application at all times.