Eating my own Dog food

September 16th, 2010

Until 2003 most of the software I wrote was exclusively for my own use, or for use primarily in businesses that I was part of. This included a significant amount of systems software – because early personal computers were far less capable than todays embedded systems and the systems software I needed did not exist.

Today most of what I write is embedded software for clients. I work with numerous embedded systems, but the greatest demand is for Linux. I have been using Linux since version 1.3. I switched to Linux on my personal computers about 4 years ago. I have OS X86, OpenBSD, and Windows XP installed on the machine I am using right now.  I spend 99.9% of my time in Linux. I did this because I like Linux and because I grew frustrated with windows. I also use Linux because most of the embedded systems I work with run Linux and because almost all the systems I develop for are far more like Linux that Windows. I am constantly learning, because I am using Linux all the time, much of what I learn is about Linux, and some software that I write for embedded Linux devices I test on my own systems. I can not run a Xilinx Local Link TEMAC driver on an x86 desktop, but I can run the Atheros AR9170 USB Wifi driver. In many instances I emulate embedded hardware on my desktop. I can test file system drivers for NAND Flash systems on my desktop without NAND, as well as network bootloaders, …. In most instances I write and test as much as possible on my desktop before addressing the few hardware specific issues on the target system. Most of the embedded systems I write for are big endian and my desktop is little endian this assures that most of my software is portable. Running the same software on a number of different systems exposes problems that can be hard to find on the target. I keep a large collection of different systems – PowerPC Laptops, embedded ppc’s, ARM’s, x86′s, softprocessors. Where feasible I test on as many disparate systems as reasonable.

To the extent possible, I use the software that I write.

Price

April 29th, 2010

The Great Recession (or little depression) has made economists of all of us. I have spent a substantial amount of time – particularly when there was little work becoming expert in economics. It has not helped run my business any better, but it has provided a philosophical framework for the way I have chosen to do it.

Economists like Mises and Hayek, allow me to explain my prices. I try to take the majority of my work on a fixed or contingent fee basis. Like Cable and Cell phone companies, I have found that clients want to know what they are paying for up front, and that the administrative costs of tracking hours, miles, paper clips etc. often greatly exceed any additional revenue they might bring in. I have managed businesses for more than three decades. At one time just one part of my job was all the billing, accounting job costing, etc for a professional business with more than $4M in revenue. That is a lot of hours, copies, paper clips and miles to bill. When I can I try to avoid that entirely. When it is possible to price a project my clients know exactly what it will cost them. It does not matter to them whether I make $500/hour or less than minimum wage so long as what they are paying is worth it. So long as I can maintain the life style and working environment I choose it does not matter alot to me either. If I am as good as I claim that I am maybe I will be making $500/hour, and if a project goes completely to hell or I make a seriously wrong choice in direction I may end up all too close to minimum wage. These are my problems and I can deal with them. Ultimately I am far more concerned about whether my revenue will cover my expenses and whether I can accomplish the projects I have committed to than what my effective hourly rate is.

For many clients this approach seems unusual or odd. But this is usually how they have to price their work. I make or lose money the same way they do. I am fortunate in that my survival expenses are far lower – if I can take care of my family and meet my mortgage I am solvent, and that does not take much.

I do take projects at hourly rates. Some work just can not be priced otherwise. Some clients can not cope with any other arrangement. Sometimes either when I am very busy or when I am suspicious that there is a deep black hole hiding in a project I will not take it on any other basis. When I take work on an hourly basis the rates are all over the place. regardless of the fee basis for a project the cost varies based on how great the clients need is for my services and how badly I need the work. Today I am cheap tomorrow I could be very expensive. It is even happens that if a client is persistent enough and I really want the project but I am too busy to take it one, that I will hire staff. When you hire me you are buying my commitment to deliver on your project. Exactly how I deliver is my problem. I am a business, not an employee. You hire me to solve problems not create an impression on a seat cushion.

My self taught Phd in economics reveals that my approach follows the pricing theory marginal utility. Nice to know that my business model has the blessing of economic philosophers from Smith through Hayek. By the way the economic theory that the price of something should be based on the materials and labor used to produce it is called the Labor theory of value – which has another name – Marxism.

So it turns out I am a good capitolist.

Why ?

April 29th, 2010

