Building software faster

In the past 20 years I continue to hear a common challenge with software engineering managers and executives – How to increase the speed in the way software is developed. This can be a cringe worthy question that elicits visions of bug-ridden releases as an end result. Let’s analyze this query and find out when and if it’s feasible to increment speed of software development.


A very simple and rudimentary question to ask one self before embarking on the quest to speed up development is: What’s the motive behind wanting to speed-up software development output? This can be simply attributed to tight deadlines and/or trying to beat the competition on a new feature, however, the question needs to reflect upon internal and external variables such as: mission, vision, capacity, resources, talent and budget.


A suggestion would be to engage a mentor or peer to provide feedback before throwing the idea to the team and having to face their backlash. Having a good soundboard can make a huge difference in making critical decisions that will affect human productivity. One can say this falls along the lines of a pragmatic approach as a problem solving framework. Validating the idea before bringing it to the team is critical, and so is any data that can verify the idea;  e.g,  the team is sluggish, chatters too much and is easily disrupted. This attributes leads to slow progress, delay backlogs and eventually a culture of slow production no matter how talented it is. Correcting a slow team will have a different strategy and approach than a team that is highly cohesive and meeting all their sprints on time.


If the objective is to build faster, it could turn into a double edge sword. Yes, you can probably push the team to build faster but at the risk of losing quality and unknowingly increase security risks. Theoretically it can be done if strategies that tackle the issue of quality and security are indirectly dealt with during the SDLC process. No matter how agile your organization is, pushing developers to hit the accelerator to churn-out code faster puts a tremendous amount of stress on them and as a team in general.

Historically certain sprints can seem to go faster depending on complexity of tasks and individual developer’s ability to code effectively, but it does not equate that that speed will be constant. It’s like in sports from running, cycling, racing etc., the team is aware of their limitations and according to those limitations exploit their strengths off of each other in order to achieve desired measurable goals. To understand the neurological process that helps us group a bunch of motor-actions into one group,  we have to delve into cognitive chunking. This reading is rather dry, but it does provide a greater picture on how humans can speed up tasks in general.

Ideally the focus is on the objective to achieve an application that will not only be contextually relevant but robust, secure and flexible enough to adapt to emerging technologies. Achieving this capability is far easier than trying to squeeze the life out of teams that are already working at optimal levels.


Best to drop the idea to a trusted peer or mentor before approaching the team and ruffling any feathers. The last thing you need is spending time quelling chaos and stroking ego’s in the process. If you know the team is slow and there’s tangible proof on root causes then applying agile practices and careful PMP policies can help get the focus back on track (basically you can tighten the reigns a bit without constricting or becoming a feudal lord).

Another option is to connect with local regional tech eco-systems that can help pick up the slack while your team focuses on accomplishing newer tasks. Proximity is key so both teams can interact, bond and meld processes that will effect rapid scalability.

If you are building a new product from scratch and want to scale up quickly, MEAN stack is a popular choice.