warpedvisions.org

Somehow I missed the recent larger EC2 unit sizes:

When I saw this, I immediately thought: these numbers will have K, M, and G suffixes within the next 5 years. Compute units will be sold as 88 mega-ECUs. Imagine 88 giga-ECUs?

The ECU is similar to our old measure of computing: boxen (except more virtual). The idea of giga-boxen boggles, but is inevitable (boxen is so much more inspiring than ECUs), or maybe it should be boxels?

My best guess is that K-boxels will be available within 2 years, M-boxels within 4, and G-boxels within 7. By the time my kids hit university, we'll be working with giga-scale utility computing units.

In the words of the great philosopher Ted Logan, “Whoah!”

Giga-boxels!

#Weblog

You start the day finding consciousness. Slowly or quickly, it doesn’t matter … you become aware of the world incrementally. Maybe you hit the snooze button once? Twice? Or maybe you wish you did. If you’re like me, you’ll find some caffeine and make the trek to work.

And if you’re lucky you will find yourself in your office quickly, alert, and ready to go. You work your way down your list of tasks until your customers, coworkers, or biology interrupt you. It may be minutes. It may be hours. The question is, what do you do when you’re interrupted?

I have a suggestion. Do just one more thing. If it’s not rude, do another. And another.

This is how things get finished: by doing them when the doing is good. And moving just one more inch gets you closer, while you’re brain is focused, and before you get pulled into something else.

Of course there are other tricks to getting things done. Doing the right things, for example. Working with a healthy mind; finding ways to focus and hone your skills. But doing just one more thing is an easy hack that works wonders.

#motiviation

While writing a spec earlier today the last few years of progress in server land hit me: uptime is a facade.

In the early days, server resources were expensive and scarce. Uptime was sacred. Long running hardware was celebrated, UNIX tools were born, beer was consumed.

The problem of focusing on the hardware is that it detracts from the time you spend developing software. Remember those late nights configuring RAID setups? What about hunting down faster drives, or terminating SCSI cables?

With utility computing like Amazon Web Services, hardware no longer exists. Slices of computing are sold by the hour, by the byte, and by the feature. Provisioning is nearly instant, and can be controlled by API, from any machine connected to the net.

Machine uptime doesn't matter. It's been replaced by ubiquity.

It ends up that service uptime doesn't matter either. Instead of thinking about keeping continuous instances running, we need to focus on ways to make it easier to replace instances, and mechanisms for pooling service resources in ways that fail over gracefully.

As the cost of swapping servers approaches zero, it becomes the ultimate form of stability and parallelization.

While I was thinking about uptime tonight, an impending software update threatened the honour of my computer. My first reaction was to avoid running the updates: this machine was nearing 3 months between reboots.

#Weblog

I'm a bit surprised that the argument over tables versus semantic layout is still floating around. It ignores the obvious:

• Any set of nodes can be rendered like a table
• Any table node can be rendered like a non-table node

There is no difference between a <div> and a <td>, except for the default layout settings and nesting. The major browsers support the distinction with the display: table-cell; and its important variants, so it's a matter of how you want to organize your data.

The argument is really semantics versus easy pixel perfection. Sub arguments include, “Do I really want my site to adapt to various handheld sizes?” and, “Screw accessibility, I like my pixel perfect layouts, thank you very much.”

The whole discourse ignores where the W3C is aiming HTML5, which is to use things like section, article, header, footer, and nav. These tags are much nicer than <div> or <td> soup, at least to me.

But screw semantics, you want your perfect little px layouts.

The complaint about pages that use positioned or floated blocks is the “difficulty” in rendering the classic column layouts. You know, the column layouts that don't behave like newspapers (text doesn't flow between columns). And guess what? These classic column layouts are based on—-wait for it—-the table layouts of the 1990s. HTML1, without any stinkin' CSS. We did what we could then, with the tools we had.

