3D Printing is in your Future

I’ve been watching 3D printing evolve for a number of years now.  I first started hearing about it almost two decades ago, and like most people my initial response was that it sounded like science fiction.  A few years ago, a friend of mine started a little business where he bought his own rapid prototyping machine and started to rent out time on it, mostly to manufacturers who needed a prototype, but also to the movie industry (like most people he abandoned the movies when he could).  The quality was never quite what I would like to see for my own purposes, but last year I figured the quality available was sufficient and I actually went to an RP service bureau to get something that I wanted.

Then this year, HP announced that they’re getting into the 3d printing market, and will be partnering to produce their own 3D printers.  Initially these are going to be aimed at businesses that used to go to my friend to get a prototype, and perhaps at architects who used to go to another friend to get hand-crafted models built.  One day, however, they are going to be aimed at you and me.  And we’ll both get one.

We’re about at the point we were 25 or 30 years ago when laser printers were becoming available.  Nobody had a printer in their house in 1979 and there was no market for in-home
printers. Why would you need one?  You might have a typewriter if you were inclined to write to the newspaper, but a printer – that was for making multiples.  Now everyone has a laser printer, and many of you have a laser printer that prints colour.  Mine sits idle for weeks at a time, and we probably go through a package of paper every two years, but I have one.

A similar trend has emerged in photocopiers. 20 years ago, you had to go to the library or an office to find a photocopier.  Now many home printers double as photocopiers.   Today if you’re at a friend’s house and you want a copy of something (that isn’t already digital) they say, “I’ll go make you a copy.”

Just like laser printers, why would you need a 3d printer today?  You might have a few tools if you were inclined to be handy, but a 3d printer – that’s for making prototypes for injection molding.  But what if you could wake up one morning and say, “hey, I want a charging stand for my new iPad, but I’m too green to drive to a store and shop for one.”  So you go online, where there is already a growing open source library of 3D designs for stuff (see Google’s 3dwarehouse for example) and find that some kid in Iowa (why is it always a kid in Iowa?) has already created a design which is close to what you want; you download it, modify it and have your charging stand all set up by the time you’re finished your coffee.

That would make everyone I know want one.  And that would make a market.

With a market like that, we’re absolutely going to see the quality improve and the cost come down, just as we did with laser printers and photocopiers.  This in turn will make more kids in Iowa make more designs, and more people will want to print them.

It’s interesting to think of what a world with pervasive inexpensive 3d printing will look like.  Would people be likely to customize designs to fit their lifestyles?  Could we distribute manufacturing so that many things are assembled in your neighborhood rather than shipped around the planet?  Will we repair more than we discard or will we be buried under a sea of iPad charging stands?

I can hardly wait.

Seth Godin’s Book and the Rise of the Artisan Class

Two events coincided last week that lead me to believe that I might never buy another book.  I love books – just look at our shelves, and they confirm that we, as a family, are addicted to them.

The first event was, of course, the confirmation that Apple was planning to change the publishing business with their long-anticipated iPad.  At Christmas, I had been thinking of getting an eReader for the main reader of fiction in our house, and if we hadn’t blown the budget on a puppy (not the bad impulse kind of puppy, but the planned type that just happened to be ready to leave her mum in November) I would have.  Unfortunately, most eReaders today are not optimized for the non-fiction, technical and history books that I mostly read; they don’t even do magazines well.  But the new iPad looks like it could work for those too.

The other event was when I started a second layer of books on yet another shelf.  The book was Thomas Friedman’s “The World is Flat”, which is also significant, because if that book doesn’t make you think about your place on the planet in a new light, you’ve either already found your way to make a living in the Flat World, or you’re already dead.  The catalyst was Seth Godin’s book, released last fall as an eBook, a page of which I printed and pinned on my office wall. I thought as my eyes flicked across the page admonishing me to excellence that I should really read the rest of that book, but I probably never will.   It’s going to languish on my eBookshelf because its format lends itself to browsing – it’s a perfect bathroom reader – than to reading (I see that it’s now available from Lulu as a hard copy).

So Seth’s book is an example of the kind of book I might actually buy after the rest of the books turn into eBooks, if only I bought that kind of book. Magazines are more my style when it comes to dipping. Sadly, it’s going to be years before we have a washable eReader; even so, I’m absolutely looking forward to that future.

