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

Why morale matters

The McKinsey Quarterly has a good interview with Brad Bird (director of The Iron Giant, The Incredibles, and Ratatouille). I’ve been following Pixar with great interest over the years, partly because I have a couple of old friends who work there (Hi guys!), and partly because I really believe in what they are doing (changing from being a software vendor in a niche market to being a major motion picture studio: brilliant!). In my opinion, Pixar is the poster child for the “eat your own dog food” school of management, and deserves their success. (How good is Renderman? Well, it’s good enough that we’ve won Oscars with movies we’ve built on it!)

In my experience, THE key issue on the performance of teams is to get the morale and the synergy of the teams going. This involves selecting the right people, keeping the great players in the team, and keeping the ideas flowing.

Here’s a great quote from the interview:

The Quarterly: It sounds like you spend a fair amount of time thinking about the morale of your teams.

Brad Bird: In my experience, the thing that has the most significant impact on a movie’s budget—but never shows up in a budget—is morale. If you have low morale, for every $1 you spend, you get about 25 cents of value. If you have high morale, for every $1 you spend, you get about $3 of value. Companies should pay much more attention to morale.

Brad is being very low-key here; the emphasis is mine. In my experience, this is exactly correct.

Read the rest of the interview for how and why Brad worked on morale.

What are you doing to increase the morale of your team (and your family, and the broader group of people you work with) TODAY? I’m talking about hugs and compliments; what are you doing to recognize people as individuals, to listen to them, and to make them feel listened to?

More later in the blog, on building a team of “Developers versus Programmers.”

Have a great weekend,
Dak

Getting cranky about “IT Policy,” and improving your password practices

I just read a helpful article about tuning organizational password policy but I’m afraid it rubbed me the wrong way.

What it says is helpful and mostly good practice, but it fails to address the problem from the perspective of the users, and does the usual “well, this will be a pain for the users, but it’s good policy, so we’re recommending it,” which is one of many reasons why people hate IT departments. (I say this as a seasoned IT professional, and I hate us, too.

IF you notice that YOUR passwords violate any of these rules, chances are that they are already broken. Change them now.

To all password users, everywhere: Make your passwords unguessable as best you can. If someone guesses your password, change it. Corollary 1: Since you can’t know if someone might have guessed your password, change it from time to time. If you feel that you have to make a list of passwords, make a list of reminders, not the actual passwords, and keep it safe (not where someone can look at it without you knowing about it). More detail below.

HOW:

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

Sources of inspiration

Today, I was reminded that we need to seek both to persist in our dreams, and find sources of inspiration.

I think this video speaks for itself.

Pursue your dream with enthusiasm, hang in there, and when you get the shot, take it.

Best,
Dak

Summary for this week: do it now, do it fast, do it cheap

So, what does all this mean?

Prototypes are your friend. Keep it simple.

1) In developing any product, especially software, DO IT NOW. So pick the things you can do NOW and get them done. Not partially done, not sloppily done…DONE, as in IT WORKS! This frees you to do something more, different…if you keep slogging on the same old thing, you are trapped in diminishing returns.

2) Decide when you are ready to show something GOOD to your customer. Keep the pace up. Don’t fall into the trap of “We can’t ship it, because the next version will be so much better!”. Show it, agree on what has to happen next[*], and then ship when you say you will.

3) Ship it, and follow up. Make a list of things you can do NOW. See step 1.

[*] Agreement means “We will pay you money when it does this.” Not “It would be nice if it did this”…that’s not agreement, that’s just socializing. You need agreement, or you aren’t DONE.

How does this fit into what I was talking about before?

A really good prototype might well be something you can sell; if not you can sell the idea, get feedback, and make something that can be taken to the market. It also allows you to play with something completely new, or the crazy idea for your main product that is too risky to actually DO with the main product.

As always, comments are more than welcome.

Best,
Dak

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.

Announcing Dakworks, and doing today’s "idea warmup"

Dakworks is an information technology, software development, editing, and management consultancy. As the principal consultant, I believe that systems and software must be built to make great things possible, to generate new possibilities, and to liberate people from onerous and repetitive tasks.

At present, the purpose of this blog will be occasional commentary, opinion, and links to “things that I found interesting” in the spirit of the new, trendspotting, and nifty uses of leading and trailing edge technologies.

Today’s cool toy spotting (Thanks to Malcolm Stanley at Strategic Thinking and Execution for pointing it out):

This uses the Arduino controller and an add-on sensor package to monitor plant status and post the results on Twitter.

http://blog.makezine.com/archive/2008/02/how_to_make_plants_talk_t.html

The application itself is silly, but think about the implications: Twitter can serve as a personal mash-up dashboard for your home, your car, your pets, your pre-writing kids, and not just your blogosphere and mobile device friends.

For example, imagine an outdoor motion sensor and camera *as a Twitter feed*. Outdoor motion sensor goes off, not worth an alarm…but if you get a call from your alarm company, AND the outdoor motion sensor went off, you’d check your camera and confirm that it’s likely NOT a false alarm. Twitter’s ongoing ‘low quality’ information stream is a great way to moderate and present this data, since it’s redundant, and truly a ‘value add’ rather than a primary source of data.

The key here is to put people in the loop when interpretation is required. This is exactly what Dakworks is all about.

Thanks for reading,
Dak