I think I have always been an Engineer - each time I look at something, I find myself working out how it does what it does. If something stops working, I imagine how it should work and think about what might cause it to do what it does now. Then I take it apart. Most of the time I fix it too :-)
I always used to think that everyone was like this, but they are not. One of my children is, and the other isn't. Some of my past employees were, and many were not. I know that now...
Certainly Universities do nothing to teach engineering graduates to think like this, but that is another hobby horse of mine :-)
I studied towards and got a BSC Hons in Electrical and Electronic Engineering at Brunel University in Uxbridge, Middlesex, UK. While I was there I followed a thin sandwich course that allowed me to gain lots of real experience at the same time as studying. I was sponsored by Thorn EMI, and worked in a number of different departments. There I learnt a lot from one particular hardware engineer, and fell in love with the simplicity and power of Synchronous State Machines. I also worked on a Synthetic Aperture Radar, and spent a long time discussing the principles of it with another very good engineer.
When I graduated I wanted to live with Niki who is now my wife (who graduated as an Electronics Engineer at the same time), and we chose the South West of England to live in. So I got a job at what was then Plessey in Templecombe Somerset. There I worked on defining, designing and making the display subsystem for a mine hunting Sonar. Because that was completed and working before the rest of the Sonar was, I was assigned to make the beam forming system work. To help myself understand how it should work I wrote a computer program. Then I went through the hardware design that already existed and modified my ideal floating point program to reflect the fixed point and truncated mess that the hardware was. My program proved that it could not possibly work, but when I presented that the hardware needed significant re-design I was told that we did not have the time. This type of ridiculous attitude annoys me, so I left the company.
I selected a start up company, NiCHE Technology, who as a spin out of Inmos, were working on Parallel processing systems using the Inmos Transputer. It was exciting to be in a fast moving commercial environment right up to the point where the investors failed to provide the second round funding that they had promised. My experience here taught me two things :- Designing electronics in a commercial environment was exciting, and relying on someone else's money made for an uncertain future.
So I formed HUNT ENGINEERING and amongst other things picked up the contract to build and test the ex-NiCHE products for the company that had bought the rights from the administrators. Eventually I also picked up contracts to design new products for them, and to build, test and provide customer support for those products too. I also gained contracts to do this for other customers too, one being Transputer based image processing products for National Engineering Laboratory (NEL).
For NEL I did a design involving the Motorola 96K DSP, and worked with a Motorola engineer Ralph Weir, who a few months later arrived on my doorstep representing TI and talking about the C40 DSP. He is still a good personal friend of mine after all of this time, having worked for us in Marketing for a while later in this story. It was him that persuaded me to make a modular product range with C40, and got me involved in writing the TIM-40 specification.
TIM-40s were a great success for HUNT ENGINEERING, Niki joined the company, we purchased, moved into and converted (yes in that order!) our business premises, employed engineers and production and test staff.
Remembering the lessons I learned from NiCHE, we have never borrowed money from the bank, or had outside investors. Niki took over the accounts, purchasing, invoicing, PAYE, VAT etc. and I set about securing the future of the company beyond TIM-40.
Taking experience of customer applications with our TIM-40 range, and my growing knowledge of real-time applications, I wrote a paper about "A Next Generation Multiple Processor Architecture for Real-Time DSP" and co-published it in several trade publications and presented it at several DSP conferences with our US distributor. This formed the basis of our HEART architecture, which we realised in the HERON modular products that you can see at the HUNT ENGINEERING web site today.
The HERON products combined FPGA, DSP and closely coupled I/Os to make it possible to realise a huge variety of embedded and/or real time systems that have been used by our customers in a very wide variety of applications.
But.... we tried to bring new products to the range that increased performance and capabilities, and found that we could not get them to perform reliably. Then some advanced customers hit a few inexplicable behaviours of the systems. Long story shortened - we discovered Signal Integrity. It seemed that (along with the rest of the world) we had tried to step beyond the point where any idiot could follow a cookbook approach and throw electronic components together.
The engineer in me made me want to fully understand all of the problems and effects, and with a lot of help from Dr Howard Johnson's books and training courses at Oxford University I dragged the understanding of my team to the point where we were confident to specify and develop some new products.
The raw teachings of the science doesn't actually tell you what you need to do in real world products. I specified a new modular product range called HAWK, and we built some test products to help understand certain areas, then some prototypes of the initial products. The results were astounding - we had over achieved in the speeds we achieved, the reliability we expected, and the analogue performance we achieved.
I drove the team to work on my new vision - a re-born company that had some products that were well designed, well manufactured, reliable and easy for our customers to program. To achieve this we worked on new production tools, production test systems, a new modular documentation system, new marketing web site, sales and support tools for the new products, that used internal programs to control external web site content via databases. We were going to have live status displayed for our customer orders and RMAs. I wrote company procedures and guides so that the team would be able to run the company smoothly and profitably.
When another graduate that we had almost finished training resigned, and at the same time we were spending more on payroll than we were generating from sales of the older products, I decided to offer the team an opportunity. I would help to complete the launch of the new products, as long as they committed to achieving that within a maximum budget. After that I wanted to be much less "in the loop" of the day to day running of the company - they could use the systems and procedures we were putting into place to run the company, and the more profit they made, the more they could earn.
I felt that we were offering an exciting opportunity to them, but the response we got was not enthusiastic, and in a few cases was actually aggressive. Faced with this it was clear that if we proceeded to complete the development of the new products and launch them, that we would again be tied to the company, needing to be there for every action and decision. So we took the decision (not lightly!) to stop the development and make the team redundant. This has immediately removed a huge weight from our shoulders. We do not have to fund the payroll in the hope that we could get a return on the investment one day, and we do not need to be in the office every moment of every day.
We both see this as a happy ending for us.