I have a confession to make. I'm not an engineer. Something to do with my school being accredited by the French engineering guild only after graduation. Not being a classically-trained engineer probably affected how I see software development and my reckless way of building digital products. But maybe it's also because I don't think software development should still be a branch of engineering.
Engineering is using scientific principles to build engines, machines and structures. Engineers, whether they're designing the engine of an airliner, a sophisticated machine tool, or a bridge, must strive for perfection; a single error can carry far-reaching and sometimes catastrophic consequences. Even in a best-case scenario, the repercussions of a blunder can be financially draining: faulty products often need to be recalled and mended, a process that requires significant time and capital. Not to mention the potential cost of redesigning the whole system, plummeting the project's margin. That's why engineers are trained and use methodologies to avoid as many mistakes as possible before they release their products. In classical engineering, the cost of mistakes is very high.
Software development, in its infancy, obeyed the same physical principles. It was very costly to build, run and maintain software. Developers were scarce, programming took time, and any necessary updates required a physical maintenance operation on-premise. At the time, the cost of mistakes in software development was also high. But software has changed. It's much faster to build and release software, and even if there are any system bugs, software developers can update their product in milliseconds without moving from their chairs, thanks to the Internet. Because of these fundamental changes in how we build and update software, the cost of mistakes in software development has become much lower.
Why do we keep using project management and quality assurance methodologies inherited from classical engineering if this is the case? What if we only used a corrective mindset instead of building software with a preemptive mindset? In the software development landscape, it is conceivable that we might adopt an approach where we prioritise error correction over error prevention, building software with a focus on adaptability and improvement rather than striving for initial perfection. This concept, often called the 'fail fast' approach, is grounded in rapidly prototyping and implementing software solutions, understanding that there will likely be bugs or inefficiencies, and then actively seeking and rectifying these issues as they arise. With such an approach, software developers can have a much faster development cycle without being hampered by the pressures and constraints of preemptive error avoidance. Moreover, it encourages a continuous learning and improvement cycle, where mistakes are seen as opportunities for enhancement rather than roadblocks.
OK. I know what you're thinking. When developers go too fast during the initial development stages, they overlook or dismiss problems that might be difficult and time-consuming to rectify. They don't design their code well. They don't comment. It's almost impossible to maintain this code and build new features on top of it. Oh, and I'm sure you're also thinking about the mob of angry users who would complain to, even trash, developers until they altogether abandon the product. And you would be right. But is it always really that bad?
First of all, fast doesn't mean stupid. A well-structured, fast-paced development process can yield as maintainable software, if not more so, than that produced through traditional methods. The key lies in following best practices such as modular design, proper documentation, and comprehensive version control, which can facilitate easier identification and correction of issues. Said differently, if developers design their code to be frequently updated in the future and not as the ultimate, final version, then it will be easier to maintain.
Second, while no one likes to interact with buggy software, user perception and retention are influenced by a variety of factors beyond the immediate functionality of the software. Consider, for instance, the strategic use of open communication and transparency. Companies can actively engage users in the development process by clearly communicating that they are interacting with a rapidly developed, iterative version of a software product and that their feedback and bug reports contribute to its improvement. Furthermore, effective and responsive customer support can significantly alleviate user frustration. Users are generally more forgiving of bugs if they see the software team actively working on fixes and improvements and if their concerns are acknowledged and addressed promptly.
In conclusion, software development has evolved to a point where it may no longer be accurately classified as a branch of traditional engineering. The dramatic reduction in the cost of mistakes, brought about by rapid development cycles and the capability for instant, remote updates, challenges the classical preemptive mindset and urges us to consider the value of a corrective one. What counts today is not the ability to build the perfect product but the ability to fix problems quickly and with transparency.
A well-structured, fast-paced development process that adheres to best practices can produce just as maintainable software as its traditionally-engineered counterparts. Meanwhile, transparency, user engagement, and responsive support can help alleviate user frustrations, fostering a sense of partnership that transcends the simple user-product relationship. Embracing the 'fail fast' approach might initially seem reckless. Still, it could also be a practical adaptation to the changing landscape of software development, turning mistakes from fearsome costs into valuable opportunities for continuous improvement and innovation. My unconventional approach to building digital products may seem risky to some, but it's a risk worth taking in the ever-evolving field of software development.