Another place that’s ideal for this sort of book is of course the coffee table.  Now, despite a surfeit of coffee tables in our house, I do buy coffee table books, but not from any ordinary book seller.  The coffee table books I’ve bought for the past few years are photo books containing all the good photos from the past year alongside a transcription of my journal.  I make one for my family, and an abridged version for Christmas gifts.  For the past two years, this has come from blurb.com, and the cost is surprisingly not that much more than a comparable mass-produced book — perhaps 50% more.

As I say, these are not your standard coffee table books that you might get from Indigo or Book Warehouse.  So do those books stick around?  They might, but I think there’s a really interesting opportunity at the intersection of my annual journal and the large-format photo book you find in Indigo.

My friend, Dan, is currently vacationing in South America.  He has an amazing itinerary that spans five countries and includes things like diving with hammerhead sharks and hiking the Inca Trail (if it’s still there).  What if he came home and could assemble a book of not just his own photos, but beautiful images by professional photographers curated and lovingly edited and captioned by people who know all about hammerhead sharks and the Incas.  Well, that would be an amazing coffee table book that he would cherish for the rest of his life.

Frankly, although he’s full of surprises, I can’t see Dan putting such a book together.  He strikes me as more of a directory full of photos kind of guy.  I wonder if he’d pay to have someone else do it?  It’s even conceivable to largely automate the process – he could put in his itinerary, the system would sort his photos and choose the best ones (judged by focus, saturation, exposure), get the relevant boilerplates on the Incas and hammerhead sharks, and assemble it all together.  He then goes in and removes the bits he doesn’t like.

For a little more dough, he could have someone else look at his actual photos and choose the ones that are artistically best, or ensure that every friend is represented at least once.  This would reduce his time commitment and make a busy guy like Dan happier.  Then for an extra special book, like this one, he could have a book binder create a custom binding for his book.

The process makes an opportunity for a number of artisans to collaborate.  First there is the photographer who takes the stock photos, then the editor who collates them, the writer who creates the captions based on knowledge from experts.  All of them come together to create the sections on the Incas and the hammerheads.  Then, there could be a personalized editor and finally the book binder.

Would there be enough Dans to provide for the Inca and shark experts, or the book binders?  That is a good question, but the experts are making a living today on mass-produced books, and so, it is surely equivalent to make a living off personalized books.

What it all depends on is a mechanism that allows a group of artisans to come together to collaborate on the digital assets.  Then there is a workflow involving a company like blurb to create the hard good, itself.  If these things were in place, then it would transform not only the book publishing industry but many other industries as well.

I can hardly wait.

Architecture or Design

We’re looking to hire an architect these days, an enterprise architect to be precise, and one of the questions I’ve been asking people is what is the difference between architecture and design.  Nobody has come up with my answer yet, and so, I’ll post it here and see if that improves the odds.

Much like the standard answer regarding the difference between a program and a script, the standard answer is deeply unsatisfying.  Most people, when asked about the difference between architecture and design respond that it’s about the size of the components being designed.  Generally, folks are pretty sure that design at the class or method level is definitely design, while figuring out how processes work together, especially over distributed systems, is definitely architecture.  Where is the line, though?  If I package my classes together into libraries, and think about them at that level, does it now become architecture?  What if my system happens to consist of two short batch programs that write and read a file, perhaps across a network, is that enough to be architecture?

The question of design or architecture is an important question to consider, not because we’re hiring an architect right now, but because one of the questions that developers rightly ask as they become more and more proficient is “what do I need to demonstrate in order to become an architect?”  The short answer is that minimally they need to demonstrate some architectural skill, but then it’s really hard to define exactly what that is, and how do you compare one person’s architectural skill with another’s.  It’s even harder to tell them how they can go and get some architectural skill!

Thinking merely about the size of components doesn’t help those developers because, well, what’s big enough to be considered architecture?  And anyway, what specific skill is it that you expect them to pick up as they become architects.

The specific skill that separates design from architecture is considering the business side of the technological proposal.  Specifically, a designer who is thinking in terms of initial and ongoing costs of their solution, and whether the value delivered by the solution is sufficient to warrant those costs is doing architecture.  The designer who draws components on a whiteboard, no matter how grandiose those components might be, is only doing design until they start thinking about the implied costs.

