By 
Speed, long hours, and mistakes through mental fatigue can each pose new difficulties for software development managers looking to creating top-tier performance. Rushing, losing critical thinking, and skipping important planning stages all play a part in widening gaps between intention and outcome.
In this article, we look at software development done at speed. Does it work? What are the pitfalls? How can speed demons balance velocity with quality results? Let’s find out now.
Don’t Confuse Speed with Progress
While speed is important in software development, as the people at Wilfrid Laurier cover in detail, going too fast can come with a heavy price.
A programmer being constantly rushed means they’re sprinting from one point to another without being able to take a breath. When they’re having to do this too many times in succession, they’re likely to burn out relatively quickly. This leads to higher staff turnover and instability in the core team because software developers don’t stick around for more than a year or two due to the strain of the job.
In that sense, trying to go too quickly creates undue stress on everyone involved. Whilst a start-up may get away with it in the short-term in a major push to get version 1.0 of the software or app launched to the public, it’s unsustainable.
Using Agile Development for Good
Agile development practices have much to recommend them in the software development process.
The basic idea is to break up software development into distinctive stages. This avoids the sense of burnout because it’s not one continual programming or design session.
Agile 101
There are stages for the pure development cycle but also ones to review what’s been produced, receive feedback, and make modifications based on that process.
When the software is being finalized for release, the work is then reviewed to determine if it’s ready or not. In the case of new features or capabilities added to an existing software application, these can be developed, tested, and then released in a subsequent version.
Rinse and Repeat
Agile development cycles repeat over and over. This avoids getting stuck on developing a series of major feature upgrades and not exiting the cycle for too many months. Instead, these are broken down into different components of it to bring them to fruition sooner.
Continuous Testing is Necessary
With software development companies that have one or more teams creating new features, it’s necessary to test the software for bugs.
Software Bugs Originate in Different Places
These bugs come in the form of things going wrong. These can be older features that no longer work when they did in the previous version before the new features were included. It can also, more predictably, be software bugs in the new feature implementation too.
While every team should ensure that new features are fully tested before putting them forward for release, sometimes uncommon, irregular bugs get spotted in the wild later too. Therefore, continuous testing is required to locate these and ensure they get worked on to resolve them.
Faster Development Speed = More Bugs to Discover
In almost every situation in life, when going faster, there’s added risk. With software development, unanticipated problems can arise because an inadequate amount of time was included to consider all the likely ramifications of implementing a change too quickly. This inevitably leads to much finger points to assign blame after the fact.
To avoid a negative scenario, with faster speed must come more thorough testing to find those obvious mistakes that were borne out of forcing developers to code too quickly.
Team Sizes Must Be Artificially Smaller
To deliver speed increases on the development side, the team must not get bogged down due to the growth in its overall size.
The difficulty in managing scores of people, overly long team meetings, and Slack sessions with too many employees in them grinds everything to a halt.
Smaller teams allow for greater creativity. However, to develop quickly, the team must be defended from distractions, lost time, and other potential impediments to their progress. The team manager needs to actively shield them from other teams and departments adding to their mental overhead.
Just like trying to walk through mud, sloshing around in it will only slow you down. The team manager must clear the path and continue to do so to ensure rapid development.
Quality Developers Must Toe the Line
The smaller the team, the more necessary it becomes for everyone to complete their assigned work in the manner expected.
When there’s someone who likes to do things their way and won’t stick to the development guides, then that’s a major problem. It will cause lost time because they didn’t do what was needed, and perhaps cause extra time added to deliver a working solution.
How does this manifest itself?
- Adding extra features not previously approved
- Overly complicating the approved features adding additional development time
- Redesigning when it wasn’t necessary
- Retooling the codebase to get a minor incremental speed improvement in software performance
- Failing to code quickly enough
It doesn’t matter how uniquely talented a programmer, developer or designer is, as part of the team, they’re relied upon to deliver what was asked for. They may be a bright shining star, but they’re equally likely to reduce the speed of progress.
Fast, Fast, Slow Approach
Software development needs to be on a fast, fast, slow approach. It cannot always be done at high speed without slowing down to check what’s being done and if it’s right.
A balance must be found to ensure that development teams do not burn out in the process of pursuing rapid development results. While Agile and other development frameworks perform well for people who use them, managers must allow for the kind of creative thinking, analytical thinking, and problem-solving necessary, which typically doesn’t work well with time limitations.
Fast software development is indeed possible. However, don’t fail to see the wood for the trees when doing so. Quality development must be done at a sensible speed to avoid creating endlessly buggy software that end-users bitterly complain about.
Comments