Of course real column layouts are possible now with CSS3, where text and headlines can flow between proper columns, where you can control flow (roughly at least), and where you can make the columns look like real print columns. And reasonable faux-tabloid-sidebar-content-sidebar layouts are easy to build without table blocks, if you absolutely must have them, and you're still free to use table block rendering if you're so inclined.

But people want their pixel perfect, hey-look-I-can-use-Photoshop layouts, without having to work for it. These people miss the point of putting stuff in a browser, which is, “Hey, look, people can view this stuff in browsers of all sorts on hundreds of different hardware and software platforms!” You get a huge potential audience at the cost of easy pixel perfect layouts.

You can still churn out perfect layouts with all sorts of hacks and caveats, but the argument for putting things in tables is mostly unrelated. There are other ways to get the same effect, while making your content make sense to your future self and automated tools of all sorts. And there are better ways to get a good effect while supporting a wider range of browsers and tools. Fluid layouts are way more interesting anyway, as they work in more browsers, more usefully, and with less work.

Tables have their place, of course, for things that are actually tables of data. Even then, you could use paragraphs and headings if it made more sense for the content.

So it's really pixel-perfect and familiar versus ubiquitous, useful, and semantically meaningful.

It ends up it's all about the data. Make the data obvious, and everything else falls into place. HTML5 has enough semantic and layout expressiveness to wrap data in a way that is obvious and easy to make look good.

</rant>

#CSS #Programming

I had an epiphany early this year: getting good at something isn't about finding a groove or being especially clever, it's about honing a method of doing something. Or lots of methods, meticulously crafted, carefully practiced, and well executed over and over again. That's it.

The problem is in discovering the method. It's harder than you expect.

It turns out that most things, while easier than you'd think, are much different than you'd expect. The process for making an excellent curry, for example, is nothing like what I had imagined, nor is the path to better photography, or art, or anything. Finding methods for things is in itself curious, and my methods for getting to good versions of things is always unexpected.

Software and web design are no different: they're not difficult, but the path to become competent with them is nothing like what I dreamed when I was younger. I found that it's mostly about discovering and repeating methods of doing the parts of design, and spending much more time polishing than seems intuitive. And while getting feedback can teach you something, curating your own design sense pays better returns. It's all in good taste, practice, and polish. Seems simple, no?

A pattern emerges

Earlier this year I was thinking back on the various redesigns of this site. My approach to design has changed, as you would expect, but more interesting: it takes a lot longer now than it did 15 years ago. What I found was that design gets better the longer you polish it, and it becomes exponentially better the more times you're able to distance yourself from it, which allows you to actually see your design as others might (and this is the real magic, the seeing).

The trick with design is in finding perspective, and taking the time to polish it. And many of the methods I use now exist explicitly to look at a design from different viewpoints. I had to discover these methods, practice them, and only after that could I start to produce even mildly competent designs.

With cooking I found that it was so much simpler than it looked. Basic flavours and layering techniques are incredibly similar around the world, the only differences are in the available ingredients and how you mutate the dish with heat. The hard parts of cooking are in mastering the most basic of skills, and in the preparation and timing. The actual cooking and inventing new dishes is as simple as adapting what everyone else is doing around the world.

Photography? It's only two things: interesting composition and lots and lots of photographs. Everything else is bullshit. It took me years to realize that I would throw out most of my photographs, and that sometimes I would take a shitty shot and turn it into something interesting, and that if I didn't that life would go on. And life does go on, and sometimes I impress people with that one picture that sits on a pile of garbage shots. And sometimes people like the shot that I think looks like shit.

And art? Art is one simple concept: make peace with failing over and over again, searching for that one thread of interesting. Once you find it, you obsess over the methods that got you there, repeating and varying it as much as you can. But the key is that you have to fail over and over again. Who expects that? And if you hear it, who believes it?

Unfortunately you have to discover the meta principle yourself. And fortunately these unexpected things are all related, as art, design, and life are all one thing.

