My first commercial programming project

Laser Cutter CNC Programmer, 1989

In 1989, I was introduced to a problem that could not wait.

Bulldog Tools were in the process of installing an automated decoiler and Computer Numerical Control (CNC) laser cutter for the newly formed Stoves Plc. The machinery was there. The business case was obvious. The production opportunity was real. But there was one critical gap: there was no software to turn the Computer-Aided Design (CAD) drawings into machine instructions the laser cutter could actually use.

I was asked a simple question: could I write an application that would take the CAD drawing files and translate them into G-code for the laser cutting machine, so it could cut sheet-metal components for cookers and other appliances?

I said yes.

The problem behind the project

This was not a speculative software experiment. It was a production problem with an operations director waiting for an answer.

The company had invested in automated manufacturing equipment, but the practical workflow had not yet been closed. Parts existed in the CAD system. Coiled sheet metal existed on the factory floor. The CNC laser cutter was ready to work. What was missing was the digital bridge between design and production.

The application needed to:

• import component geometry from the Sun Microsystems CAD environment;
• allow parts to be arranged visually on a sheet area;
• support mouse-driven lay-up of cooker parts onto the available material;
• save the lay-up to 3.5" floppy disk;
• generate an optimised G-code sequence;
• export that sequence directly to the CNC machinery.

In modern language, it was a manufacturing workflow automation tool. At the time, it was simply the missing piece that would make an expensive machine useful.

Building a graphical production tool in MS-DOS

The software ran under Microsoft Disk Operating System (MS-DOS) and was written in Borland Turbo Pascal.

That meant there were no modern interface libraries, no web frameworks, no cloud services, no package managers, no code generators and no online search. The graphical interface had to be designed and built manually. Every interaction needed to be deliberate. Every byte mattered. Every function had to earn its place.

The finished application provided a fully graphical interface. Operators could import parts, place them on a representation of the sheet, adjust the lay-up using the mouse, then save and export the result as machine-readable G-code.

The goal was not to write clever software for its own sake. The goal was to make a machine productive.

The four-week challenge

The operations director understood the urgency. He had bought the machinery, but without the software it could not deliver the intended value.

He offered to pay double the fee if I could deliver the application within four weeks.

I beat the deadline.

More importantly, there was still enough time left inside the four-week window to deliver iterations that improved the application beyond the original specification. That lesson stayed with me: the first working version matters, but the best results often come from seeing the software in context, listening to the people who need to use it, and improving the fit between the tool and the real workflow.

Delivery timeline

Stage	Effort
Business analysis and design	2 man-days
Briefing to minimum viable product	15 man-days
Minimum viable product iteration to final version	5 man-days

The whole project was delivered by one person, using manual human coding from start to finish.

Tech stack used

• Borland Turbo Pascal
• MS-DOS
• Floppy-disk-based file transfer
• Imported CAD geometry from a Sun Microsystems CAD package
• CNC G-code generation

What made the project formative

This was my first commercial programming project, but it already contained many of the themes that have shaped my software engineering work ever since.

1. Start with the operational outcome

The project was not defined by a technology preference. It was defined by a production outcome: make the CNC laser cutter usable for manufacturing sheet-metal appliance components.

That is still the right way to approach software. The valuable question is not “what can we build?” but “what business capability needs to exist that does not exist today?”

2. Understand the workflow before writing code

The critical design work was not just the translation of CAD data into G-code. It was understanding how people would move from design file, to sheet lay-up, to machine instruction, to production.

That required business analysis, process thinking and enough manufacturing context to design something usable.

3. Make the interface fit the user

A graphical interface was not an indulgence. It was essential. Operators needed to see the sheet, place the parts, understand the layout and trust the output before sending it to the machine.

Good software reduces cognitive load. It makes the next action clear. That was true in 1989 and it remains true today.

4. Deliver quickly, then improve intelligently

The promise was a working system inside four weeks. The delivery approach was therefore necessarily lean: understand the problem, build the smallest complete workflow, test it against the real operational need, then improve.

That pattern still sits at the heart of effective technology delivery. A minimum viable product is not a rough demo. It is the first usable version of a real capability.

5. Software creates value only when it is used

The machine, the CAD drawings and the code were only valuable when they came together in a production workflow. That is a principle I have seen repeatedly since: software does not create value merely because it has been delivered. It creates value when people can use it to do something better.

This is also reflected in virtco®’s current delivery philosophy: we combine technical delivery with business analysis, workflow mapping and adoption so systems are not only built, but used and embedded in the organisation. virtco®’s approved capability material describes this as end-to-end delivery, from business analysis and solution architecture through to deployment and support, with a focus on measurable business outcomes rather than technology for its own sake.

The personal memory

I was doing this during the summer holidays after completing my art and design foundation diploma.

I used to cycle to the site from my parents’ house.

That detail matters to me because it captures the point at which design, engineering, business pressure and practical delivery all came together. I'd been messing about with computers and programming in various languages for over 10 years already, but wanted a different path from school to career. I had just completed my art and design foundation with offer of a place at industrial design school, but here was a commercial production environment with a real machine, real operators, real deadlines and real consequences.

The project showed me that software engineering is not only about programming. It is about translating intent into working systems. It is about making technology useful. It is about seeing the shape of a problem, designing the missing bridge and then building it with enough care that other people can rely on it.

Looking back from today

More than three decades later, the tools have changed beyond recognition. We now work with cloud platforms, mobile applications, web systems, automation, artificial intelligence and modern software delivery practices. virtco®’s current capability set includes custom software development, Software as a Service (SaaS) product development, automation, integration, artificial intelligence and digital transformation consulting.

But the fundamentals have not changed as much as people think.

The 1989 laser cutter project was about:

• understanding the business outcome;
• designing the workflow;
• integrating between systems;
• giving users a practical interface;
• delivering quickly;
• iterating against real needs;
• making expensive technology produce measurable value.

Those are still the fundamentals.

Today, at virtco®, we describe much of this as Outcome Engineering: starting with the result the organisation needs, then using software, automation, artificial intelligence, process redesign and adoption support as the means to achieve it. The Virtco Outcome Engineering Framework defines this as the systematic identification, design, implementation, measurement and continuous optimisation of interventions intended to achieve specific business outcomes.

In that sense, my first commercial programming project was not just the beginning of my coding career. It was the beginning of a way of thinking.

Build the bridge between the business problem and the working outcome.

Then make it reliable enough for people to depend on.