Saturday, September 04, 2010

What do you mean by "Everything"?

I had a great meeting with someone the other day who, during the course of our conversation, questioned my statement in my post below1 that "Everything does not need to be a Class".  His rationale was that if something had attributes, it should be a class. I realized that this point of mine needed clarification.

I like Classes that represent some real-world object; whether tangible (car) or intangible (transaction). It's a thing that has real attributes which, when taken as a whole, comprise that thing.  So sure, create a Class and instantiate it a few times as needed to get a few things happily bouncing around your system. If it has an analogue in the physical world, it's an excellent candidate for a Class.

What I object to can be shown by example: A Class composed of a collection data transformation functions. Why does this need to be an Object? It's a module full of functions, really, and does not need the additional layer of Class in there to wrap the methods. This Class doesn't represent a thing, and doesn't have attributes. I'd recommend module-level functions.

Another example is best demonstrated by a process that does the following:
1. Generate some JSON for consumption by a web client
2. Wrap this JSON in an instance of a class (no other attributes).
3. Send this object to the client.
4. The client unwraps the JSON from the object
5. The client consumes the JSON.

I object that there needs to be an Object here.  I'd rather see
1. Generate some JSON for consumption by a web client.
2. Send the JSON to the client
3. The client consumes the JSON.

I fully realize that all of this sounds (and is) absolutely elementary.  And yet, I run into over-Objectification more frequently than I believe is desirable. (The whole wrap-JSON-in-an-object was rationalized by the engineer, "Everything in the system is an object, and I wanted to be consistent".  Someone else was optimizing for the future, "We might need more stuff sent to the front-end someday. This makes it a no-brainer for the next engineer".)

"If all you have is an OOP, everything looks like a Class".  I believe that engineers should have a whole box of tools from which to choose, and OO is one of those tools among others. When everything in your system is an object, it's clear that your toolbag contains only one tool. Even worse is when every object inherits from some other object, sometimes in stacks of 5, 7, 12 Classes high. (e.g., no use of object-composition whatsoever: conflation of the "Is-A" ad "Has-A" relationship concepts, conflation of data and function, etc).  And, once again, ultimately we're engineers in a business; our responsibility is not at all to the gods of OO, it is to the business.  It's very valuable to learn when a Class is absolutely appropriate and awesome, and when It Is Not.


Saturday, August 07, 2010


Quick update:

Yes, I'm back at Slide, and yes, we've just been acquired by Google.

Look out, world.

Friday, April 30, 2010

Thoughts and Advice, part 0

General advice regarding engineering

Some tenets:
  1. Everything does not need to be a Class. 
  2. When you do use Classes, consider composition.
  3. Keep it simple.
  4. Ask yourself, "Now that I consider this complete, how can I make it simpler?"
  5. Can any reasonably talented and/or experienced engineer read what I have created and extend it/modify it in as little time and as effectively (e.g., regression-free) as possible?
  6. Ask yourself, "Have I separated data from function?"
  7. See 3. (above)
  8. "There are many right ways to do the task" does not mean there are not wrong ways to do the task[2].  If one can say "All things being equal, this is a correct way to do this task", one must remember that all things are never equal, and the solution you are proposing may violate or lay beyond the principles of the existing robust architecture. If it does violate the principles of the existing and robust architecture, it is indeed a bad solution and you probably shouldn't do it.
  9. When in doubt, find two or three engineers whom you respect and ask their opinion. Better yet, get them together and present your idea/solution to them (preferably at a white-board). The act of explanation slows down your thought process, and activates a different part of the brain (you engage in a different cognitive process than you do just sitting there, ruminating). It forces you to clearly articulate and  linearly work through the solution. Then: make an educated best-guess.[3]
  10. If your rebuttal to anything starts with "Yeah, but..", stop and reconsider your argument.
  11. Rationalizing a bad decision does not alter the quality of that decision. While not all bad decisions can be mitigated right now, don't conflate time- and project-management with the idea that "it was the best we could do at the time, therefore it's as good-code as everything else in the system".  Rather, "Yeah, I know it sucks, and we'll fix it when it's opportune; for the moment we have to live with it".

