Analysis of the Macbook charger

Ken Shirrif did an excellent tear-down on the Mac laptop chargers.  Impressive.

The chargers are generally speaking, terrific.  In particular, it has a small microcontroller that serves as a watchdog, and turns the rest of the charger on and off when connected (or not).  This is laudable from an energy conservation perspective!

I have one pet peeve that has two root causes:

1) The outer coaxial conductor is aluminum, which work hardens and gets brittle over time, especially when the outer insulation layer gets stiffer. I think this is why the newer cables are even more problematic than the older ones.  Coaxial conductors are terrific for reducing radio noise, especially with a switching power supply, but don’t go well around tight radius curves.

2) People aren’t very good about not pulling on their cables and wrapping them tightly around corners. This is a particular problem right at the connection points on both ends. It’s fundamental to human behavior: people do what the object ‘affords,’ and cables look like they are meant to be wrapped up and pulled on. (Read Donald Normal’s “The Design of Everyday Things” for a good explanation of James J. Gibson’s “Theory of Affordances.”)

Bottom line: Apple would be well served to move away from the ‘pretty’ round coax able design and move to a flat design with more and thinner conductors, so that the strain between the outer side and inner side was reduced when going around sharper corners. Adding cable connectors so that the cable is replaceable, not just the whole charger, would also help.

(I posted a shorter version of this in a comment on Ken Shirrif’s blog.)



A great way to make quality important in your organization

There’s really only one key practice for quality:  continuous improvement, and its dual, continuous learning. For continuous learning, many practices that help; one of my personal favorites is ‘Lunch and Learn.’  It’s easy to get started, allows the team to ‘opt in’ to shared practices, and is an amazing opportunity for growth.

One example that quickly springs to mind is “Clean Code: A Handbook of Agile Software Craftsmanship” by Robert Martin. This was one of the featured books in our lunch and learns at EVault. We’ve also done this at Pharmatrust, and I think we’re about at critical mass to do this at MedAvail.

On a side note: I consider myself fortunate to have had the opportunity to learn from the teams I have worked with over the years; it’s one of the greatest pleasures of my professional life.

Quick article excerpt for the day…on Apple’s business strategy and software leadership.

Steve Jobs at the WWDC 07
Image via Wikipedia

There are many useful business strategies for companies, and many of these are executed successfully up to the point of a crisis, at which point the companies must re-invent themselves or die.  It seems to me that most hardware vendors (RIM, Motorola, Scientific Atlanta) are caught in a ‘how do we race to the bottom on price and still preserve our margins?’.

This article (Steve Jobs Speaks Candidly About the State of Apple and Its Competitors.) suggests that Apple does it differently.  There are many interesting points, but this one struck me as being especially important, both in illuminating Apple’s strategy, and in highlighting how real strategies must be explicit, not implicit, and sometimes reinventing the company strategy is the most critical thing that an executive can do.

“Because Apple looks at things from a software-driven standpoint first and then works to iterate and make the product better while keeping the price the same (or lowering the price), as it did with the iPod, the company doesn’t look at its line and make decisions based on features in order to lower the price, expecting the software to magically perform.”

In my opinion, Software requires real investment, process, and sustainability.  As a software leader, I guide the software team to make our work a key feature of what the company is offering to the customer, not an afterthought.  Apple clearly gets it.  Microsoft gets it (finally?); see Windows 7.

RIM *could*, if they make the Blackberry a great platform for developers, and see their own software on it as being pivotal.  RIM still has best-in-class email and instant messaging, and Outlook integration, but these advantages are starting to erode.  There is still time for RIM to awaken, but the clock is ticking…

Thanks again for reading,

Building teams: Developers, not Programmers

If you aren’t in the software development business, this post is not for you.  These aren’t the droids you are looking for.  Move along!

Once upon a time, it was Good Enough to have wicked good coding skills.  Master programmers would hand out assignments to the rest of the team, who would code up the concepts and go their merry way.  However, those times are long gone; not only are coding skills regularly taught in high school (all over the world), but even the higher level skill of programming to specifications, not designs, has become a commodity.

I personally believe that the best answer to the commodification of skills is refactor jobs and skill sets.  With this in mind, I am thoroughly convinced that people who were once content to be “programmers” need to be “developers”– consumate professionals able to solve the “whole problem” and take a design task from concept to production.

The fundamentals of business and career growth remain the same: find a need and fill it.  However, there’s no longer a need for 100% code jockeys.  That’s OK; solving the real problem is more fun, and pays better.  (Anyone who I have worked with over the years will recognize that I’m consistent on this point…and most of them have moved on to bigger and better things.  If you are reading this, do drop me a line or post a comment.)

As always, best regards,


Now absolute for Toronto, but perhaps useful elsewhere: Keep raccoons out of your green recycling bin