Thinking about costs leads to all the other aspects that usually fall into solutions architecture.  In order to understand the initial build cost, the architect has to make sourcing decisions.  Hardware costs come from the deployment view of the architecture, which means the designer needs to understand how scale and fault tolerance will be achieved.  The distribution model and the data architecture imply network costs.  A design that includes manual step in the business process will incur ongoing labour costs, which may or may not be justifiable relative to the initial build cost.  An architect who isn’t thinking about these costs in relation to the business is only doing part of the job, and their solution while technically superb will fail.

Note that the intuitive answer still works.  Design at the class level rarely has real cost implications.  Design at the component level, on the other hand, often does.  The design that specifies two short batch programs that access a file over the network might be architecture, but probably not a very good one.

So, when your developer is asking, “what do I need to do to become an architect?”  The answer is not, “draw bigger boxes on the whiteboard,” but something along the lines of “talk to me about the cost of your solution, what other approaches did you consider and what would their relative costs be.”  Get your developers to think in these lines, and they may grow up into architects who deliver successful solutions.

When Someone Leaves

It’s a fact of life that people will quit your organization.  If you’re doing your job as a manager, you should have expected this; few people leave on a whim, and the warning signs stretch from complaints to repeated dental appointments with no apparent improvement in the smile.  Still it often comes as something of a shock when the day finally comes.
The first thing to remember is that it is almost always positive for both the employee and the organization.  The employee is leaving for something that is surely perceived to be an improved personal opportunity.  The organization, no matter how key the individual might be, will find a way to recover and will be stronger because of it.  There will be a short period of adjustment, and then you’ll adapt.

I once worked for a company that asked as soon as the letter came, “Can we save them?”  Sometimes we could, but inevitably, once someone is looking for a new job, they have effectively already left.  Whenever we saved them, they continued on at reduced performance for a few months and eventually left anyway.

Incidentally, having seen the other side of the same coin, the reverse is true.  A company that promises to reform itself to keep you probably won’t and you’ll be looking for work again in a few months.  And extra cash only makes you feel better about the personal sacrifices you’re making to come into work for a little while, and then the underlying reasons come back to the fore.  So, if a company is trying to convince you to stay, then remember that it’s only going to be for a few months anyway.
So, you’re going to lose staff, and while I suppose you could have a current succession plan in place for everyone who you consider a retention risk, you probably don’t and in the end, you only have two weeks to deal with the disruption.  At one place I worked, we developed a formal process for dealing with this.  It wasn’t that it happened frequently, but rather that it happened infrequently, and bungling an exit was expensive.  We wrote it down because when you lose someone you sometimes feel like panicking, and having a process quells panic.

The first step is to acknowledge to yourself that the person is leaving.  As I say, there is nothing that you can do to avoid this, although you can postpone it.  You should first congratulate them on either finding a new opportunity.

It is reasonable to inquire where they’re going, as I suppose this could impact how you treat them for their notice period.  Often salespeople who are going to a competitor, for example, get walked out the door in a vain attempt to reduce the damage.  However, realistically, they are taking their customer list with them, and they already have it filed somewhere.

You should also look at this initial meeting as an opportunity to learn.  Is the person leaving because of you or the organization?  How can you improve so that others don’t leave for the same reason?

Once you’ve satisfied yourself with the conversation, it’s time to start getting the word out and planning.   You should talk to the employee to ensure you know everything they do; especially with long-standing employees, you may not know it all.

You need to tell all the internal people who will be directly impacted by the change, find out what their view of the impact will be, and work with them to come up with a near-term and medium-term plan to manage that impact.  Hiring falls in the medium term.  Reasonable near-term plans are hand-off to existing staff, documentation and deferral of responsibilities or termination of responsibilities (you can stop doing things).

By the end of that first week of work, the plan should be known to everyone internal, and you should be starting to communicate it externally.  Your customers and suppliers need to know there is a plan and that the situation is under control.

The second week should be completely about implementing the plan.  I wouldn’t expect the exiting employee to do much more than to think about their new opportunity.  If there is hand-off to be done, they should be doing that early in the week, and overseeing the newly responsible person as they do it by mid-week.

