As I've written before, say, here, this reflects a fundamental misunderstanding about OOPSLA has always been about. It's a natural misunderstanding, given the name and the marketing hype around it through the 1990s, but a misunderstanding nonetheless. It's hard to unbrand a well-known conference and re-brand it once its existing brand loses its purpose or zip. So OOPSLA struggles a bit. I hear that next year it will become one attraction under the umbrella of a new event, "SPLASH". (More on that later!)

In the last few years, people have begun to notice something similar going on with a younger spinoff from OOPSLA. Agile software development has started to become mainstream. It is over the initial hump of awareness and acceptance. Most everyone knows what 'agile' is, or thinks he does. Its practices have begun to seep into a large number of software houses, whether from Scrum or XP. Our languages and tools now make it possible to work in shorter iterations with continuous feedback and more confidence. We teach it in universities, sometimes even to freshmen. Agile has become old school.

Maybe I'm overstating things a bit, but the buzz has certainly died off. Now we are more likely to hear grumbling. I don't know that many people are asking whether we need conferences devoted to agile approaches yet. But I am starting to read articles that second guess the "movement" and to see a lot of revisionist history. Perhaps this is what happens when the excitement of newness fades into the blandness of same-old, same-old. The excitement passes, and people begin to pay attention more to the chinks in the armor than the strengths that gave the idea birth.

Let's not forget what made agile development and especially XP so galvanizing. William Caputo hasn't forgotten:

But why Agile sells isn't why I liked it. I liked it *because* it put the programmer at the center of the effort of programming (crazy notion that), I didn't need the manifesto to tell me that I had to find ways to make the person paying the money delighted with my efforts, what I needed was a way to tell them that I would gladly do so, if they would just let me.

(The asterisks are his. The bold is mine.)

This is what made XP and the other agile approaches so very important. Focusing on the buyers' needs is easy to do. They pay for software and so have an opportunity to affect strongly the nature of software development. What was missing pre-agile was attention to the developer. I still prefer the term "programmer", with all it implies. It was easy to find ways in which programmers were marginalized, buried beneath processes, documentation, and tools that seemed primarily to serve purposes other than to trust and help programmers to make great software.

The agile movement helped to change that, to shift the perspective from inhuman processes that expected the worst from programmers to practices that celebrate programmers and their love for making software. That some people are now even talking about restating the Agile Manifesto's values toward maximizing shareholder value is a tribute to agile's success at changing the overarching story of the industry.

All this reminds me of an essay by Brian Marick on ease and joy. Agile is about joy at work. We programmers love to make software -- software that improves the lives of its users. Great software. Let us love writing programs, and we can do great things for you.

To me, one of the most thought-provoking things Reg says is actually a rather small point in the overall message of the talk. Object-oriented programming is, he summarizes, basically a matter a matter of nouns and verbs, objects and their behaviors. What about other parts of speech? He gives a simple example of an adverb:

blitz.not.blank?

In this expression, not is an adverb that modifies the behavior of blank?. At the syntactic level, we are really telling blitz to behave differently in response to the next message, which happens to be blank?, but from the programmer's semantic level not modifies the predicate blank?. It is an adverb!

Reg notes that some purists might flag this code as a violation of the Law of Demeter, because it sends a message to an object received from another message send. But it doesn't! It just looks that way at the syntax level. We aren't chaining two requests together; we are modifying how one of the requests works, how its result is to be interpreted. While this may look like a violation of the Law of Demeter, it isn't. Being able to talk about adverbs, and thus to distinguish among different kinds of message, helps to make this clear.

It also helps us to program better in at least two ways. First, we are able to use our tools without unnecessary guilt at breaking the letter of a law that doesn't really apply. Second, we are freed to think more creatively about how our programs can say what we mean. I love that Ruby allows me to create constructs such as not and weave them seamlessly into my code. Many of my favorite gems and apps use this feature to create domain-specific languages that look and feel like what they are and look and feel like Ruby -- at the same time. Treetop is an example. I'd love to hear about your favorite examples.

