Experienced Software Architect with completed projects on a wide range of platforms including online systems, multi-core high performance SOCs, and resource-constrained low cost microcontrollers
Looking to develop flexible efficient products with high reliability and low cost of maintenance, working both independently and within a team environment as required.
A company my wife and I established in 2008 to sell children's clothing on Wholesale and Retail websites. Turnover is growing steadily, and we have launched redesigned websites written in PHP, leveraging AJAX interactivity and performance optimizations including MySQL query caching and an NGINX veneer for static content delivery.
The new system reduces dramatically the workload and level of expertise required to run the business day to day, so I am looking for fresh challenges.
I am currently providing course leadership for ARM Processor training classes for Doulos Ltd on a contract basis, and I am providing architectural and software development leadership for a small startup company that is using Node.js and MongoDB for live data sharing and update across multiple client sites, with robust data recovery and offline working for unreliable internet access situations.
Provided guidance for Callfinity's re-architecting effort to ensure that their new code base will be easier to maintain and extend than their legacy VOIP product. Provided a system-wide perspective for some excellent engineers who had formerly been entirely focused on just the features they had been developing. Established component boundaries and clean interfaces.
Wrote the central call queuing component in Erlang, integrating an innovative call-aging priority scheme.
A three-month contract was extended to three years as a contractor, then a further five years as an employee. I was recommended to WD by ARM Ltd as an in-house/on-call ARM processor expert when WD started developing their first ARM Powered Hard Disk Drive.
Rewrote WD's servo positioning code to give a 5x speedup with increased filtering; both original and replacement code was written in ARM966 assembler. This was a key metric that convinced WD that the ARM drive was feasible, and resulted in the immediate hiring of over thirty engineers.
Worked across multiple departments and drive programs to optimize code and mentor in good engineering practices; all Western Digital hard disk drives manufactured in the past six years (and many earlier drives) contain my code.
Part of a team of four architects who designed WD's next-generation firmware framework. Used in Western Digital's first enterprise SAS drive.
Taught approximately thirty three-day and four-day ARM software and hardware training classes; provided independent competitive analysis and benchmarking for ARM Ltd; Assisted Sharp, HP, Western Digital and technology startups with ARM system expertise.
Developed a program that turned a textual description of a memory map into a binary Memory Management Unit control table set. This tool was purchased by ARM and is still distributed with their development tools.
ARM's first software engineer in their then-new Consulting Services department. I was responsible for providing software components and advice to OEMs and semiconductor partners as a paid service.
My role was 50% commercial and 50% technical; as the Software Consulting business grew to a pool of 40 available engineers, my role transitioned to developing work specifications, negotiating consulting contracts and selecting and managing teams to carry out consulting projects.
Harlow Technical College, UK
Education and work experience adjudicated in 2002 by City University of NY to be the equivalent of a BSc in Computer Science including 6 years University attendance.
Ongoing self-education in the many aspects of computer science that interest me. I evaluate new programming languages, libraries and frameworks on a regular basis, for example I experimented with erlang before I had the opportunity to use it at Callfinity and I am currently learning Python by using it for simple utilities. I am particularly interested in developing techniques to simplify multi-threaded distributed programming for traditional linear software engineers.
My goal when working for a company is to do what it takes to make that company successful. That means never assuming that anything is "somebody else's problem"; if there is an opportunity to prevent a potential problem or make a product or process improvement, I'll do it. If this overlaps with someone else's area I will research the issue, discuss possible enhancements with them and move forward with a mutually-acceptable solution.
Engineering best practices do not stand still, as an ongoing activity I am studying new techniques and methodologies; if the sales mantra is "ABC" - Always Be Closing, then the Engineering credo should be "ABLE" - Always Be LEarning.
I am concerned when a company is too reliant on Key Personnel; the company as a whole is weakened if someone is "the only person who knows how to edit file X". I believe that an engineer is more valuable to a company if he documents programs and processes, writes clear understandable code and mentors other engineers.
To overcome Key Personnel issues, at one company I set up and populated a database on an ongoing basis with factory and user support issues and responses. At Western Digital I introduced MediaWiki to enable engineers to record design decisions and publish 'HowTo' articles within the Controller Firmware group.
The Engineering Wiki was soon adopted across multiple departments and is now used for documenting processes, as a whiteboard for new feature development and as a resource for bringing new engineers up to speed.
I was still a student when a friend showed me his company's flagship product, an early computer vision system for performing automated quality control inspections on parts that it picked from a production line. A major cost item on this product was the stepper-motor controller that managed motor acceleration; this was more expensive than the processor unit - around $200 in the early 1980's.
I suggested that perhaps the stepper motors could be controlled directly by the processor board in software with acceleration controlled by Timer interrupt events, since the processor wasn't busy when the parts were being moved to the camera platform. This suggestion was adopted, saving over 10% of the BOM costs.
Throughout my engineering career, I have looked to achieve more with less resources; at Neotronics, I squeezed an innovative non-averaging filter into the last 120 bytes of ROM to eliminate periodic PSU-induced 80% f.s.d spikes in an explosive gas detector, saving weeks of hardware redesign and recertification.
Also at Neotronics while on a customer visit to set up a new datalogging center, I heard several people express a need for a simple quick datalog downloader that could be used in the field rather than downloading a bank of instruments during their charging cycle. When I returned to Neotronics I found that the existing system was slowed down by the daisy-chained connections of the ganged charger/downloaders. I was able to prototype a direct-connection system and get a 16x speedup in downloads, leading to a potential new product.
I had a conversation with an engineer in Western Digital who was asking if there was any way to get a stack backtrace from a core dump retrieved from a hard disk drive. I determined that it was possible to load the various parts of the core dump into the ARM simulator together with the original object file, and not only extract a stack backtrace, but also retrieve the values of all global variables in the system with the correct enumerated symbols for typedef variables.
There were some issues - limitations in the ARMulator prevented expansion of more than ten elements from an array, and WD had decided to purchase the compilation tools but not the debugging tools for general rollout. These problems were overcome by running the DumpFile Analyzer as a web service, using perl to massage the ARMulator requests and generating dynamic web pages from the output.
As time went by, the data transferred for each report became extremely large - up to 45MB for a full dump, so I used AJAX to fetch the contents of arrays and nested structures only when clicked by the debugging engineer.
This tool saved thousands of hours of developer time over its eight year lifespan.
A hard disk drive is a complex beast; at one time in Western Digital there were fifteen active drive programs in development sharing the same code base - all with different combinations of feature switches.
At the time, feature configuration was managed from a global header file containing 5,000 lines of code controlling around 600 feature switches, all enabled or disabled by combinations of conditional compilation flags. It was taking a lead engineer two or three days to set up a new drive program in that file, even if it was a simple "make-from" with minor changes.
As a temporary stop-gap until a true replacement was written (three years later), I transcribed the feature switches into an Excel spreadsheet, split into sub-sheets by categories of feature switch. A new drive program could be added in an hour or less by copying a column and making the few feature changes necessary to comply with the product specification.
At build time, a perl script generated a drive-specific features.h file. Since the generated file was smaller and contained no conditional compilation, build times were reduced by twenty minutes.
This system simplified the development of tools to compare features settings for different drives and to validate drives against specification.
I am very much aware that nobody has a monopoly of good ideas; I also see that some of the people with the best ideas tend to stay quiet in meetings. I make an effort to ensure that people are encouraged to contribute, and when I 'read' from their body language that they aren't happy about something but choose not to speak up in a public forum, then I'll have a chat with them later either to put their mind at ease about an issue, or to gain valuable input.
Working as an outside Consultant and Contractor required some deft footwork to get buy-in from the engineering teams with whom I was working. One cast-iron rule that I followed was to always give credit for people's contributions when talking with their managers, and always take appropriate responsibility when there were problems. If it was my decision to use some code that later proved problematic, then it was my fault. I can discuss how to avoid similar issues in the future with the contributor without raising a red flag for a simple error.
A significant part of my work for the past decade has been to mentor engineers and to help them build up their skill sets; after introducing Perl to WD for the DumpFile Analyzer and Features File Generator, Perl was adopted for many housekeeping tasks across several departments. I helped out engineers when asked, showing them where to find answers and how to understand the underlying problems when they ran into difficulties, rather than simply fixing the problem for them. I didn't let anyone flounder for too long, but enabled them to improve their proficiency.
Introduced Bagel Day at Callfinity. I don't think anyone realized that it was a cunning ploy to get people in early at least one day a week.
I tend to want to get everything 'just right' before releasing a new product. Over the years, I have learned to become more pragmatic, until a product is released it can't earn any money for the company. Now I focus on identifying the 'must have' features and getting them presentable, then iterating the design to complete the feature set and polish any rough edges revealed once the product gets out into the real world.
When a product is released and a problem is identified, I have had to learn to resist my initial impulse to get a fix out at breakneck speed. There are two issues with this; the primary concern is that the 'fix' breaks another aspect of the product - it has to go through at least a sanity-level regression test before release - the secondary reason is that a 'quick fix' may mask the underlying issue and lead to more pain in the future. If a 'quick fix' is released, then it has to be understood that the root cause has still to be discovered, and a 'real fix' put into the code.
I believe it is axiomatic that the only way to avoid making any mistakes in software engineering is to avoid making any progress. I also believe that engineers have different skill sets, aptitudes and competency levels, and should be guided into appropriate roles. That being said, I have very little patience with anyone who is persistently incompetent, unproductive or who consistently stifles the creative process through negativity. If someone's only talent is stating why something can't be done and if they never come up with a solution to a problem, then they should be encouraged to pursue new opportunities. I hear BK is hiring.