Some fallacies:
  1. Everything needs to be a Class.
  2. Functional programming "doesn't work"
  3. Imperative (procedural) programming "doesn't work"
  4. [software that is used very successfully around the world] "doesn't work"
  5. Everything must be an Object. 
  6. The more complicated it is, the better the system.
  7. "I don't need to explain myself, just do what I tell you."
  8. Picking emotionally immature managers will result in a mature, professional organization.
  9. "Ur doin it rong". (See 7. and 8. above)
  10. Great engineers always make great managers.
  11. Code is a good outlet to demonstrate to other engineers/the world/my mom how brilliant I really am.
  12. "My code will help The Singularity arrive more quickly".
  13. "The names of things doesn't matter - a good engineer should be able to read the code and know what things are". (Imagine an Exception class named "Fred".  raise Fred('there has been a problem') is meaningless).[4]

[1] Project specifications are generally a static 'snapshot' of an evolving business process. The business changes rapidly as the people running the company must respond to changing market conditions. It's dynamic. We are engineers, but we do not work in a vacuum. We must act as engineer/entrepreneurs.
[2] Via Libor 
[3] If you work for a good manager, they'll  understand that part of their job is to help you recover from bad (although reasoned) decisions and failures; they will also understand that it is not a part of their job to try to prevent you from making bad (although reasoned) guesses/failures. []. They should strongly advise you against making unreasoned, and unreasonable, decisions.
[4] _items = items.item.Item.items() and from items.item import Item is also ridiculous. As are one-letter attribute names and attribute names that still conform to 1970's-era 6-character name limitations.  Also ridiculous is code that isn't sufficiently namespaced: import as stitems and import as tritems is ridiculous.  Worse yet is import game.challenges.exceptions as lolufailz. No, really. Don't do that.

Saturday, March 20, 2010

How to be a Programmer

Time and time again, I return to this classic essay by Robert L. Read.

Debugging is the cornerstone of being a programmer. The first meaning of the verb to debug is to remove errors, but the meaning that really matters is to see into the execution of a program by examining it. A programmer that cannot debug effectively is blind.

Idealists that think design, or analysis, or complexity theory, or whatnot, are more fundamental are not working programmers. The working programmer does not live in an ideal world. Even if you are perfect, your are surrounded by and must interact with code written by major software companies, organizations like GNU, and your colleagues. Most of this code is imperfect and imperfectly documented. Without the ability to gain visibility into the execution of this code the slightest bump will throw you permanently. Often this visibility can only be gained by experimentation, that is, debugging. 
 If you're an engineer, this is a must-read.   Related: this thread on Quora. And more quotes from the essay after the break.

Friday, March 19, 2010

Discover Information

You might have noticed that if you scroll down on this blog, a bar appears at the top. Go ahead, scroll down a bit now, I'll wait.

Cool, isn't it? It's means that I have Apture 2.0-beta installed on the blog. This is a way to discover more information. Gain more knowledge! It's also a way to share that information and knowledge with the world.

For example....
Now try this: highlight this word: Iran. (You can highlight a word by double-clicking on it, or by dragging the mouse over it). See that little thought-bubble that says "Search"?  Click it. (or hit Control-C)

Now you have a bunch of relevant links to information up to your right. Click on one, and a small box with that information appears. Now click on a few. Now you have a few windows of relevant information for the term (or phrase) in the page about which you wanted more knowledge and.or were curious about.

Information, knowledge, context, discovery
This is cool. So when I write all sorts of technobabble like "I'm skeptical about the value of designing systems in python using only object inheritance without also considering object composition", readers unfamiliar with the esoteric nomenclature of object-oriented programming can use Apture to quickly and easily learn more about wtf I'm talking about, and gain a greater context in which to understand the discussion.

You are not entitled to your opinion; you are entitled to your informed opinion. If you are not informed on the subject, then your opinion counts for nothing.
~ Harlan Ellison

I want it everywhere.
I've been using Apture 2.0 beta for a few days now, and I'm addicted to it. I want it on every page I visit, especially on those where I frequently find a term or subject with which I am unfamiliar.