So, our OO programs have nouns and verbs and adverbs. What about other parts of speech? I can think of at least two from Java. One is pronouns. In English, this is a demonstrative pronoun. It is in Java, too. I think that super is also demonstrative pronoun, though it's not a word we use similarly in English. As an object, I consist of this part of me and that (super) part of me.

Another is adjectives. When I teach Java to students, I usually make an analogy from access modifiers -- public, private, and protected -- to adjectives. They modify the variables and methods which they accompany. So do synchronized and volatile.

Once we free ourselves to think this way, though, I think there is something more powerful afoot. We can begin to think about creating and using our own pronouns and adjectives in code. Do we need to say something in which another part of speech helps us to communicate better? If so, how can we make it so? We shouldn't be limited to the keywords defined for us five or fifteen or fifty years ago.

Thinking about adverbs in programming languages reminds me of a wonderful Onward! talk I heard at the OOPSLA 2003 conference. Cristina Lopes talked about naturalistic programming. She suggested that this was a natural step in the evolution from aspect-oriented programming, which had delocalized references within programs in a new way, to code that is concise, effective, and understandable. Naturalistic programming would seek to take advantage of elements in natural language that humans have been using to think about and describe complex systems for thousand of years. I don't remember many of the details of the talk, but I recall discussion of how we could use anaphora (repetition for the sake of emphasis) and temporal references in programs. Now that my mind is tuned to this wavelength, I'll go back to read the paper and see what other connections it might trigger. What other parts of speech might we make a natural part of our programs?

(While writing this essay, I have felt a strong sense of deja vu. Have I written a previous blog entry on this before? If so, I haven't found it yet. I'll keep looking.)

Some people don't like languages with features that allow them to reconfigure how the language looks and works. I may have been in that group once, long ago, but then I met Lisp and Smalltalk. What wonderful friends they were. They opened themselves completely to me; almost nothing was off limits. In Lisp, most everything was open to inspection, code was data that I could process, and macros let me define my own syntax. In Smalltalk, everything was an object, including the integers and the classes and the methods. Even better, most of Smalltalk was implemented in Smalltalk, right there for me to browse and mimic... and change.

Once I was shown a world bigger than Fortran, PL/I, and Pascal, I came to learn something important, something Giles Bowkett captures in his inimitable, colorful style:

There is no such thing as metaprogramming. It's all just programming.

(Note: "Colorful" is a euphemism for "not safe to read aloud at work, nor to be read by those with tender sensibilities".)

Ruby fits nicely with languages such as Common Lisp, Scheme, and Smalltalk. It doesn't erect too many boundaries around what you can do. The result can be disorienting to someone coming from a more mainstream language such as Java or C, where boundaries between "my program" and "the language" are so much more common. But to Lispers, Schemers, and Smalltalkers, the freedom feels... free. It empowers them to express their ideas in code that is direct, succinct, and powerful.

Actually, when you program in C, you learn the same lesson, only in a different way. It's all just programming. Good C programmers often implement their own little interpreters and their own higher-order procedures as a part of larger programs. To do so, they simply create their own data structures and code to manipulate them. This truth is the raw material out of which Greenspun's Tenth Rule of Programming springs. And that's the point. In languages like C, if you want to use more powerful features, and you will, you have to roll them for yourself. My friends who are "C weenies" -- including the aforementioned colleague -- take great pride in their ability to solve any problem with just a bit more programming, and they love to tell us the stories

Metaprogramming is not magic. It is simply another tool in the prepared programmer's toolbox. It's awfully nice when that tool is also part of the programming language we use. Otherwise, we are limited in what we can say conveniently in our programs by the somewhat arbitrary lines drawn between real and meta.

You know what? Almost everything in programming looks like magic to me. That may seem like an overstatement, but it's not. When I see a program of a few thousand lines or more generate music, play chess, or even do mundane tasks like display text, images, and video in a web browser, I am amazed. When I see one program convert another into the language of a particular machine, I am amazed. When people show me shorter programs that can do these things, I am even more amazed.

The beauty of computer science is that we dig deeper into these programs, learn their ideas, and come to understand how they work. We also learn how to write them ourselves.

It may still feel like magic to me, but in my mind I know better.

