The TRUTH Behind the Rapid Software Development

Speed is vitally important in modern software development, as the business generally wants a complete product with features delivered yesterday or (better yet) now.

Deadlines are often tight, and developers need to perform in environments where priorities shift. This is part of the job, and why developers are paid to solve problems at scale.

Sometimes the balance between speed and quality shifts too much towards speed and quality seems to get forgotten. When this happens there are consequences, and a messy reality prevails.

The Myth of Speed Without Consequences

Companies love to brag about how quickly they can roll out new features. It does sound great to ship updates weekly, but when that’s said like it’s a badge of honor something might just be going wrong.

The reality is that speed can come at the expense of thoughtful design, rigorous testing, and collaboration across teams. 

If developers work late nights to meet arbitrary deadlines in the short term the work might get done, but over the long term it isn’t sustainable as a lack of sleep impairs cognition. Eventually, those pushed features are riddled with bugs, shortcuts and cheats that make maintenance difficult. 

This tech debt must be eventually paid and can cause a cycle of rushed development as shoddy software is built upon shoddy software. As this progresses over time team morale is eroded and the customer experience is often impaired.

Companies like Revolut seem to feel that employing smart people means work can be completed quickly and to a high-quality standard, but their high turnover suggests that ex-employees simply vote with their feet. I have to say I hated it.

The Death of Thoughtfulness

Rapid development cycles are sold to us as “agility,” but they’re often just chaos wrapped in a buzzword. Features are added with minimal discussion about their long-term impact, and maintenance is something for the future that isn’t taken account of until it is too late. 

Developers work without design documents, so there is no record of scope creep. If there are QA teams their testing might not keep pace with development, meaning features can only be shipped after waiting for QA to “catch up”. Developers might push features without any thought to maintenance.

Somewhere along the line, we stopped asking, “Does this make sense?” and started agreeing to the question “Can we deliver it by Friday?”.

It’s a lack of foresight that hurts everyone in the production pipeline. Developers see codebases become sprawling messes, full of quick hacks and half-baked solutions that nobody has time to clean up. Users get a sub-par experience that may not even function in an acceptable form. The business will need to pick up the issue at some point, the question is when they will pay down that accumulated tech debt interest.

Rushed codebases in my experience become rather depressing. When I needed to work on three projects simultaneously at a code shop it was difficult to switch between them, meaning when I need to push a new feature I just did it anyway I could. No thought of the future (I didn’t have time), and the scariest thing is that people are still working on that codebase and probably they have to deal with my hacks. Sorry!

Teamwork in Crisis Mode

When speed is prioritized above all else, teamwork suffers. Collaboration becomes a luxury, and developers retreat into silos to churn out code as quickly as possible. There is no longer time for real code review and these degenerate into a quick look, a LGTM (Looks Good To Me) comment and a merge into the codebase. Stakeholders become desperate to hit deadlines and override concerns, meaning phrases like “We’ll fix it later” become heard all too often in Agile ceremonies (and the fixing of course never happens).

Maybe that is what happened in my current team where developers simply go along with everything that is asked of them. They don’t question decisions and seldom speak up at all. Bad times.

The User Pays the Price

In such environments delivering real value to users becomes secondary to delivering rushed features. It’s different making a good sprint demo compared to making good software. 

I’ve seen completed features where buttons don’t do what they’re supposed to, workflows break, and performance tanks. 

It’s users who feel the frustration first, leaving reviews and complaining though any support channels they can find. The work comes down the pipe to developers who need to scramble to fix issues that could have been avoided with more deliberate planning.

A Better Way Forward

If we’re serious about creating great software, we need to rethink how we define success. Instead of celebrating how fast we can ship, we should come up with a charter that prizes good software. Here are a set of guiding principles:

Quality over speed

Set realistic timelines and prioritize thorough testing.

Collaboration over silos

Foster communication across teams to avoid surprises and misalignment.

Thoughtfulness over chaos

Take the time to define problems clearly before rushing into solutions.

Sustainability over burnout

Protect your team from crunch time and support their ability to do great work.

Conclusion

Truth be told, I’m not against rapid software development. After working in an environment where we were unable to create a refined backlog (so no tickets “ready to go”) I’d appreciate a little more pace in my day-to-day software development.

There are even times when speed matters. Those emergency fixes need to get implemented, and that’s no bad thing.

The problem is when speed over consideration becomes default mode. Like anything taken to the extreme, it’s bad news for everyone involved (developers, stakeholders, users), and my problem is that this is a thing for too many tech companies. Musk isn’t alone in pushing software developers to go fast, now and forget the consequences. My question is, why can’t we afford to get things right?