5 Ways to Speed Up Your Software Development Process
Table of Contents
We all constantly face the challenge of reducing time-to-market to ensure our company will not lose market share. This challenge has made time the most valuable resource for every software development team leader and manager. We all try to meet the crazy timelines for product releases and in order to meet this goal, we always aspire to speed up software development pace.
But how?
I’ll start by clarifying I’m discussing long-term speed (marathon run) and not short-term speed (sprint), as experience showed me repeatedly that one comes at the expense of the other. Since you cannot sprint run for a long period of time, by definition, and since we all strive to run long distance (years) with the highest possible pace – improving our long-term speed should be the goal.
And here are my five key tips for speeding up your software development processes:
1. Implement continuous integration (CI)
Agile is now the norm and almost all software development organizations have implemented agile to some extent. Agile comes in many forms, but the goal is always the same – incorporate iterations and feedback to the development process with continuous planning, continuous testing, continuous integration, and other methods of continuous evolution of both the project and the software. Most importantly, agile focuses on empowering your people to collaborate and make decisions together quickly and effectively. Isn’t that what we’re all aiming for?
When it comes to agile, I believe one the key process you can implement to step up your game is continuous integration (CI). I have witnessed firsthand the impact CI can have and I think every software development manager should try to justify why they shouldn’t implement it, rather than why they should.
CI is the practice of integrating code into a shared repository several times a day/week. Each check-in is then verified by an automated build, allowing teams to detect problems early. The idea is to build and integrate the software frequently, as frequent as every code check-in, to detect issues as early as possible. CI enables automated testing, decouple software builds from software deployments, and basically enable continuous deployment. Examples of CI platforms are Jenkins, Microsoft Visual Studio VSTS/TFS, Atlassian Bamboo, TeamCity and more.
2. Limit your work in progress (WIP)
I’m going to go ahead and assume you have already defined a clear and simple workflow. My advice regarding your workflow would be to manage and limit your work in progress (WIP) for each one of your steps. The reason is productivity goes down as multitasking goes up. There’s no tricks and tips to go around it. If you’re using a kanban board, you can specify the maximum number of tasks allowed on each column. Like in the below example:
Work in progress (WIP) limits determine the maximum (sometimes also the minimum) amount of work in each stage of your workflow. You will soon learn that not only limiting your WIP, would reduce the amount of work “nearly done”, but would also help you identify inefficiencies and bottlenecks in your pipeline.
3. Define clear development standards
Almost all software teams have their own informal best practices. You’d be surprised to see how much of those ‘unofficial rules’ will change or just plain disappear once you’ll start ‘formalizing’ it. These development standards can be derived by consensus or consulting experts, just as long as they are documented, agreed upon by all teams in your organization, and most importantly – continuously enforced to all levels.
Coding documentation and code review process should be emphasized in these standards. After all, a lack of documentation drastically reduces the accountability of authors and makes it difficult to track forward progress. We all know how frustrating and time-consuming it can be to start working on a codebase with diverse programming styles and formatting that looks like a quilt, not to mention the major improvement in quality and security you’ll experience.
4. Shift left through automation
The days of QA testers treated as second-class citizens has gone away and we are now all ‘testers’. We all understand that testing from day one not only helps us find issues early in the software development lifecycle (SDLC), but also changes our mindset. It focuses us on quality and security while developing and therefore improves the quality of our software products.
Shift left is the general approach of shifting all possible testing to the left (early in the SDLC) and make not only the testing but the progression of any build through the quality stages of our delivery pipeline automated and continuous.
There are many benefits to shifting left your testing with automated tools in terms of productivity and efficiency, but there’s also an added important benefit on your development cost. As detailed in the Ponemon institute research, fixing a defect earlier in the software development process takes significantly less time and resources and therefore substantially reduces the development costs:
5. 60 hour work week? That’s not the way
This might surprise you, as you were probably expecting me to discuss setting clear projects specs or making your progress visible to all key stakeholders in your organization. Don’t get me wrong – these are all valuable things that will drive your efficiency and therefore speed up your development pace, but I’d like to give you advice regarding your most valuable resource – your developers.
Software development is a creative process (I hope there’s no doubt about it), which demands focus and attention. An average developer, true for other professions as well, is focused and productive for the first 6-7 hours of his or her day. In terms of productivity, it will spike about an hour after the beginning of the day and will start trending down 3-4 hours later. After 10 hours of coding your developers can do more damage than good. In addition, why would you want to pay your developers to work when they are not productive as they were in the beginning of the day? If you are still not convinced check out this answer to a Quora question of ‘how can I make my developers work 60-80 hours a week?