The critical factor is that doing something well has an unexpected path. You might know what works well, as in you like that curry or that photograph—but doing it yourself means discovering some counterintuitive principles, and repeating them, practicing their constituent parts, and then cherishing the path that got you there. Over and over and over again.

It's not that these tools and techniques are bad in themselves, but our use of each should be fit into a well tuned approach to building software. An entire project delivery should be tidy, professional, and complete.

There are a few causes to the problem of organizational buildup. Our software is limited, our methods need improvement, and the unseen pieces of our project pile up and are left a mess once we ship. categories: rants

TODO lists, project management software, and GTD all have the same basic problem. They push you to produce things that aren't your end goal, to help you improve your focus, thinking, and (in the end) produce better quality software in less time. These artifacts clutter your archives; the very things that help you create more effectively get in the way. They're a form of noise to your project's signal.

It's not that these tools and techniques are bad, but our use of each should be fit into a well tuned approach to building software. An entire project delivery should be useful, professional, and complete.

There are a few causes to the problem of organizational buildup. Our software is limited, our methods need improvement, and the unseen pieces of our project pile up and are left a mess once we ship.

Everything is a file

Our tools treat each of our artifacts as equal. They're generic, as there are many approaches to managing projects, so very few assumptions are made about the importance of each piece of the process. Requirements, specifications, prototypes, estimates, and development plans are strongly interrelated, but few tools are able to capture this.

Even the application structure of project management and software development tools re-enforce the everything-is-equal by placing features in tabs, sections, and tree nodes similarly. While it's easy to organize product features into tabs and tree nodes, it keeps them at the same level of importance by default and we have to work to tame the mess.

A polished specification is much more important than the research and prototypes that fed into it. A completed user interface design is superior to the sketches and feedback that improved it. Our tools, however, rarely help us focus on these differences.

Rushed and unfinished

Our own methodology—our process of analysis, design, and development—contributes to the chaos of project bits. We don't like to fund (or spend time) on things that aren't part of the output, so prototypes, design documents, and specifications remain unfinished and unpolished.

We also produce, and subsequently discard, various artifacts as we're learning the process of building better software. These forays into improvement leave a wake of debris that is unlikely to be used again. This is a failing of team management and individual process: we just don't put enough emphasis on picking successful tools or polishing and curating the prerequisites.

Projects need teams that have a winning approach. We should not be exploring process on project time (side quests are better for this), and hence the exploration and failure of various processes should be insulated from active work. Why practice at game time?

Cooks who cannot clean

Our tools should serve us better. Our own methodology should avoid processes that fail us. In the end, though, we shouldn't leave the mess behind. Each member should take pride in what we deliver, including the parts unseen: the designs, specifications, drawings, models, and all the supporting pieces.

Our methods and techniques are not unfortunate side effects in building software. They are what's involved in building software. We sketch, we design, we carefully consider each piece. These supporting activities are not lesser to writing code, they make writing code better.

Less is more

There are many great reasons to use better tools, to understand the process of building software, and to curate the entire effort. We know that it improves communication, reduces bug rates, and reduced project costs. We know that it makes for better software. And yet we end projects late, incomplete, insufficient, and in a mess.

Let go of the tools that do not work. Ignore the processes that are obvious losers. Obsess over ways of documenting design that take less time, and produce something useful. Learn to write better, make your sketches count, and don't leave a mess at any time. The thinking that goes into your software is the software.

Know how to build software. Sketch, document, and plan. Be proud of the method of building software, and curate the in-between steps. Spend time between projects improving your process; finding ways to do less and better. And above all, curate your thinking and the things you record your thinking with. What you produce will be better for it.

#SoftwareEngineering #TheArtOf

So you can't write. You're empty, tired, and unfocused. You've tried exercise, meditation, caffeine, binge sleeping, and a dozen other cures—but nothing comes out. And when you do happen to squeeze out a few paragraphs, you stall, spiralling further into your uninspired daze. You are burnt out.

