Improving software quality in every application lifecycle management (ALM) stage

Development lifecycles have become tremendously compressed, which means many stages of the application lifecycle management process are iterated over time and time again. Here are some lessons SFactory's Sorin Zaporojan learned throughout the ALM process.

Sorin Zaporojan, co-founder of SFactory, is about a year into a major entrepreneurial endeavor building a commercial mobile app from the ground up, which in today's accelerated development environment, is more than enough time go through every application lifecycle management (ALM) stage, from conceptualization to building, testing, deployment and maybe even decommissioning. It's also long enough to make plenty of mistakes, and a corresponding number of corrections as the software development team learn from their experiences. Ask any software architect about the choices they made five years ago, and they'll admit that those decisions impact what they are developing today. Sometimes, those choices make things easier, and sometimes they make the road a lot longer, but either way, successful organizations and individuals are willing to let past experience inform their choices going forward.

We still intend to support Apache Cordova, but we want to change the way we develop the backend. 

Sorin Zaporojan

Pay attention to the pain

What are the SFactory's teams thoughts after a year into development? Reworking the backend looks like it might become a priority. Apparently, designing the front end that the user sees is the easy part. Delivering low latency functionality through a carefully constructed backend is hard—and certain web frameworks can make it harder than it has to be.

"For the next application, we still intend to support Apache Cordova and come up with our own plugins. But we want to change the way we develop the backend. Right now our stack on the backend is Njinx and Django," said Zaporojan. "From there we go into python with MongoDB as the last layer. We are looking to change things on the backend heavily."

Don't be afraid to shake up the stack

Zaporojan also said that cloud based technology will play a starring role in upcoming development cycles. "Right now, we don't use as much as we should. That's where we want to make changes. We're going to stay with Njinx as the load balancer and front end. But we'll switch from Django to node.js because Django is threaded and we are looking for an event-based approach to deliver a faster, better experience. Right now, we have python classes under the Django components. We want to move these into tasks. We're going to run Celery on the backend and move from the entry point which is node.js to the task that will be run on Celery and go through RabbitMQ for messaging." 

Knowing what didn't work—and why—has provided invaluable insight. But it's Zaporojan's willingness to put that knowledge into action that will deliver value in the end.

What lessons have you learned throughout the ALM process? Let us know.

 

You can following Cameron McKenzie on Twitter: @potemcam
You can follow SFactory as well: @SFactory.ca

This was last published in March 2015

PRO+

Content

Find more PRO+ content and other member only offers, here.

Join the conversation

1 comment

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

I think that both of the lessons Zaporojan talks about could be mitigated by an honest and thorough team retrospective. I’ve seen many teams that have tried to make the development process leaner by cutting out the retrospective, but that never provides the opportunity to stop and see what is causing pain.  A retrospective also provides the opportunity for the team to stop and re-assess the quality of the product. Weinberg’s definition of quality as being value to someone, at some time, who matters implies that what is perceived as quality changes over time. A team retrospective is an excellent place for the team to examine whether or not what is valued has changed, and hence provides the opportunity to re-assess everything about the project, including the technology stack.
Cancel

-ADS BY GOOGLE

SearchCloudApplications

SearchSoftwareQuality

SearchFinancialApplications

SearchSAP

SearchManufacturingERP

DevOpsAgenda

Close