So enjoy! And please let me know what you think.

Update: More information at our Apture blog.


Saturday, March 13, 2010

Brian Eno on context

Brian Eno discusses context by way of the analogy of how one listens to Miles Davis:

[from The Wire Dec./Jan. 1993] When you listen to Miles Davis, how much of what you hear is music, and how much is context? Another way of saying that is, 'What would you be hearing if you didn't know you were listening to Miles Davis?' I think of context as everything that isn't physically contained in the grooves of the record, and in his case that seems quite a lot. It includes your knowledge, first of all, that everyone else says he's great: that must modify the way you hear him. But it also includes a host of other strands: that he was a handsome and imposing man, a member of a romantic minority, that he played with Charlie Parker, that he spans generations, that he underwent various addictions, that he married Cicely Tyson, that he dressed well, that Jean-Luc Godard liked him, that he wore shades and was very cool, that he himself said little about his work, and so on. Surely all that affects how you hear him: I mean, could it possibly have felt the same if he'd been an overweight heating engineer from Oslo? When you listen to music, Aren't you also 'listening' to all the stuff around it, too? How important is that to the experience you' re having, and is it differently important with different musics, different artists?
Miles was an intelligent man, by all accounts, and must have become increasingly aware of the power of his personal charisma, especially in the later years as he watched his reputation grow over his declining trumpeting skills. Perhaps he said to himself: 'These people are hearing a lot more context than music, so perhaps I accept that I am now primarily a context maker. My art is not just what comes out of the end of my trumpet or appears on a record, but a larger experience which is intimately connected to who I appear to be, to my life and charisma, to the Miles Davis story." In that scenario, the 'music', the sonic bit, could end up being quite a small part of the whole experience. Developing the context- the package, the delivery system, the buzz, the spin, the story - might itself become the art. Like perfume...
Professional critics in particular find such suggestions objectionable. They have invested heavily in the idea that music itself offers intrinsic, objective, self contained criteria that allow you to make judgments of worthiness. In the pursuit of True Value and other things with capital letters, they reject as immoral the idea that an artist could be 'manipulative' in this way. It seems to them cynical: they want to believe: to be certain that this was The Truth, a pure expression of spirit wrought in sound. They want it to 'out there', 'real', but now they're getting the message that what its worth is sort of connected with how much they're prepared to take part in the fabrication of a story about it. Awful! To discover that you're actually a co-conspirator in the creation of value, caught in the act of make-believe. 'How can it be worth anything if I did it myself?'
I remember seeing a thing on TV years ago. An Indonesian shaman was treating sick people by apparently reaching into their bodies and pulling out bloody rags which he claimed were the cause of their disease. It all took place in dim light, in smoky huts, after intense incantations. A Western team filmed him with infrared cameras and, of course, were able to show that he was performing a conjuring trick. He wasn't taking anything out of their bodies after all. So he was a fake, no? Well, maybe-- but his patients kept getting better. He was healing by context-- making a psychological space where people somehow got themselves well. The rag was just a prop. Was Miles, with a trumpet as a prop, making a place where we, in our collective imaginations, could somehow have great musical experiences? I think so. Thanks, Miles, and thanks everyone else who took part, too.

Friday, March 05, 2010

Closing one door, opening another one

Today is my last day at Slide. After two-plus years of being a Slider, I resigned a couple of weeks ago to join the gang at Apture. While I'm sad to leave Slide, I'm excited to join Apture.

I'll be moving from a company of over 100 people to a company of around 10 people.

When I started at Slide, we were somewhere between 50-70 people, and each team within the company felt like a mini-startup. I worked wild hours and loved it, and had a lot of fun working with the brilliant people by whom I was surrounded. Literally surrounded: our office at the time was essentially one big room, and we were packed in like obsessive-compulsive python-chewing sardines. At one point I shared a cheap Ikea desk with a QA engineer's pet fish.

Slide is a bigger company now and, while still maintaining some of the "scappy little startup" atmosphere, has grown into the "now we're a real company" phase. And while I loved going to work every day, I began to yearn for the 5-10 person sized company.