Whenever I bump into a new bit of sorcery, a new illusion or a new incantation, I know what I need to do. I need to learn more about how to write programs.

In the last few months, I've seen several articles in which authors talk about how they set out to write a book on a topic they didn't know well or even much at all. Last summer, Alex Payne wrote this about writing the tapir book:

I took on the book in part to develop a mastery of Scala, and I've looked forward to learning something new every time I sit down to write, week after week. Though I understand more of the language than I did when I started, I still don't feel that I'm on the level of folks like David Pollak, Jorge Ortiz, Daniel Spiewak, and the rest of the Scala gurus who dove into the language well before Dean or I. Still, it's been an incredible learning experience ...

Then today I ran across Noel Rappin's essay about PragProWriMo:

I'm also completely confident in this statement -- if you are willing to learn new things, and learn them quickly, you don't need to be the lead maintainer and overlord to write a good technical book on a topic. (Though it does help tremendously to have a trusted super-expert as a technical reference.)

Pick something that you are genuinely curious about and that you want to understand really, really well. It's painful to write even a chapter about something that doesn't interest you.

This kind of writing to learn is still not a part of my mentality. I've certainly chosen to teach courses in order to learn -- to have to learn -- something I want to know, or know better. For example, I didn't know any PHP to speak of, so I gladly took on a 5-week course introducing PHP as a scripting language. But I have a respect for books, perhaps even a reverence, that makes the idea of publishing one on a subject I am not expert in unpalatable. I have to much respect for the people who might read it to waste their time.

I'm coming to learn that this probably places an unnecessary limit on myself. Articles like Payne's and Rappin's remind me that I can study something and become expert enough to write a book that is useful to others. Maybe it's time to set out on that path.

Getting people to take this step is one good reason to heed the call of Pragmatic Programmers Writing Month (PragProWriMo), which is patterned after the more generic NaNoWriMo (NaNoWriMo). Writing is like anything else: we can develop a habit that helps us to produce material regularly, which is a first and necessary step to ever producing good material regularly. And if research results on forming habits is right, we probably need a couple of months of daily repetitions to form a habit we can rely on.

So, whether it's a book or blog you have in mind, get to writing.