In use.
Installed and closed.

Toronto uses a ‘green bin’ system to recycle and compost organic waste. Toronto also has a highly active raccoon population, which quickly tips, opens, scatters, and eats the leftovers in the green bin. This is risky from a health perspective, as raccoons are carriers of roundworms, can be rabid, and will escalate once they establish your home as a source of food.

There are many solutions to this problem. Toronto FINALLY implemented a proper anti-raccoon lock with an all-new bin solution. It’s not perfect, but it does render the below obsolete.

ELSEWHERE, feel free to use this. Cheap, cheerful, works-ish.

Without further ado, here is mine, and a bit of description of the design space.

The requirement: keep the raccoons out of the recycling.
The solution space: cheap, people-friendly, and does not require locking the bin in an enclosure, since many people do not have a convenient place for the enclosure.

Typical solutions involve locking straps, multiple screws, and some sort of buckling mechanism. These work well.

Mine is one loop of Velcro One-Wrap, and a screw. Tools needed, a screwdriver, a sharp knife point, and a drill or small flat screwdriver bit suitable for making a pilot hole in the body of the green bin. (A Leatherman tool will frequently have all of these. I favor the ‘Juice S2‘ for everyday use.)

  1. Take the roll of One-Wrap. Hold the end of the Velcro in your hand. Wrap it around your hand until it completely overlaps on your palm.
  2. With a sharp penknife or utility blade, cut a 5mm slit in the velcro so that you can pass a screw through it, just below the overlap region. You will use this hole to securing the loop to the body of the green bin with a screw, below.
  3. Push the screw through the velcro, so that the head is inside the loop
  4. Place the velcro loop on the bale of the green bin, and close it. Use the sharp end of the screw to mark the body of the green bin.
  5. Using your drill or small screwdriver bit, make a pilot hole for the screw
  6. Drive the screw into the body of the green bin

Notes on using this device:

  • The velcro must be firmly and fully coupled on the overlapping part to keep the raccoons out
  • When you take the bin out on the morning of recycling/garbage day, remember to undo the velcro.  Toronto Garbage will not open it (nor any other strap that I can find on the market).
  • In practice, the loop lasts for about a year due to weathering. I recommend replacing it each Spring.
  • The largest failure (in three five years of practice) is human error: someone dropping a recycling bag into the bin, and forgetting to re-close it.

Feedback, requests for clarification, commentary, kudos and complaints are all welcome.

HOWEVER, I make no warranty or claim of suitability, as I’m NOT selling this to you. It does work for me. It won’t work for you. Seriously, you’ll lose a load or two of recycling to the raccoons because you’ll forget to close it properly, or the loop will become stiff with age and need to be replaced, but it’s radically better than nothing, and very inexpensive.

As a helpful commenter notes, below, there’s also a good commercial solution ( If this doesn’t work for you, upgrade to that.


Design trade-offs, and the virtue of fast (part 3 of 3)

So, what’s the lesson for software in these different examples of “the high end” vs. “the cheap”?

In my view:

1) Make a cheap (FAST) prototype. It may not have the cachet of the ultimate product, but it will validate the functionality of the product, and begin the incremental test/design/improve cycle.

2) If you have a high end product, make a cheap prototype of what might displace you. It will generate new ideas; the cheap prototype may not be something you can sell or make a profit on, but you will at least know where to look for a potentially disruptive competitor. Keep incrementing the cheap prototype; it’s better to disrupt yourself than for a competitor to do it, and your time as the only ‘cool thing’ in your category will end eventually. Moreover, your high-end product needs to pay for development, and is, in any case, a ticking time bomb waiting for someone (you? a competitor?) to destroy its value.

Note that Steadicam has done this; they have their high-end product, and have introduced their low-end product, but have shunned the “too cheap to make a profit on” product.

(If you’ve read The Innovator’s Dilemma you should be nodding your head at this point. If you haven’t read it, you should.)

3) Huge development costs for high-end products are risky. They need to be amortized quickly and/or defended vigorously. They can serve as a barrier to entry for your market…but you have to beware the lower-cost entrants!

To me, this is a compelling reason for incremental software development. Get the requirements, build a prototype, increment until good enough to field. Repeat cycle. Keep it fast; software development tools and training are much better than they were, say, 15 years ago. Even if you don’t release the prototype to the customer, build it this way *anyhow*.

What if you’ve got a big legacy system? The same lessons apply: build extensions incrementally, and by writing the tests first, and the code later. Think about prototyping replacements to the legacy monsters, even if you have to do it piece by piece. (Building tests for those legacy monsters is a great way to get started on replacing them; how else are you going to know if what you’ve built is backwards compatible?)

Comments, as always, are more than welcome.