Clever kitchen implements

Over the years I have gotten various "cleverly designed" kitchen implements.  I have a clever pizza cutter, a clever tin opener (that costs more than my first motorized vehicle(*)), a clever tea infusion ... thing.  The list goes on.  All of them gifts from well-meaning individuals.   None of which appear to cut pizza, open tins or make tea.

Of course: none of these implements work.

The pizza cutter is an awkward design that makes it hard to not hurt yourself -- let alone cut pizza.

Nobody knows how the tin opener works.  Probably by some form of black magic, because making it work invariably involves generous amounts of loud blaspheming and some measure of gesticulating angrily.

Finally, there is the tea infusion ... thing. While looking somewhat promising, the opening to facilitate contact between tea and water is so narrow your tea is in no danger of becoming even the least bit damp.  By the time your water has taken on observable coloration, the water is cold and most of it has evaporated.

I have drawers more of clever kitchen implements.

If I may I'd like to make two suggestions:
  1. Don't buy me clever kitchen implements.   Please.  They'll just end up at the back of a drawer and jam when I try to close the drawer.  Buy me battle-hardened stuff that actually works.
  2. If you are an industrial designer and you feel like designing something for the kitchen: please don't.  It is extremely unlikely that you'll manage to design something that is significantly more useful than a sharpened stick.
Next week we will discuss the Audi 1.8 litre inline-4 petrol engine versus the 2 litre, inline-4 Alfa Romeo Nord engine and ask the question why Audi allowed a village idiot to design such an unsightly lump of misery and why this miserable ode to impotence was ever fitted to a car.  Stay tuned.

(*) Okay, so my first motorized vehicle only cost NOK 25.  It was a 50cc Vespa scooter that was stuck in first gear and I could pedal my bicycle faster than this thing would move at max rpm.  I bought this off the village idiot.

I am unsure if he went on to a career in the german automotive industry.


Be neat, and the rest will follow.

When I review someone else's code I occasionally have to harp on about basic things.  Missing Javadoc, superflous code, superflous methods, lack of attention to thread safety, lack of comments documenting intent, or even lack of unit tests.  And some of the programmers that make these mistakes are not people who just graduated -- some of the programmers that make these mistakes are relatively senior software engineers.

The above are what I see as basic skills.  If you cannot produce code that checks the above boxes consistently, you should consider yourself a novice programmer and you must work harder to become a better programmer.  I don't care if you have been programming for 1 year or 50 years.

I'm not going to speculate as to why many programmes habitually skimp on neatness, but I'll offer some observations.

The first, and most obvious observation is that neat code, in my experience, is more often correct.  It has fewer bugs.  Not always, but more often and by a good margin.  When people make an effort to write code that is eminently tidy and understandable to other people, correctness seems to follow.  And where there is correctness and simplicity, consistent speed often follows.

I am not sure if this is because tidy programmers are inherently better programmers or because tidiness makes correctness more attainable.  But they tend to co-occur.

The second observation is that code produced by messy programmers will be treated with distrust.

When we have to deal with code we do not understand we grow wary.  It is extremely uncomfortable to put trust in what you do not understand.  And it is even more scary to alter or to be responsible for changes to code that is hard to grasp.  You do not want to build your system on top of code you do not trust.

Code that is not trusted is replaced.  It doesn't matter if the code is brand new (although sometimes newness can lead to indecision in throwing the code away).  I've seen people spend months of their life writing code which is then discarded because it was more costly to maintain and develop it than to start over.   Or more importantly:  because the code did not provide a foundation on top of which others could build.  I know of no engineering discipline where so much work is simply thrown away on a regular basis.

It breaks my heart that a good proportion of programmers who have just produced code that is thrown away learn nothing from the experience and go on to repeat their mistakes.

Occasionally people will challenge me on the importance of neatness.  They will point out that neatness is not a goal in itself.  That it is the features, the performance, and not least moving projects forward that counts.

In particular the last argument can be hard to argue with.  In particular when combined with lack of experience or lacking ability to extract learning from experience and mixed in with various popular project management philosophies like the focus on "minimum viable product".

Most software projects, if successful, will be long-lived projects.  What you can do in the short term isn't really that interesting.  What is interesting is what you can do long term -- how long you can maintain forceful forward momentum.

It is important to not knowingly make too many mistakes early on that will necessitate doing a lot of work over if your product or project is successful. Try to see it from an external point of view.  How would you feel, as an investor if I showed you something, you invested in it and then I threw it away saying "of course, what you just saw would never work so I am going to throw it away and build something entirely different".  That happens every day in the software industry.  But we don't always admit it.

Software projects have a tendency to stagnate over time.  Complexity grows, faults and design problems accumulate and at some point everything grinds to a halt.  Focusing only on short term results without having a realistic vision of how to maintain developer speed in the long term means you will have to throw more code away earlier or you will have to suffer low productivity.