At the end of the second week, you should have a leaving party.  Everyone needs an opportunity to say good-bye, and this party is more for the folks who are staying than for the one who is leaving.

Availability: it’s expensive

I was jawing today with a developer who wanted to build something a little more robust than we needed it. He didn’t do it, but he thought it would be interesting and fun (the root of another blog post one day, perhaps).

The thing is, generally cost is proportional to something like the exponent of the uptime requirement. This is why uptime is so often expressed in terms of percentage: if 9% uptime costs 1 dollar (say), then 99% costs 10 dollars, 99.9 costs 100 dollars, 99.99 costs 1000 and 99.999 costs $10,000. Now think of what an underpaid junior developer can develop in under 6 minutes, because that’s what you can build robust enough to stay up for all but five minutes per year for $10,000.

Don’t believe me? I bet your junior developer could develop something that continually writes incremental integers to the screen in six minutes. Now, how would you make that survive power failures, screen failures, how about hot-replacement of parts? Yeah, now you’re talking about $10,000.

A couple of questions to consider in acquisition

When your CEO goes to buy another company, the chances are they’re going to ask you, their trusted technical advisor, to have a look and decide if their technology is worth acquiring. Now, I’ve never heard of an acquisition stopping at this point, but I suppose it could affect the offering price. Here are some questions that are relevant:

1. How is the company protecting their intellectual property? What patents does the company hold? What are the relevant patents in the space, and why does this company not infringe on those patents?
2. How much can the company and their systems scale? Can they readily accommodate the increased demands of an amalgamated company? What are their plans for scaling beyond the handful of customers they have today?  Has this scaling been proven?
3. What is the state of the company’s equipment?  Is it leased or owned, how much life is left in it?
4. What are the development processes that are currently in place?

Any company should be able to provide you with a number of architectural diagrams.  I would look for logical and deployment views to get you started.  There should also be a good entity relationship diagram for each database.

Colour – The CTO Weighs In

I guess colour is a key aspect of a brand. All the companies I’ve worked for have spent huge sums identifying the exact colours that they will use to represent themselves. Then the marketing department hires a small team of brown-shirts to police that palette.

So, you’d think they would have really tight control over what exactly that colour is.

Unfortunately, colours are decided by marketing people, usually under extreme pressure to complete the project and they don’t think ahead to the technical requirements of the job. And the one technical requirement that we have of colour is to know exactly how to reproduce it in a variety of contexts.

Now, I’ve just had an interesting experience reviewing our brand book, because we wanted to get our particular colour right on an online form. Sadly the brand book contained only CMYK and Pantone colours — useless online — which lead me to a colour converter, and ultimately to the Pantone website. If you think for five minutes, you can use the Pantone website to convert a Pantone colour to their suggested RGB value. The very strange thing is that none of these colours matched: they didn’t match by value and they didn’t match by looking. So, we were no further ahead, apart from an interesting dicussion with the local colour nazi, who gave us the colour he uses — another county heard from.

So, if I’m ever working with a company that is redoing its graphic standards, and I have a chance to affect the graphic standards, I am going to try my best to withhold judgment about the chosen colour: there will certainly be enough executives squabbling over that. However, I will insist on the following:

1. Do not accept only print-centric colour spaces! The agency owns a copy of the Pantone Color Bridge, and should at least give you the Pantone RGB, HSV and other versions of the colours .

2. Test the colour specifications suggested, rather than accepting that they look like the graphic standard. Bear in mind, they will appear different on different types of stock, under different lighting, with different monitors. But you should be able to get something that looks reasonably close.

Budgeting in MS Project

Until now, whenever I have wanted to build a budget, I have always used Excel, as I’m pretty sure everyone who doesn’t use paper does as well.  Lately, I have been revising my budget for the fiscal year, which consists of many many projects and opportunities.

It’s a lot easier for me to try to estimate project costs using MS Project.  I can think about a single project, the tasks that are involved, who would have to do them, and the dependencies between them.  Furthermore, MS Project makes it relatively easy to add up the number of individuals of a certain type you’ll need.  So that’s how I started out, fully expecting that I would take the projects and their costs and paste them into my spreadsheet.