Writer's block and burnout are the same problem: undue mental exhaustion brought on by overuse, misuse, and other stress. It's important to understand that you cause your own burnout, either directly through your actions, or indirectly through your lack of action. It's your choice.

While it isn't just writing that's affected by burnout, writing is one of the fundamental skills subdued by mental exhaustion. If you can't write, you can't design, create, express, or inspire. For me, writing is the real measure of my creative mojo.

It's a sticky problem

Don't worry about the root cause of your exhaustion. Your job and your life have very little to do with how you react to stress. Your reaction to stress might feed your exhaustion, but learning to dodge them are only a temporary measure. The real problem is that you're stagnant, stuck in a place where you allow these natural forces to erode your being. While the erosion might cause the burnout, allowing it at all is the real problem.

Your goal is to get unstuck. Ignore the bullshit of addressing stress and the remedies that promise to manage it. The stress doesn't matter. Your balance isn't important. You need to get unstuck. You need to strengthen. You need to create.

Don't try to find balance. Balance isn't something you can concentrate on; it's what happens when you become stronger, when you create things, when you polish them, and when you enjoy the result. If you focus on balance, you'll find it impossible to stay balanced at all. Let balance happen.

Don't try to focus. It's not something you can do directly, rather it's what happens when you do. Build something. Learn to perform each step well. Train yourself to understand the history and science behind each concept. Enjoy polishing each piece until you're proud of it. Just do it. The burnout melts away.

Skills are fundamental. Skills are required to do, even if secondary to the doing. Learn, practice, and play regularly in the domains that matter to you. This is a form of doing that precedes and complements the act of creating things.

You need to learn to develop your skills as part of your regular regimen. You should include it in your project work, when things you're building require better understanding. You should also include it in those times where it's not practical (or possible) to create. Between projects, when especially demotivated, and when the opportunity encourages it.

Doing is all that matters

Burnout is the result of becoming stagnant and the natural erosion that results. You can't cure burnout by coping with the erosion, you transcend it when you make the erosion irrelevant. Grow, practice, and do.

Just do it. Do it well. Do it now, and repeatedly, and with passion. Throw yourself at making things and understanding every part, until you breathe their essence. Enjoy the process of practice, in a way that complements your work. Everything else ceases to exist as you grow stronger and do more.

#Weblog

I've become passionate about design. It's a subtle craft that says something, things that can't normally be said with words. It suggests things. It implores us to think in a particular way. It encourages us to go here or there. It is enough of a metaphor to be easily recognized, but not so much that it becomes tacky, unless of course tacky is the thing you need. Design is the artful side of craftsmanship, the soul of a thing.

I was talking about design the other day with a friend. “How do I get into design,” he asks? He already has the passion for design, he sees design, but he lacks the processes for finding, honing, and pushing designs along into to production.

How do you get into design? You need to see it first. Feel it. Then you do it. Again, and again, and again. Floundering, failing, and fumbling your way through at first. Is there any other way to learn to ride? To swim? It's a craft that requires balance and grace, and some amount of time to learn to execute well. And that's okay.

How do you get into design indeed! Find your passion, as it fuels the process. Passion is simple too: focus your frustration, awe, and excitement for a thing into a narrow band of optimism and spunk. It can always be better, and it can always be solved. It's just a matter of seeing it, boiling it down, and then actually doing it.

Passion starts with comprehending that a thing isn't working well enough. Then you imagine what it could be, what else has been done—-what hasn't been done yet—-and let your mind iterate over the possibilities. You eat. You sleep. You shower. You read. And at some point you see it, as if it were magic.

You'll see many visions of what it should be (many of them good). Later you'll learn which visions are better, and which are worth chasing after. But find your passion first, then learn to listen to it, to ignore it when it's wrong, and to trust it when it's onto something.

An example

I love reading. Great inspiration can be found by streaming in the things other people write. Books are especially excellent, as the format turns out thoughtful, polished experiences. Buying and finding books, on the other hand, is something I often find frustrating. It's an investment of time and money that can result in a growing pile of carefully bound recycling. Books you feel compelled to keep (but likely will never read to completion).