(To put numbers to the above: in my experience, projects that are messy tend to reach the point where more effort is spent on debugging and keeping the code afloat than on development after 3-4 months.  However, killing off these projects can sometimes take years, depending on the size of the project owner's cojones)

Neatness may not be a goal in itself, but it is what is called a "keystone habit": habit that has a ripple-effect on everything around it.  It is a prerequisite for writing good code.  If you can't even produce neat code, it is highly doubtful that you are capable of paying much attention to more glamorous things like algorithm design, optimization etc.


Why I am not patenting my prototypes.

A year ago I was diagnosed with kidney failure and informed that I would need a kidney transplant within the next 2 years.  Last summer my kidneys took a turn for the worse after a salmonella infection and I became dependent on dialysis to keep me vertical.

I am still on dialysis and waiting for a transplant and despite what one might expect:  life is fairly close to normal.  I eat, sleep and go to work and I still shake my fist at all the orange people on my TV.

There are two main kinds of dialysis.  Hemodialysis, in which the blood is pumped out of your body and circulated through a machine.  This requires you to go to a hospital, and to get hooked up to the machine is a bit of a ceremony since we are talking about pretty direct access to your bloodstream.

Then there is peritoneal dialysis, where a fluid is pumped into your abdomen through a small tube and dialysis is performed by creating osmotic pressure and sucking waste (and excess fluids) out of your blood through the peritoneal membrane.   With peritoneal dialysis you walk around with ~2 litres of dialysis fluid in your peritoneal cavity and this fluid is exchanged 4 times per day.  You drain it out and you put new fluid in.

For the most part I can live a normal life.

However, that was just the background.  What I really wanted to talk about was something else.  You see, with peritoneal dialysis there are certain practical problems that need solving.  Since I need to exchange fluids every 3-5 hours, I need to have bags of fluid with me wherever I am.  8kg of fluid per day.  And this fluid has to be heated to almost body temperature before I can put it in my body.  (I've tried putting in fluid at room temperature.  Not pleasant).   I also need some supplies and equipment to do the exchanges.  Disinfectants, face masks, clean tissues, Iodine caps for the catheter, an IV-stand for the bags, a scale etc.  Travelling with all this gear is ... interesting.

Finally, the actual exchange can be rather painful.  As you drain the fluid the catheter might attach itself to various bits inside your abdomen.   Imagine a vacuum cleaner -- now imagine dangling your testicles in front of it.  FWOMP!  You get the picture?  This is sort of what happens inside my abdomen when I empty out the fluid.  It is curse-out-loud painful.

Naturally this inspires some measure of creativity.

I prototype stuff to help me cope with this.  For instance right now I am building a portable dialysis fluid heater.  I had a look at the ones on the market and they were all too bulky and too expensive. None of them would be an improvement over the heater I have now.

Not a lot of people prototype and build their own gear.  And a lot of health professionals are very interested in what I do because they have other patients that might benefit.  In fact I've been asked if I can give demonstrations on several occasions -- and I will when things are in a safely usable state.  But I keep hearing people say: "you should patent it".   And every time people say that I cringe a bit.

I know that most people do not really think about the role of patents in research, innovation and product development.  For most people patents are this magic thing that protects your idea and makes you rich.  And I don't blame them.  I know intelligent people who think that patents are actually worth something to a private person and that they play a positive role in society.  (I know even more people who think society can go fuck itself as long as they can get rich).  The original intent behind patents was good:  to share knowledge and to give the inventor a head start.  But that was a very, very. very long time ago.

Patents do not play that role today.  Patents are not a source of usable information for engineers and inventors:  they are poisoned wells that you cannot drink from.  Anyone who says otherwise cannot possibly have worked for any company that is embroiled in, or runs the risk of being implicated in, patent lawsuits.

Nor do I think people have any realistic concept of what it would cost to license all the patents that would apply to any non-trivial product, world-wide.  Because companies don't do that.  Go to a consumer electronics store of some description.  Almost everything you see is an act of patent infringement.  Every little detail on every little device is an idea that someone claims to "own".  And for the most part, the intellectual property isn't licensed.

Patents do not provide the ordinary inventor with any sort of protection.  A patent is worthless unless you have lots of time and money.  If you have a patent and I have a pile of money, my pile of money wins over your patent.

But even if we pretend that patents have value for society: why would I patent these things?  Why would I want to contribute to keeping solutions away from people who need them?  And more importantly:  why would I isolate myself from the help I could get from others?

When I design gear I spend a lot of time thinking about whether other people can duplicate what I do.  It isn't enough that I manage to design and build something: I want other people to be able to build what I build.  That means it has to be relatively simple and it has to be cheap.

One example is an automatic valve system to assist in draining that I have been tinkering with in my spare time.  I'm not sure I will finish it before I get transplanted, but it is an interesting problem and I enjoy figuring things out and come up with solutions to problems.  For the system to work I need relatively precise measurement of the flow rate.  If I do this by weight I can make do with very cheap components (a kitchen scale, a microcontroller chip, an LCD-display of some sort, some buttons, a high resolution ADC -- total cost perhaps $100-$150).  I could use ultrasonic flow measurement, but then the cost of the sensors alone jumps by an order of magnitude.

If I had ultrasonic flow sensors I could miniaturize the whole system to where it fits in your palm, and if I ask nicely, I bet that the manufacturer would give me the sensors for free.  But people who try to build the same system would not get them for free.  So that isn't really a viable route.

You may think that I do this out of pure altruism.  Sure, I'm not above admitting that there is a component of that.  But there is also the fact that if I can interest other people in what I do, I directly benefit from it.  If other people make suggestions, develop my ideas, add their own, that helps me directly.  In fact, it has already helped me a lot.

I cannot imagine a scenario under which I would want to patent anything I designed to help dialysis patients.  I'd be delighted if someone turned my ideas and designs into commercial products -- even if I don't make a dime.  If they do they deserve whatever profit they can make of it.

Of course, what I should do is to publish my notes so that at least there is prior art if some patent troll were to bully others with bogus IPR.  I have been too lazy in jotting down what I have learned, which solutions I have tried, which I have rejected, why etc.  I hope to do something about this.  Possibly by publishing a blog on the subject.  I guess such a blog would have a pretty narrow audience though.  Perhaps I can spice it up with fashion tips and long descriptions of how personal grooming habits :-).