Rockhopper Digital

Errors in Conceptual Design

2013-03-05T09:02:00Z

Learning from the Poor Judgment of Paconius

In “Design Paradigms: Case Histories of Error and Judgment in Engineering,” Henry Petroski details several civil engineering failures throughout history. The text also includes candid analysis of the reasoning that led to each failure.

Petroski begins his discussion of errors in conceptual design with the story of Paconius and the Pedestal of Apollo.

Let's explore how this civil engineering lesson can be applied to the design and development of software. If you're not familiar with the story, listen to the radio program linked above (or read the provided transcript).

Paconius sought an innovative solution to moving a massive pedestal from a quarry to the building site at the temple of Apollo at Selinous. The factors that drove his conceptual design appear to be primarily economic and aesthetic in hindsight. His solution, rather like a spool unwinding from the top, was apparently easier to construct, and allowed for heavier loads to be pulled with fewer oxen. Moreover, in contrast to the standard wooden frame solution, Paconius' innovation required no holes to be drilled in either end of the pedestal (to be fitted with iron and lead inserts). The spool approach also kept the pedestal more protected from the road and elements.

These all seem like big wins. Therein lies the problem, it's a trap, and a seductive one at that.

There are two fundamental flaws with Paconius' spool:

As the oxen pull the spool forward, they distance themselves equally from the spool.
After the rope runs out, you have to set the whole damn thing back up.

As the oxen distanced themselves from the spool, it became less stable and was prone to running off the road, undercutting the economic efficiency of using fewer oxen. The problem of scaling the solution over long distances made things even worse for Paconius. He ended up in financial ruin.

The Folly of Competing Objectives

Every consumer facing software project has economic and aesthetic objectives that are weighted to varying degrees. How do we balance these aims with technical design?

There are clearly many examples of software projects run off course, similar to Paconius' failed endeavour. Feel free to share your own in the discussion on Hacker News. However, I'm going to focus on how technical, economic and aesthetic objectives can be acheived harmoniously per an article I read on “Designing for Performance,” by P.J. Onori.

“Designing for performance requires a commitment to maximize the necessities and strip out superfluous luxuries. A more utilitarian approach towards design is needed where each element has a tangible and net-positive impact on the end result. This does not negate the importance of aesthetics, rather it means that it should not given a blank check.”

No blank checks doesn't mean letting the engineering team make all the decisions, it means regardless of your role, embrace an engineers mindset. One reason why VCs are insistent on startups having technical founders is their ability to assess the implications of conceptual design. Think carefully about how early design decisions impact technical architecture and performance. At the end of the day, we're all trying to solve problems, and this leads into my favorite part of P.J.'s article:

“…aesthetics should always support the problems we are asked to solve…. Looking at design through this lens will help create a goal-driven approach and focus our thinking.”

That said, as we discussed earlier, goals alone aren't enough to keep a project on track. To spare future generations the humor of reading about your own spectacular failures:

Recognize competing objectives and work to resolve them as early as possible.
Explore potential solutions to novel problems with other engineers (or critical thinkers).
Question and attack your own ideas, but don't stop having them.

Discuss this article on Hacker News.

Idols of the Mind

2013-02-28T06:58:00Z

Empiricism in Product Development

Francis Bacon wrote about idols of the mind, with regard to scientific inquiry. This is a nod to his style of clear, empirical thinking, with regard to product development (software, or otherwise).

Here are four ways to build a product nobody wants.

Rely on preconceived assumptions

Questions are one of the best tools for avoiding unwarranted assumptions. Paul Graham suggests, “The initial idea is just a starting point–not a blueprint, but a question.” A fresh perspective is invaluable when entering a domain that's ripe for disruption. However, failure to recognize your own innate biases can limit your ability to innovate. From your target market, to the problem your product solves, don't limit yourself with assumptions unless you've a compelling reason. There are times when assumptions are unavoidable, but that's ok as long as you recognize them.
Fail to acknowledge external perspectives

