System Check! FPGAs offer flexibility and performance, but for many engineers, they can still come with a steep learning curve. Are you comfortable working with FPGAs? What keeps you from using them more often?
System Check! Field-programmable gate arrays (FPGA) offer flexibility and performance, but for many engineers, they can still come with a steep learning curve. Are you comfortable working with FPGAs? What keeps you from using them more often?
We recently asked our community members about the “move fast and break things” mindset and what it means for real-world engineering. Let’s take a look at the results.
Results: Move fast and break things?
The results suggest that our community members take a nuanced view of the “move fast and break things” mentality. Around 20% said it encourages dangerous shortcuts, while another 20% felt that speed can sometimes justify taking risks. The largest group, about 33%, said it depends on the industry, while roughly 28% rejected the premise altogether, arguing that experimentation requires failure. In other words, most respondents were unwilling to characterize moving fast as inherently problematic.
That flexibility largely disappears, however, when engineers are working against tight deadlines. About half of respondents said engineers should maintain a balance between speed and quality, while about 44% put testing and reliability first. Few prioritized speed to market or cost and efficiency. Even under deadline pressure, respondents appear reluctant to sacrifice engineering quality just to deliver results faster.
The strongest consensus emerged when readers were asked about the consequences of moving too fast. Just over half identified safety or reliability failures as the biggest risk, followed by poor testing and validation at roughly 39%. Technical debt and inadequate documentation attracted only a small portion of responses.
So, what can we conclude? Speed itself isn't necessarily the problem. Engineers appear comfortable with experimentation, iteration, and even failure, but not when speed compromises testing, reliability, or safety. It seems most wan to “move fast, but validate what gets build.”
Discussion (0 comments)