Hacker News Reader

To borrow from another field, there's a great 1969 interview with Charles Eames [1] (famed furniture designer) in which he discusses design, and constraints as being a necessary component of design. A pleasure to read.

Excerpts:

Interviewer: Does the creation of Design admit constraint?

Eames: Design depends largely on constraints.

Interviewer: What constraints?

Eames: The sum of all constraints. Here is one of the few effective keys to the design problem: the ability of the designer to recognize as many of the constraints as possible, his willingness and enthusiasm for working within these constraints. The constraints of price, size, strength, balance, time and so forth. Each problem has its own peculiar list.

Interviewer: Does Design obey laws?

Eames: Aren’t constraints enough?

[1] http://blog.designersrevolt.com/post/52143068880/the-definit...

Eames's views towards design helped me better make peace with accepting constraints and working with them as part of the medium.

Also, their interview set in a beautiful layout by House Ind, sure did help drive the point better - http://eames.houseind.com/objects/catalog.html

It might still be freely available as a catalog to those interested in their products. I highly recommend that one.

I agree, but for me it's important that the constraints be real. Sometimes when people hear that constraints are good and people love doing the impossible, they just make up arbitrary impossible constraints for their team.

I totally agree with you on shifting away from manager-centric approaches. I really like the Lean focus on customer value. Out from that center are people who directly add value: line workers, engineers, designers. Managers become necessary overhead (when they're just coordinating) or indrect value-adders (when they're helping tune the processes that actually add value). That's in contrast to the traditional western approach, where managers are bosses, people whose opinions win because they're big kahunas.

"constraints are what breed elegance" This; 1000x this.

I think this is also the reason so many really old-school video games are still not just playable, but can actually (arguably, of course) be even more fun than most of the current-gen eye candy. I'm thinking of Pac-man, Joust, and their ilk. Talk about embracing constraints.

EMBRACE CONSTRAINTS!

I remember the 'old school' and there were plenty of poor quality games; its just that very few of these have survived 20 years or more to be shopped around as examples of the past.

Survivorship bias.

"If all our airplanes keep getting japanese bullets in the wings and tail, don't put more armor there--that's were we don't need it. Put it where the airplanes that don't survive get shot." - Abraham Wald

Great comment (and quote!) -- totally agreed. But my having used a mediocre example doesn't counter the gist, that constraints can and do breed elegance. (shrug)

I do agree with your conclusion that constraints can lead to elegance. I just think that your point about old video games wasn't a good argument in favor of it.

I also think there is a better point to be made about what sorts of constraints produce elegance and which ones are just frustrating and produce hacky workarounds. I think in order to make that point, someone would have to do some engineering history research and some insightful thought to see how an engineer's mindset and a projects constraints interact to produce elegance. I suspect the development of those video games could be a fruitful place to look for that history.

I really should have clarified that this isn't actually a quote; It is a paraphrase of some of the work he did during the war.

Great point. Perhaps a better example might have been something like http://js1k.com/.

Constraints gave us Facebook instead of Myspace. Constraints gave us Twitter. Constraints gave us Snapchat.

Social networks have thrived on obvious constraints. When looking for a startup idea, sometimes I try to reimagine a popular tool or service with additional constraints.

I agree and would add that constraints gave us Star Wars: A New Hope instead of Star Wars: The Phantom Menace.

Which is to say that creatively working within hard constraints being a good thing is a universal creative rule, not specific to tech or social networks at all.

and no-constraints gave us 4chan.

It's entirely not true that no-contraints gave us 4chan. 4chan is definitely constrained: In manpower and financials. Every time the 4chan people post a clever hack that makes 4chan work with what they have, I'm impressed. The fact that they don't filter the content doesn't mean that there are no constraints to the system. The constraints are just different from facebook and myspace.

4chan has constraints: There are only 20 pages per board (if I recall correctly) and if a thread does not get new posts and drops from page 20, it's gone forever. Just like the twitter 140 characters limit, 4chan has a history limit.

So 4chan perfectly fits in the parent's list of social network like things based on arbitrary contraints

I doubt it was constraints that made Facebook become more popular, or any other technical reason. It's too bad MySpace isn't what people use anymore. I'd like having all the customization of my home page on Facebook.