Now there are bookstores and libraries that make finding books a better experience. You know the sort, comfortable chairs, brilliant selection, and a staff that know the product and who love to read. These shops are gems.

Enter Amazon.com. It's a store with incredible potential. A huge collection of titles. Reasonable shipping, easy book downloads, and a sturdy site to run it all. But it doesn't work well and it's not very inspiring.

My favourite book store isn't much to look at, but it's organization is incredible. The shelves were built by the owners in a way that showcases the right books, providing an archive for depth, all while being easy to navigate. The owners themselves are avid readers, having read most everything I've asked them about. They haven't just read most of their inventory, they usually know exactly where it is or when they'll get it in next. And if you want a recommendation, they remember what you've read so that their recommendations are only a few steps from clairvoyant.

Amazon isn't much to look at either. In fact it's downright noisy. Dozens of things mashed into every page, making it difficult to find what you want. While their selection of print books is excellent, many of the books are not available for download. The result is an experience that isn't fun or inspiring. In fact, I often avoid it until I'm absolutely out of reading material.

Amazon could be so much more. It should be the comfy bookstore you want to browse. It should be the eclectic owners, their pristine organization, and the recommendations that leave you wondering if someone knows just a bit too much about you. It should be effortless, not leaving you wondering if something will be available for your mobile device in your region. It should feel like the perfect bookstore, melting away to trade your money for a lifelong experience of losing one's self between the pages of whatever turns your crank.

But it isn't. Buying books online is mostly worse than queuing up at your local mega mart, innundated with impulse items, inexperienced staff, and bright, over-saturated displays and lighting. Limp, uninspired, grating a bit on your nerves. You shop there when you have to, but the result is uninspired.

The first part of design describes that feeling, the way a thing should be front to back. The real world things it needs to bring to you, to make you feel. And the real bits of functionality that it absolutely must have.

The second part of design is in describing and making it happen, but that is something best talked about after digesting the first part. So go on, digest.

#Design

If you want to get better at something, do a lot of it. Throw yourself at practice and real chances to do it.

When you want to become great at something, stick with it, obsess over it, and suck up all of the knowledge that surrounds it.

And when you want to become truly incredible at something, you need to invert your thinking: reflect on the fundamentals, write, and do anything that lets you define what that thing is.

Then lather, rinse, and repeat.

#HOWTO

I know a few generations of developers. I find they tend toward different ways of thinking about software design, based on the languages and decomposition tools that were available at the time they formed their thinking. Their tendencies shift over time too, but often their imaginations are limited by whichever mode of thought they're working in at the time.

By design I mean the approach to solving a problem with software, including software architecture and low level design (not product, visual, or UX design). These are another universe around how we think about solving people's problems with software, a topic for another set of posts.

I realized the other day that design thinking follows an evolutionary path. It progresses to solve larger problems in better ways, and is based on layering and combining the various tools and techniques available.

A maze of twisted pathways

1. Flowcharts and pseudo code
2. Data diagrams and relational algebra
3. Eventing and state diagrams
4. Object diagrams and trees
5. Layered architectures and approaches
6. Partitions and service maps

The thinking moves from direct low level constructs toward more abstract solutions, based on less obvious symmetries and fissures. A flowchart, for example, is a direct mapping of instructions. A set of services and domain partitions is far less direct, and often maps to important constrains like scaling, performance, and cost.

Well, duh

It's obvious that our thinking has changed as software becomes more complex. What's interesting is how we get stuck in particular ways of thinking, and how difficult it is to translate between the various design approaches. A procedural solution is a very different beast than one based on intersecting data, and is very different again from a set of disjoint services for the same concepts.

To talk about design intelligently, we need to lay the groundwork for how we plan to cast the approach. More than one design tool can be used, but it's important that everyone participating in the design understands how to think and discuss things cast using that particular approach.

#Design