Hello and What?

My software engineering career began in industrial manufacturing with a paid internship at O’Sullivan Films Inc, a company specializing in plastic and vinyl sheeting for products like pool liners and car dashboards that, like so many American businesses was bought by and international conglomerate and folded into its parent’s generic embrace. The experience I gained while working at O’Sullivan, along with my years working in ‘agile’ tech startups over the years has me thinking about the differences between how manufacturing and pure software businesses approach product design, development.

“Traditional” mechanical and electrical engineering approaches encourage methodical, long-term thinking as opposed to the “move fast and break things” ethos prevalent in many modern tech startups. I believe there is a happy medium to be found for more sustainable and efficient software development practices.

The Traditional Engineering Approach

At O’Sullivan Films, every project began with a comprehensive planning phase. When the business unit approached the engineering team with a request for new equipment or an upgrade, it kicked off a meticulous process of blueprinting, planning, and specification development. This wasn’t just a cursory overview; it involved detailed simulations, small-scale models, and rigorous testing to ensure that every aspect of the project was thoroughly vetted before full-scale implementation began.

The emphasis was always on long-term viability. Every project proposal included not just the initial costs, but also projected maintenance needs, operational requirements, and expected output over the system’s lifetime. This holistic view ensured that the company wasn’t just solving immediate problems, but investing in solutions that would serve the business for years to come.

For instance, when we embarked on a project to upgrade a calendaring machine (a device that creates thin plastic sheets), the process looked something like this:

  1. Business need identification
  2. Detailed blueprinting and planning
  3. Simulation and small-scale testing
  4. Full-scale execution (typically lasting about six months)
  5. Rigorous testing and quality assurance
  6. Deployment
  7. Continuous maintenance and upgrades

This approach meant that once a project was underway, all resources were dedicated to its completion. There was a clear understanding that work on improvements or business ask s elsewhere in the system would be put on hold until the project was finished. This focus allowed for a level of quality and thoroughness that’s often lacking in environments where the emphasis is on delivery first, quality later.

How Startups Do It

In contrast, many modern startups operate on a fundamentally different philosophy. The mantra of “move fast and break things,” popularized by Zuckerberg and now endemic in the software industry, encapsulates an approach that prioritizes speed and innovation over careful planning and long-term considerations.

This methodology often looks like:

  1. Rapid MVP (Minimum Viable Product) development
  2. Quick deployment to gather user feedback
  3. Iterative improvements based on user data
  4. Continuous feature addition and pivoting as needed

While this approach can lead to rapid innovation and quick market entry, it often comes at the cost of long-term stability and scalability. Many startups find themselves drowning in technical debt or struggling with systems that can’t scale as the business grows. Startups don’t die from bad code but, they do die from slowing execution speed and innability to continue innovation.

Bridging the Gap: How Far Can a Little Planning Go?

I believe the key to reconciling these opposing ends of the spectrum lies in understanding the nature of the problem you’re trying to solve.

In industrial settings like O’Sullivan Films, many processes were well-understood and relatively stable. The challenge wasn’t in figuring out what to build, but in building it efficiently and ensuring its longevity. This lent itself well to comprehensive upfront planning.

However, many software projects, especially in startups, deal with more uncertain and rapidly changing environments. In these cases, a more flexible approach is necessary. But that doesn’t mean we should throw traditional engineering practices out the window.

Here are some key lessons we can apply:

  1. Understand your problem domain: Is your project more like a well-understood industrial process, or is it venturing into unknown territory? This will help you decide how much upfront planning is appropriate.

  2. Consider long-term viability from the start: Even if you’re building an MVP, think about how it might need to scale or evolve in the future. Build with extensibility in mind.

  3. Incorporate maintenance planning: Regular maintenance isn’t just for physical machinery. Plan for code refactoring, technical debt reduction, and system upgrades from the beginning.

  4. Balance agility with strategic planning: While remaining flexible, set clear long-term goals and architectural guidelines to ensure your rapid iterations are moving in a coherent direction.

How To Use It

To put these principles into practice, consider the following strategies:

  1. Do you understand the problem: If there aren’t many unknowns and the system you’re building is well understood. Don’t get fancy, keep it simple and spend time up front getting it right. If you don’t understand it, spend time asking questions until you have an at least the outlines well understood.

  2. Develop a maintenance mindset: Schedule regular “maintenance sprints” to address technical debt and system health, just as traditional manufacturing businesses maintain their business critical machines.

  3. Implement thorough testing and quality assurance: While you may not need the six-month testing periods we had for industrial equipment, invest in robust automated testing and QA processes.

  4. Foster a culture of sustainable development: Encourage your team to think beyond the immediate feature and consider long-term implications of their code.

  5. Balance MVP with MMP (Minimum Marketable Product): While building your MVP, also consider what additional features or robustness might be needed to create a product that’s not just viable, but sustainably marketable.

There Are No Magic Beans

Of course, there’s always the risk of over-engineering or getting bogged down in planning at the expense of execution. It’s often hard to understand what needs to be built early on since ‘product market fit’ can come later. In these cases, focus on experimentation and create disposable prototypes. In startup environments, it can be difficult to convince stakeholders of the value of long-term thinking when immediate results are demanded.

However, I would argue that the costs of not considering long-term viability are often much higher. The time saved by skipping thorough planning is often lost many times over in debugging, refactoring and sometimes complete outages followed by rewrites when systems can’t scale or adapt to changing needs.

Last Bit

My experience at O’Sullivan Films taught me that there’s immense value in the methodical, long-term focused approach of traditional engineering. While the software world’s emphasis on agility and rapid iteration has its merits, I believe we do ourselves a disservice by not incorporating more of these time-tested engineering principles.

As software engineers, we have the power to shape not just code, but the entire approach our industry takes to building systems that will form the backbone of our digital future. By blending the best of traditional engineering wisdom with modern agile practices, we can create software that’s not just innovative, but sustainable, scalable, and truly built to last.

Let’s champion long-term thinking in our projects, our teams, and our industry as a whole. The future of our digital infrastructure depends on it.