However, when I paste it into Excel, I lose all the dependencies between projects: it’s hard to show that three projects share a common pre-requisite.  Not only that, but if I think further about a particular project, refining the numbers, I would then have to go back to Excel and update it there (hmm, I wonder if a .mpp can be a data source for a .xls?).

So, I decided to stay in Project.  I was pleasantly surprised to find that I could change all my resource hourly costs to negative numbers, and Project behaved the way I expected.  Then I started thinking about benefits.  I’m entering the benefits as positive numbers under the same project.  Projects that wind up positive should get the green light.   I still have a slight difficulty with those prerequisites because they never get a positive number; I suppose I could apportion some of the dependents’ revenue numbers to the prerequisite to get them to happen.

The one benefit of a spreadsheet-based approach is that I can use formulas to figure out other costs.  For example, every developer comes with training costs, workstations and doughnuts, and I would really like to show those costs separately rather than burying them in the loaded cost for a developer.  So far I’ve not figured out a way to make MS Project do this for me.  If I figure out how to make it a data source for Excel, though, I’m off to the races!

One Big Message?

This is the scenario: periodically, one component is going to look for objects that satisfy some criteria and tell the others. For example, perhaps it is the accounts whose billing anniversary is today. A bunch of other components are interested in these accounts, and so we’re going to send a message out that they can subscribe to and be notified of billing anniversaries. Clearly the initiating component is going to do a single query and get back a big list of accounts; should it send out a single big message, or many small ones?

Ordinarily, when one component is talking to another, I like to see as much go into each message as possible. This was a lesson we learned back in the days of CORBA (which I realize may not be completely over everywhere) when, based on some particularly optimistic advice from authors who had apparently never actually built more than sample code, everyone I worked with was composing interfaces for inter-process communication that exposed miriad small methods. The key to killing performance of distributed systems, it turns out, is to make communication synchronous and chatty so that the communication overhead dominates the payload. Maybe this is what killed CORBA for so many people; I have no doubt their early experiences with performance sewed some initial seeds of doubt.

However, in this case, we don’t have the same scenario. First of all, we’re talking about asynchronous communication. So, while we would add communication overhead by going with multiple small messages, it’s overhead that will only affect total processing resources, and not latency of individual requests. On the other hand, there is quite a bit to be gained from using multiple small messages –

• we can route and filter the individual messages based on their contents.
• we can scale the message processing by “simply” adding more sinks.
• we can be much less clever about interrupted processing: the sink consumes each message in a transaction, and so, a failed transaction will be restarted automatically (perhaps by another recipient)
• the constant-size messages mean that the sink does not have to scale. So, if we have a simple in-memory reader for the message that works for 20 accounts today, the same reader will work tomorrow when we have 20k accounts.

It’s a small question in the grand scheme of enterprise architecture, but all these small things add up.

Perhaps the next question is: how small is too small?

Scripts and Programs

What’s the difference between a script and a program?

Most people to whom I ask this question jump at the idea that a script is interpreted, and indeed, the Wikipedia page on scripting languages currently makes that distinction.  However, there are lots of interpreted programming languages — Basic, Prolog and Smalltalk all leap to mind — so that can’t be it.

So then, most people tend to say something to the effect that scripting isn’t serious, while programming is.  Well, that might be true, but it also has huge implications!  If scripting isn’t serious, then is there any need to apply proper software development practices to scripts?  Do you need to keep scripts under source control?  Do they need requirements?  Do you need to test them thoroughly?  What about documentation?

The assumption that scripts are not serious has serious implications to an organization’s stability.  Organizations that don’t value scripts wind up with a host of arcane code snippets sitting on servers, known only to a handful of sysadmins who have composed them and shared them with others.  When those sysadmins leave, their tools whither in lost directories and the organization breaks.

My own definition is this: a script is a sequence of instructions that is only intended to run once without modification.  Any script that you plan to use more than once is a program and deserves to be treated and cared for with the appropriate respect.

This has the interesting side effect that you can write programs in languages that are called “scripting languages,” and may, like JavaScript, even have “script” in their names.  Perhaps I am swimming upstream, but I would say that the standard definition is useless and indeed dangerous.

So don’t tell me, “there’s just a little script that runs nightly and downloads the billing information,” when what you mean is “there’s a critical csh program…”  Such scripts deserve all our respect!

Blogged with Flock