By the time an engineer is tasked with implementation, a sufficiently-constrained problem or set of problems should be established. Execution risk tends to increase significantly when engineers are tasked with building solutions to an unwieldy set of problems.

But at the earliest stages, when exploring a market and business opportunity, premature constraints can be deadly because they often encourage you to ignore feedback from the market and make assumptions that aren't necessarily correct. The result, in many cases, is that companies end up solving problems that don't exist, or that aren't painful enough to support a real business.

In my experience, there are just as many engineers trying to make their jobs easier (by pushing to constrain scope at all costs) as there are product managers/business owners who aren't very good at defining problems and crafting sensible solutions to them.

Your manager-centric versus engineer-centric comment suggests that managers are inherently less capable of developing solutions to problems than engineers but in reality, the real issue is that there are relatively few product-savvy engineers and relatively few engineering-savvy product managers.

In art school they say "form is liberating". It gives you direction and relieves you of the oppression of infinite choices. It can give you something concrete to fit into, or subvert.

Form is liberating.

I've heard it as "restrictions breed creativity," but I think I like that version much better.

This is quite good. Too many choices are indeed a source of misery.

"Form is liberating" is also cited in The Mythical Man-Month.

It's entirely possible I picked it up from there. I frequently think of brilliant sayings and discover Brooks got there first and better.

As a student of management (once upon a time) what I found to be one of the more interesting paradigms was the Theory of Constraints: https://en.wikipedia.org/wiki/Theory_of_Constraints

I recently read "The Goal", may I ask what you found interesting about TOC?

As far as I could see, it seemed to boil down to finding and fixing bottlenecks. Focusing on the critical paths in a process whether project schedules or chip designs is just par for the course. I don't know whether I missed something.

I think the "constraints" he had in mind were more like what we would call "implementation details." What if someone told you, "sort this list of a million words as fast as you can, but the constraint is you have to use a bubble sort." Think of a CEO with $50M in the bank telling his CTO, "build a best-of-breed product, but you can only hire two new engineers this year."

The thing we don't always recognize is, there are constraints either way. Part of the process or designing or solving any problem is to realize what the constraints are - you're unlikely to fulfill any constraints you're not sure about! By focusing on what the constraints should be from the start, you have a clear idea of what problem you're trying to solve

> "As a technologist, you know that the worst thing that you can do is over-constrain the problem before you start. You'll kill creativity and prevent yourself from getting a truly great outcome."

> As an engineer, I love hearing firm constraints from the beginning.

Sure, but note that these two points aren't in conflict. As someone building solutions, of course you want as firm a definition of the problem as possible, and constraints are part of that. But its still a critical failure to over-constrain the problem at the start (or any other time) -- constraints are essentially just a different way of phrasing requirements, and overconstraining a problem is exactly specifying superfluous requirements. Extra, unneeded constraints make the ultimate solution worse, because they mean you are solving the wrong problem -- and a more complicated problem than the one you actually needed to solve.

>But its still a critical failure to over-constrain

Well yes tautologies are tautological and all, but the point is that GP and the people agree with it suspect that their definition of "over-constrain" happens way way past where the article's author does.

This also neatly ties in with the Mythical Man Month. You cannot increase the headcount to in the hope that you can accelerate. There is a great deal of domain knowledge that is locked up, and initially - growing involves having a person who is wearing multiple hats to give up one of their hats.

I agree that having constrains makes the problem simpler to think about, which as a programmer/engineer is great. It makes the problem look more like a puzzle.

However the truth is that constrains can be broken as long as you realize that doing so has a cost. Taking this into account expands the solutions space hugely, which both means that if you can take advantage of this you might find overall better solutions, while at the same time it can be overwhelming and paralyzing.

Edit to add: sometimes when the solutions space is too big artificially and arbitrarily limiting it might help.

It applies to games too! When customization is too granular, all players' configurations converge on a few min/maxed builds.

Constraints (e.g. player class systems) reduce the raw number of choices you can make, but the ones left behind are more interesting and meaningful.

Plus-one - constraints are absolutely vital. I'd say the absence of constraints has killed more projects as I have seen. It's difficult to determine wants v.s. need without some thinking, and constraints help with that.