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,

Dak

Free for a limited time: how to keep raccoons out of your green recycling bin

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.

There are many solutions to this problem. 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, 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.

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‘ line 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
• In practice, the loop lasts for about a year

Feedback, requests for clarification, commentary, kudos and complaints are all welcome.
I’ve thought about illustrating this posting; please let me know if you think that would be valuable, or would like to do the art for it!

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, but it’s radically better than nothing, and very inexpensive.

As a helpful commenter notes, below, there’s also a good commercial solution (http://www.raccoonsolutions.com/).

Regards,
Dak

Here’s an even cheaper “how to stabilize a camera”

Or, how to gain 2 f-stops with about a dollar in parts. Note that it will only help you for stills, but it’s a great hack.

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.

Best,
Dak

Design trade-offs, the knee in the price curve, and appropriate solutions

Poor man’s camera stabilizer
http://littlegreatideas.com/steadycam/

This is an important reminder that cheaper does NOT have to mean “radically worse.” This is brilliant; you may well have seen it before, but if you haven’t, go look. If you have…

Consider this. A good low-end, name brand stabilizer (Steadicam ‘Merlin’) is about $900. It’s a LOT nicer than this, won’t tire you out, and is beautiful (really). It buys you credibility if you have to Go Somewhere Important. The big, impressive-as-all-getout rigs for Professional Film cannot be beat…if you are carrying a 15 to 70 lb. camera.

The question, as always, is: what is your application, and what matters? Web video for personal use? $15 + your labor buys you what you need to do a few motion shots without that “hand held, make the audience ill” documentary look.

Now, consider what this means in the context of product evolution. Generally speaking, broader market adoption of products means a reduction in cost and features. When working in product development, it’s tempting to think of this as “sliding down hill” in terms of reducing your beautiful boutique product to least-common-denominator “mass market” stuff that “those people” might use.

This is a trap, and smart product managers know this. Quantity is its own quality. Go ahead, own the high end. But introduce the low-end product. If the high end product is that much better, you can still sell it. (Steadicam comes to mind!). But it’s better to make the low-end product that might cannibalize your high-end sales, before someone else does, if and only if there’s a sufficiently large market for it.

Now, you are thinking, how does this apply to software? And to software engineering?

I’ll give you a hint: amortization of development costs. More later.