(Oh, and you really should click through the link in Rappin's essay to Merlin Mann's Making the Clackity Noise for a provocative -- if salty -- essay on why you should write. From there, follow the link to Buffering, where you will find a video of drummer Sonny Payne playing an extended solo for Count Basie's orchestra. It is simply remarkable.)

Someone could do the SE world a great service by gathering, organizing, and providing links to all the good work that has been done. Wilson is one of the people I turn to for pointers to empirical SE results.

I did have fun reading some classic old work in this area. One is McCabe's original article on cyclomatic complexity. This is very cool and has a nice tie to theory, but it simply describes a metric. It does not gather present data from real programs against which the metric has applied, and it doesn't provide any base line for comparison. When he speaks of 10 as a reasonable upper bound for a module's cyclomatic complexity, or of code with cyclomatic complexity in the 3-7 range as "quite well structured", I wonder "Why?" He drew these values from experience looking at production code available to him, but these numbers feel a bit unreliable.

I'm not a stickler who needs statistically significant analysis of carefully collected data, though. I like to learn from experience that is gathered and presented qualitatively. I enjoyed reading about an informal experiment into the complexity of code developed test-first. We need to be careful to take the results with a grain of salt, given the informality of the definitions and methodology used, but the experiment seems to say something useful. I also liked Martin Fowler's reflective analysis of dynamic type checking in production Ruby code from ThoughtWorks. He also wrote an interesting reflection on Ruby at ThoughtWorks that I learned from.

Still, we need more of the sort of empirical evidence that Wilson offers in his talk. As a discipline, we can do a better job of paying attention to the validity of our claims, and of more frequently asking, "Data, please!"

As a doctoral student, I thought my career path might look similar to Cook's. I applied for research positions in industry, with two of the Big Six accounting firms and with an automobile manufacturer, at the same time I applied for academic positions. In the end, after years of leaning toward industry, I decided to accept a faculty position. As a result, my experience with industrial CS research and development is limited to summer positions and to interactions throughout grad school.

Cook's talk needs no summary; you should read it for yourself. Here are a few points that stood out to me as I read:

Venture capitalists talk about pain killers versus vitamins. A vitamin is a product that might make you healthier over the long run, but it's hard to tell. Pain killers are products where the customer screams "give it to me now" and asks what it costs later. Venture capitalists only want to fund pain killers.

This is true not only of venture capitalists, but of lots of people. As a professor, I recognize this in myself and in my students all of the time. Cook points out that most software development tools are vitamins. So are many of the best development practices. We need to learn tools and practices that will make us most productive and powerful in the long run, but without short-term pain we may not generate the resolve to do so.

We read all the standard references on OO for business applications. It didn't make sense to us. We started investigating model-driven development styles. We created modeling languages for data, user interfaces, security and workflow. These four aspects are the core of any enterprise application. We created interpreters to run the languages, and our interpreters did many powerful optimizations by weaving together the different aspects.

To me, this part of the talk exemplifies best how a computer scientist thinks differently than a non-computer scientist, whether experienced in software development or not. Languages are tools we create to help us solve problems, not merely someone else's solutions we pluck off the shelf. Language processors are tools we create to make our languages come to life in solving instances of actual problems.

The way I see it is that industry generally has more problems than they do solutions, but academia often has more solutions than problems.

Cook makes a great case for a bidirectional flow between industry, with its challenging problems in context, and academia, with its solutions built of theory, abstraction, and design. This transfer can be mutually beneficial, but it is complicated by context:

Industrial problems are often messy and tied to specific technical situations or domains. It is not easy to translate these complex problems into something that can be worked on in academia. This translation involves abstraction and selection.

The challenge is greatest when we then take solutions to problems abstracted from real-world details and selected for interestingness more than business value and try to re-inject them into the wild. Too often, these solutions fail to take hold, not because people in industry are "stupid or timid" but because the solution doesn't solve their problem. It solves an ideal problem, not a real one. The translation process from research to development requires a finishing step that people in the research lab often have little interest in doing and that people in the development studio have little time to implement. The result is a disconnect that can sour the relationship unnecessarily.

Finally, the talk is full of pithy lines that I hope to steal and use to good effect sometime soon. Here is my favorite:

Simplicity is not where things start. ... It is where they end.

Computer scientists seek simplicity, whether in academia or in industry. Cook gives us some clues in this talk about how people in these spheres can understand one another better and, perhaps, work better together toward their common goal.

I signed up for this race in large part because it let me keep my options open as late as possible. I started training late and wasn't sure I'd be ready for an October marathon. On the Road for Education was later than most midwest marathons, October 25, and had a late early registration date. It also was less expensive than other, better-known races. All of these added up to an attractive package for an unsure trainer. They also left me uncertain; I had no idea what to expect from the race or organization.

This was a great little marathon. It is super small by the standard of most well-known marathons these days. This year, 78 men and 25 women finished, with only one runner who started not finishing. Add in the 101 half-marathoners, 35 10K runners, and 78 5K runners, and the event is still super small. That creates an intimate setting, as well as an opportunity to run a lot of the race solo.

The trimmings of the race were all good and better than I hoped:

• Aid stations every two miles offered water and sport drink.
• Aid stations at miles 12, 18, and 22 offered energy gel.
• There were more portalets than advertised.
• There more local spectators out cheering us on than I had expected in such a small town, and on such a cold morning.
• We ran on a variety of surfaces, including many miles of soft surface: packed dirt in the country, bike trails, and a few miles of off-road trail. This was great for my legs.
• We ran in a variety of settings, including city roads, country roads, bike trails, recreation trails in town, and nature trail.
• The volunteers working along the course, including the police officers patrolling the intersections, were unfailingly friendly and helpful.
• The end-of-race food and drink were plentiful, various, and tasty.
• Finally, the high school was open after the race with hot showers and towel service. Awesome!

In addition, the race hotel was excellent and happy to serve the runners from out of town.

The one risk you face with this race is one the organizers cannot control: the weather. The last weekend of October in northern Iowa can be dicey. We were lucky, with temps in the 40s F. and clouds to keep the heat down at the end of the race.

This was the 11th year for the On the Road for Education marathon. These folks have experience putting on a race, and it showed. I give it two two thumbs up and recommend it highly for an intimate, personal marathon experience. If you want the experience of a "spectacle marathon", look elsewhere. This one isn't about tens of thousands of spectators or bands playing at every mile. It's about the run.

One final warning: don't expect a course built for PRs. Eleven of the miles were net climbs, with steep rises during miles 6, 7, and 21. Eleven of the miles were net drops, and the rest of the course is flat. But even that is deceptive. Miles 15-19 show as flat on the course elevation map, but they were in a nature area. They might be net neutral, but they undulate throughout. This makes for interesting running! Just don't expect a flat Iowa course and an easy PR.

The weather was dreary but almost perfect for a race: in the low 40s, cloudy, with little wind.

After feeling good with an 8:30/mile pace in a half marathon six weeks ago, I decided to try that pace for the full. After nine miles, I was right on target, though by an unusual path. The first three miles were downhill and fast, the next three were uphill and slower, and the next three were flatter and down in a steady 25:30.

My time at the halfway mark was 1:51:51. After fifteen miles, I was at 2:07:36 -- still on an 8:30/mile pace. It seemed too good. I need to look up my times from previous races, but I think that these may be my best times ever at those two points in a marathon.

On top of it all, I felt good. At the Mile 15, I thought to myself, "I can do this." And I could, but not at that pace.

By mile 15, we had entered a 5-mile loop on soft trail through the Lime Creek Nature Center. My pace slowed for at least three reason. The course elevation map says this part of the race is flat, but that must be net rise. These miles were hilly. Add to that the overnight rain which had softened them up even more and created a little bit of mud for us. Slippery footing on hills means a slower pace.

The third ingredient was a dose of reality. My legs weren't quite ready to maintain the ambitious pace for a full marathon. I did manage a couple of miles at near-goal pace after leaving the nature center, but in general I had slowed down. I took a second restroom break at the 20-mile mark, which added more than a minute to my time but gave my legs a brief respite.

Then came miles 23, 24, and 25. My legs were dead, and my pace slowed further. I had another short reprieve when a half dozen of us experienced our own Des Moines moment in Mile 23. For a while in the last two miles, I chanted to myself just keep running. For some reason I had the strongest of desires not to walk even as my body had the strongest desire to stop. Somehow I kept moving. I never reached what one of my friend's calls "the dead man's shuffle", but my pace had slowed dramatically.

The last 0.2 of a mile snuck up on me. I felt a brief boost of energy as I crossed the Mile 26 marker and managed to run through the finish line with a smile on my face.

It was a tough finish. In retrospect should have gone out with 8:45 miles for 10, 15, or 20 miles and then taken stock of what I had left. That would have been the conservative approach, the wise strategy. But the siren call of 8:30 miles and a time near my PR was too much for my dreams, or my vanity. I had to know. Now I do! Going into the arena has a way of showing us reality.

This race was unusual for me in another respect. My wife and daughters made the trip with me. This was the first time I'd had family with me since my wife accompanied me to my first. They met me along the route a half dozen times or so, and seeing them boosted my spirits every time. It was easy for them to do this, which is one of the benefits of a race in a small town. I'll have more to say about a small town race in a coming entry.

So, I survived. Even with the rest stops, I ended up with my third-best time ever. After my experience the last two years, with dicey health, on-again, off-again training, and the mental doubts that came from those two, I really could not be happier with my time. Asking for more would be unrealistic and would devalue what turned out to be a good performance.

I could feel better physically, though. A few days' rest can give me that. Heck, I already feel like a short jog!

I know that you are talking about visual design, but I am struck by how this approach applies to many other domains.

But I could have.

I started university life intending to become an architect, and my interest in visual design has remained strong through the years. I was delighted when I learned of Christopher Alexander's influence on some in the software world, because it gave me more opportunities to read and think about architectural design -- and to think about how its ideas relate to how we design software. I am quite interested in the notion that there are universal truths about design, and even if not what we can learn from designers in other disciplines.

Garr Reynolds identifies seven principles of the Zen aesthetic of harmony. Like the commenter, my thoughts turned quickly from the visual world to another domain. For me, the domain is software. How well do these principles of harmony apply to software? Several are staples of software design. Others require more thought.

(1) Embrace economy of materials and means
(3) Keep things clean and clutter-free

These are no-brainers. Programmers want to keep their code clean, and most prefer an economical style, even when using a language that requires more overhead than they would like.

(6) Think not only of yourself, but of the other (e.g., the viewer).

When we develop software, we have several kinds of others to consider. The most obvious are our users. We have disciplines, such as human-computer interaction, and development styles, such as user-centered design, focused squarely on the people who will use our programs.

We also need to think of other programmers. These are the people who will read our code. Software usually spends much more time in maintenance than in creation, so readability pays off in a huge way over time. We can help our readers by writing good documentation, an essential complement to our programs. However, the best way to help our readers is to write readable code. In this we are more like Reynolds's presenters. We need to focus on the clarity and beauty of our primary product.

Finally, let's not forget our customers and our clients, the people who pay us to write software. To me, one of the most encouraging contributions of XP was its emphasis on delivering tangible value to our customers every day.

(7) Remain humble and modest.

This is not technical advice. It is human advice. And I think it is underrated in too many contexts.

I have worked with programmers who were not humble enough. Sadly, I have been that programmer, too.

A lack of humility almost always hurts the project and the team. Reynolds is right in saying that true confidence follows from humility and modesty. Without humility, a programmer is prone to drift into arrogance, and arrogance is more dangerous than incompetence.

A programmer needs to balance humility against gumption, the hubris that empowers us to tackle problems which seem insurmountable. I have always found that humility is a great asset when I have the gumption to tackle a big problem. Humility keeps me alert to things I don't understand or might not see otherwise, and it encourages me to take care at each step.

... Now come a couple of principles that cause me to thing harder.

(2) Repeat design elements.

Duplication is a bane to software developers. We long ago recognized that repetition of the same code creates so many problems for writing and modifying software that we have coined maxims such as "Don't repeat yourself" and "Say it one once and only once." We even create acronyms such as DRY to get the idea across in three spare letters.

However, at another level, repetition is unavoidable. A stack is a powerful way to organize and manipulate data, so we want to use one whenever it helps. Rather than copy and paste the code, we create an abstract data type or a class and reuse the component by instantiating it.

Software reuse of this sort is how programmers repeat design elements. Indeed, one of the most basic ideas in all of programming is the procedure, an abstraction of a repeated behavioral element. It is fundamental to all programming, and one of the contributions that computer science made as we moved away from our roots in mathematics.

In the last two decades, programmers have begun to embrace repeatable design units at higher levels. Design patterns recur across contexts, and so now we do our best to document them and share them with others. Architectures and protocols and, yes, even our languages are ways to reify recurring patterns in a way that makes using them as convenient as possible.

(4) Avoid symmetry.

Some programmers may look at this principle and say, "Huh? How can this apply? I'm not even sure what it means in the context of software."

When linguistic structures and data structures repeat, they repeat just as they are, bringing a natural symmetry to the algorithms we use and the code we write. But at the level of design patterns and architectures, things are not so simple. Christopher Alexander, the building architect who is the intellectual forefather of the software patterns community, famously said that a pattern appears a million times, but never exactly the same. The pattern is molded to fit the peculiar forces at play in each system. This seems to me a form of breaking symmetry.

But we can take the idea of avoiding symmetry farther. In the mathematical and scientific communities, there has long been a technical definition of symmetry in groups, as well as a corresponding definition of breaking symmetry in patterns. Only a few people in the software community have taken this formal step with design patterns. Chief among them are Jim Coplien and Liping Zhao. Check out their book chapter, Symmetry Breaking in Software Patterns, if you'd like to learn more.

A few years ago I was able to spend some time looking at this paper and at some of the scientific literature on patterns and symmetry breaking. Unfortunately, I have not been able to return to it since. I don't yet fully understand these ideas, but I think I understand enough to see that there is something important here. This glimmer convinces me that avoiding symmetry is perhaps an important principle for us software designers, one worthy of deeper investigation.

... This leaves us with one more principle from the Presentation Zen article:

(5) Avoid the obvious in favor of the subtle

This is the one principle out of the seven that I think does not apply to writing software. All other things being equal, we should prefer the obvious to the subtle. Doing something that isn't obvious is the single best reason to write a comment in our code. When we must do something unexpected by our readers, we must tell them what we have done and why. Subtlety is an impediment to understanding code.

Perhaps this is a way in which we who work in software differ from creative artists. Subtlety can enhance a work of art, by letting -- even requiring -- the mind to sense, explore, and discover something beyond the surface. As much art as there is in good code, code is at its core a functional document. Requiring maintenance programmers to mull over a procedure and to explore its hidden treasures only slows them down and increases the chances that they will make errors while changing it.

I love subtlety in algorithms and designs, and I think I've learned a lot from reading code that engages me in a way I've not experienced before. But there is something dangerous about code in which subtlety becomes more important than what the program does.

Blaine Buxton recently wrote a nice entry on the idea of devilishly clever code:

But, it got me thinking about clever and production code. In my opinion, clever is never good or wanted in production code. It's great to learn and understand clever code, though. It's a great mental workout to keep you sharp.

Maybe I am missing something subtle here; I've been accused of not seeing nuance before. This may be like the principle of avoiding symmetry, but I haven't reached the glimmer of understanding yet. Certainly, many people speak of Apple's great success with subtle design that engages and appeals to users in a way that other design companies do not. Others, though attribute its success to creating products that are intuitive to use. To me, intuitiveness points more to obviousness and clarity than to subtlety. And besides, Apple's user experience is at the level of design Reynolds is talking about, not at the level of code.

I would love to hear examples, pro and con, of subtlety in code. I'd love to learn something new!

Phantom got its start with casino games. They started from scratch, with no training in software development. Part of the team did have background in graphic design, which gave them a foundation to build on. In the last decade, they have became serious players in the market, with several top-selling titles.

I'm am not a "computer gamer" and rarely ever play the sort of games that are so popular with students these days. But as a computer scientists, I am interested in them as programs. Nearly every game these days requires artificial intelligence, both to play the game and, in character-based games, to provide realistic agents in the simulated world. My background in AI made me a natural local resource to the company when they were getting started. As a result, I have had the good fortune to be a long-time friend of the company.

Aaron's talk was like the game; it had something for almost everyone: history, creative writing, art, animation, media studies, and computer science. The CS is not just AI, of course. A game at this level of scale is a serious piece of software. The developers faced a number of computational constraints in filling a screen with a large number of realistic humans and while maintaining the frame rate required for an acceptable video experience. There were also software development challenges, such as building for multiple platforms in sync and working with contractors distributed across the globe. There is a lot to be learned by conducting a retrospective of this project.

Aaron spoke a lot about the challenges they faced. His response was the sort you expect from people who succeed: Don't be dismayed. Do you think you are too small or too poor to compete with the big boys? Don't be dismayed. You can find a way, even if it means rolling your own gaming engine because the commercial alternatives are too expensive. Don't know how to do something? Don't be dismayed. You simply don't know yet. Work hard to learn. Everyone can do that.

The practical side of me is glad that we are so close to a company like this and have connections. We've recently begun exploring ways to place our students at Phantom EFX for internships. I love the idea of running an iPhone development class to port some of the company's games to that market. This is a great opportunity for the students, but also for professors!

The dreamer in me was inspired by this talk. I am always impressed when I meet people, especially former students, who have a vision to build something big. This sort of person accepts risks and works hard. The return on that investment can be huge, both monetarily and spiritually. I hope more of our students take stories like this to heart and realize that entrepreneurship offers an alternative career path when they have ideas and are willing to put their their work hours toward something that they really care about.

At its bottom, this is the story of small-town Iowa guys staying in small-town Iowa and building a new tech company. Now they have Hollywood producers knocking on their doors, bidding to option their script and concept for a major motion picture. Not a bad way to make a living.