Idiosyncratic belief and passion are often at the heart of brilliance. They are also barriers that can feed your own echo chamber. Don't fall victim to this. External perspectives lend insight into the alignment of your product in the marketplace, balancing raw, creative effort with instructive guidance. Graham (in the same essay on ideas) suspects the together-alone-together sandwich as being the most productive setup for conceiving and implementing great ideas. I tend to agree with him. Time spent reflecting alone on your discussions with others shouldn't be discounted.
Forget that talk is cheap

Talk is cheap in all forms. This goes beyond just put up or shut up. Don't “let the power of mere words induce belief in non-existent things,” as Edward O. Wilson paraphrases Bacon's idols of the marketplace in Consilience: The Unity of Knowledge (unashamed to drop an affiliate link here). Just as talking about your product won't get you to launch, someone telling you a market exists doesn't mean it actually does. Take steps to empirically validate any assumptions you've made about your product and its place in the world.
Let dogmatic thinking cloud your vision

Unquestioning acceptance is almost never a good thing for product development. An open mind allows you to see opportunities that would be missed if you closed off your thinking. Dogmatic thinking begets more of the same old thing. The product might not be terrible, but you're running the risk of developing the kind of uninspiring software that needs to be sold with fancy steak dinners and extravagant bar tabs. Shake up the enterprise and don't box yourself in!

In Summary

Start with a question. See the world as it is. Make something better.

Discuss this post on Hacker News.

The Case for Static Site Generators

2013-02-26T08:46:00Z

Creating a website has never been so easy, and it's never been so hard. For the purposes of this post, assume that I'm considering a few different options for creating a site like the one you're looking at right now—a simple content-focused site with pages and articles.

WordPress

WordPress is ubiquitous. As a publishing platform for non-technical users, WordPress is as solid as any solution out there. Over the last 10 years, it's grown from a simple blogging tool into a fully fledged CMS. I don't need to debate its merits.

That said, maintaining a self-hosted WordPress installation takes vigilance. Security vulnerabilities can creep in if you don't stay on top of updates. Plugins further compound the problem. I'm not saying you can't put out a solid site on WordPress, just that there's more to worry about than you might think (particularly if you're just getting started, or busy worrying about other things).

Rails and Sinatra

Rails is a solid web application framework, and a great JSON server for single-page JavaScript applications. However, it's a little heavy for the purposes of our simple site. But what about all the great ruby gems and helpers Rails throws our way that would still be nice to have?

Haml
Sass
Asset pipeline
Application helpers (including partials)

I suppose I could use Sinatra, but then I still have to run an application server. There's more configuration and deployment (for the record, I know my gripes about keeping WordPress secure apply to any web application, including Rails and Sinatra apps). Moreover, it needs to be able to handle Hacker News or Reddit traffic, because, even though I don't want to spend a lot of time making the site, the content is going to be gold (right?). I need to be prepared. What's the solution?

Enter Static Site Generators

There are quite a few out there, however, I'm partial to Middleman, which is what I used to build this site. To be fair, here's a few others:

Jekyll
Octopress
Cactus
and a ton more….

Middleman is a command-line tool for building static sites that borrows some helpers from Padrino, and gives us access to all those kick-ass shortcuts we thought we'd left behind in Rails or Sinatra.

While they don't work for everything, it's refreshing to know that I don't have to worry as much about whether my server is going to conk out if the site gets slammed (or think twice about the bill). It's all static content once you build the project from the command-line. With directory indexes (on an Apache server), you can make your routes pretty too.

When I began getting into web development, WordPress was a great platform for me to learn on. However, I'm going to make the argument that a beginner today interested in the front-end would be better served by figuring out how to use a static site generator. They'd pick up…

Basic command-line skills
Ruby and its associated work-flow
Dynamic templates
Modern front-end development tools
Learning to RTFM

Fucking priceless.

At the end of the day… I'm not trying to pick on WordPress. Rails and Sinatra rock. But sometimes (when you can), it's nice to simplify things all the way down to the foundation of what makes the web great. Static content.

Discuss this article on Hacker News.