I write this, sitting in my office in a building I designed and built, in my leather Eames chair, surround by solid walnut and cherry furniture hand made by my father-in-law – with an assortment of cables, computers and electronics scattered ontop. One of my dogs is pleading to crawl into my lap. My kids are napping on the leather sofa. In three directions  I can look out into the woods surrounding my home. My wife is in her chair at her desk on the far side of the room, and art that we chose together is on the walls.

This is where and how I work.  I am not John Thain CEO of Merrill Lynch. Some years I have made less than the manager of a Burger King. Others I have done very well. But because I run my own business, I get to choose how, where and when I work. It does not always work perfectly – there are rare occasions when a family and work crisis coincide and I have to figure out how to solve a clients problems and one of my kids to an emergency room. but these are rare. An most of my actual work as differentiated from managing my business usually occurs late at night when everything is very quiet and there are absolutely no distractions. Often I will work until daylight when I have fully absorbed all the intricacies of a complex project into my mind and I am racing to accomplish as much as I can while I am highly productive, before the need for rest overcomes intense focus on the work.

This is what I choose. This is what I want for me and my family. It is not for everyone, and the good parts come with bad parts. I constantly have to find work – as task I a abysmally bad at. On occasion I go for long stretches without work. When finances get extremely tight I am occasionally forced to take work I would not otherwise consider. When finances are bad enough I will take short onsite contract buns’n'seats work that makes me miserably unhappy or the night manage at the local Burger King. I will pay my mortgage, and take care of my family – and as quickly as I can get back to doing the work I love in the way that makes me incredibly happy.

I love what I do, and I love how I do it, and I will make great sacrifices to preserve or return to it.

In the begining

April 9th, 2010

Imagine you are curled up in a ball, buried in a cave, with no light – not even a flashlight, no tools, no sense of direction.  That is embedded software development.

It all began when I was a kid. I spent hours divising means to make an hour job take 15 minutes less – there was always an easier way.

Later my high School bought a Monroe calculator about the size of a mini-fridge.  It had 128 steps of programmable operations, and I was in heaven.  The Munroe was good at what I was not. It could add, subtract, multiply and divide and always get the right answer. I could put my effort into the fun part – the algorithms rather than the drudge work.

Two years into college I got a Heath H-89. Here was something with much of the power of the university computer system that sat on my desk. It always needed more, more memory, more and smaller programs, more storage, networks, …  I went from payroll programs in Hbasic, to system utilities, to firmware, to programmable hardware. . The H-89 was far more powerful than the Munroe, in many ways it was more powerful atleast for one person than the college mainframe. But a variety of artificial constraints or missing pieces limited that power. Making effective use of the H-89 meant overcoming those constraints, first writing modem programs, then printer drivers,  disk drivers, network drivers and eventually even reprogramming the memory PALs to use larger memory chips. In classes I was studying quick-sorts, data structures, and writing programs to process tax returns. In my dorm room I was experimenting with registers on synchronous serial controllers to increase the bit density of the disk controller. This all seemed natural – everyone with a micro-computer was busy overcoming limits.

I had not just become a computer programmer, but had entered the world of embedded systems. We did not call them embedded systems then – at least no one I knew did. In the years that followed I wrote general ledger systems, messaging an collaborations systems, CAD programs, as well as network drivers and boot ROMs, drivers for SCSI controllers, disk and tape drives.

Some time ago while flying cross country, the passenger next to me was writing SQL queries, on her laptop. I inquired and found that she was a software developer – we had common ground.

I was taken back by the adulation, almost trepidation that she expressed when she found out that I worked on embedded systems.  To me it was all software. When you needed to calculate unemployment compensation taxes you wrote and SQL query. When you needed to TFTP boot a new network card you wrote a boot ROM.

Still there is something different about embedded development. The process starts with nothing. In most instances nothing can be assumed to be working. There is always that instant of euphoria at first contact between the device and the outside world, whether it is blinking an LED or sending a few characters out a serial port, it has responded and you are now in control. This is also a moment of relief and disappointment. The system has come to life, the challenging intractable hard part is over. Relief and euphoria because the intimate contest of man against nature – in this instance scaling a never before climbed mountain of bits and  cycles has been won. Disappointment  because an enormous amount of work is left, but all remaining obstacles are hills rather than mountains, speed-bumps on the route to  completion, and the next unclimbed mountain.

I call myself a programmer,  but what I really do is summit unclimbed mountains.

Hello world!

April 9th, 2010

Welcome to WordPress. This is your first post. Edit or delete it, then start blogging!