I had no intention of leaving Slide so soon, and I won't be ready to start a company of my own again until I've slept for a month straight and taken a vacation in some sunny, gin-and-tonic laden locale. But after several serendipitous conversations with Tristan, Can, and Steven, I felt that we could "make good jazz" together (I'll explain what that means in a later post).

Slide was, and is, a great place to work. When the opportunity to work at Slide came to me in an email from Max, I drove from Los Angeles to San Francisco the next day. Within a week of signing the offer, I had packed almost everything from the home-office rental in Topanga (from where Paul and I launched several products including our reasonably successful Facebook app) to SoMa. I'll miss the place and the people at Slide.

I'm very excited to work with the team at Apture on an extremely cool-and-useful product, and once again with some very smart people. You can see some of our product in this blog-post, but I'm sure that the best is yet to come.

Monday, March 01, 2010

Programming as an objective art

Managing or working with any team of highly motivated, passionate and creative developers presents this problem, as a group: how can you objectively judge code while preserving the sense of ownership by the author?
The first step to objectively judging code in my opinion, is to separate it from the individual who wrote it when discussing the code. For a lot of people this is easier said than done, particularly for younger engineers like myself. Younger engineers tend to have "more to prove" and are thereby far more emotionally invested in the code that they write, while older engineers whether by experience or simply by having written more code than their younger counterparts are able to distance themselves emotionally more easily from the code that they write. Not to say older engineers aren't emotionally invested in their work, in my experience they typically are, it's just a matter being better at picking battles.

Monday, February 15, 2010

Apple on Design

During the design process, if you discover problems with your product design, you might consider applying the 80 percent solution—that is, designing your software to meet the needs of at least 80 percent of your users. This type of design typically favors simpler, more elegant approaches to problems.
If you try to design for the 20 percent of your target audience who are power users, your design may not be usable by the other 80 percent of users. Even though that smaller group of power users is likely to have good ideas for features, the majority of your user base may not think in the same way. Involving a broad range of users in your design process can help you find the 80 percent solution.
Read the whole thing, as they say.

Of the ten best engineers with whom I have worked...

6 do not have a C.S. degree,
2 have a liberal-arts degree,
1 has an engineering-related graduate (and post-graduate) degree,
4 did not finish college (or did not attend), instead opting for entering business,
2 are women (because I know someone's going to ask), 
5 are over 40.

This deserves some additional commentary, to which I will have to attend later. 

(I'd been thinking that of the best engineers I know, the majority did not finish university or did not attend. I'd also thought that many, or most, of them had some sort of liberal-arts study. I quickly compiled a list and derived some elementary statistics in order to do a quick analysis of my supposition. More on this later.)

Friday, January 29, 2010

Plan for community

If people love your game/site/product/etc., they'll be compelled to talk about it, brag to their friends about their involvement with it, share ideas about it, complain about it... in short: they'll feel a natural compulsion to get involved.

While working on an idea for a product, make sure that the community elements are intrinsic* to your product.  Your product must be comprised of many things, one of which must be some sort of mechanism for community involvement.

For example, if you're building a game, insure that one or some of the core mechanics implemented are dependent on community involvement. For a non-game, insure that there's some necessary community involvement from the earliest customer contact.

From the start, make certain that community is one of your behavioristic design components**.

The alternative is to build something, launch, and subsequently "bolt-on" a community, usually in the form of a bulletin board/forum. What happens in this case, unfortunately, is that (usually) by the time you get around to it there's already one out there created by your fanatic customers, and you now have to either co-opt theirs or build your own and compete with it.***

*adjective: belonging naturally; essential
** And please, don't be cynical with your behaviorist design. We're not mice, and you're not building a Skinner Box. 
*** When Paul and I built "Just Three Words", two separate forums popped-up within a week of each other, very quickly after launch. We'd missed the boat on creating our own, and so became members of a customer-operated community.

Saturday, January 16, 2010

Thought for today

Great engineers assume ownership of their projects and become emotionally invested in the success (or failure) of their project.

Preventing them from doing so is a quick path to failure. Enabling and encouraging them to do so and assisting them where necessary (removing obstacles to success and so on) makes success much more likely.