Three in a Row

I just got home from a 3-in-a-row conference marathon. First I went to the Patterns of Programming Language Conference or PLoP in Nashville, where our paper Dynamic Factory, co-authored with Leon Welickiand Joe Yoder, was shepherded in a writers’ workshop. This was my first PLoP where I actually had fun. Our writers workshop group was a sharp group and gave everyone excellent feedback. The first time I had a paper workshopped at PLoP a couple of years ago I was disappointed about the quality of the feedback. Speaking with more seasoned patterns conference attendees, I learned that workshopping is hard work–and not always does it work out well. It takes a combination of a skilled workshop leader, workshop attendees who’ve critically read their papers, and a good mix of insight and discussion. Sometimes, even with the best intentions a workshop doesn’t deliver good feedback to every paper. When everything comes together the results are amazing.

Then it was on to OOPSLA where 750 geeky souls met to discuss programming languages, design, practice, and what the next software trends might be. At OOPSLA I presented a keynote, What Drives Design? that I’d spent the last five weeks working on. I talked about the main ideas behind Responsibility-Driven Design (the first, “driven” method) and then compared and contrasted several different design methods. For the record, I characterized TDD as “design between the keystrokes” and Feature Driven Development as “Design first, program next.” Truth be told there is a lot of design that happens when people practice TDD. But refactoring isn’t the same as initial design ideating. It still begs the question, when do you do an initial design (if ever)? Is it always at the keyboard? Scott Amber, with Agile Model Driven Development interjects a “model when you need to” front end to TDD practices. Not specifying what you should model, but giving people the framework to plug in non-programming design efforts when they think they need them.

Last week I was at SD Best Practices in Boston–the consummate conference for those seeking technical trends and practical advice. I presented my tutorial,The Art of Telling Your Design Story, and a talk on Giving and Taking Design Criticism. At the conference I enjoyed hearing Neal Ford take a swipe at the inefficiencies/unnecessary clutter of implementing design patterns in traditional (read non-dynamic) languages. Neal is a compelling speaker. At the end of his talk I was convinced that Ruby doesn’t have anything over Smalltalk. Neal confirmed my thoughts about Smalltalk. Still, I plan on taking a deep dive into Ruby this winter.

I’m somewhat concerned when DSL-makers tack on behaviors to any class of thing in order to have a fluent language. While that may work in the short run, I’m betting meta-programming tricks and behavior hacks to basic classes won’t scale. Call me a traditionalist, but I remember the clutter of extra behavior tacked on to Objects, Integers and Strings causing real problems in Smalltalk. It wasn’t considered good practice then…and I’m not sure I’d make the same “fluent language” tradeoffs Neal wood. Still, his talk got me thinking.

I also enjoyed hearing Rick Brenner’s Organizational Politics for Those Who Hate Politics. While I don’t have office politics to contend with in my own business, I do encounter lots in my clients. SD Best Practices is a conference where you can blend geek topics with management or professional development topics and come away feeling well-rounded.

OOPSLA, Creativity, and Practice

I’m home for 2 weeks after spending a week at San Diego at OOPSLA and last week teaching object design. It is good to be home as I can now configure my new tablet PC and start using it. It’s bad to be home as it is raining too hard and spoiling my plans for getting my perennial garden in shape for the winter. But truth be told, the rain leaves me hunkered down inside, forcing me to write, to reflect, and start new projects.

OOPSLA this year was full of creative types: George Platts led a number of workshops and experiences; Robert Hass, past poet-laureate of the USA, gave the keynote. This was no surprise with Dick Gabriel as program chair. Dick is a man of many talents. In addition to his heavy-duty computer side—having made Lisp implementations practical being one of Dick’s early accomplishments—he is a published poet, musician, patterns instigator, Sun fellow, and scholar. A highlight for me was getting Dick to autograph his new book of poetry Drive On and then to read it on the plane ride home.

Sunday morning I attended the tutorial, “How has the arts, sports or life stimulated, inspired and informed your work in computer science?” led by George Platts. George is an artist and game master who is a well known creativity/fun instigator at software pattern conferences. As it was a Sunday morning tutorial, I expected George to drive (and me to sit and quietly soak up his words). Silly me. After showing us an incredible film of an amazing panoply of pyrotechnics, mechanical feats, oozing chemical reactions crafted to produce a Rube Goldberg-like perpetual motion machine, we sat down to discuss how art or sports stimulated or inspired our work.

Two thoughts struck me about how arts and sports have stimulated my work. In college I fenced (with a foil—don’t ever call it a sword). Much preparation went into a competition. We repeatedly practiced standard moves (all with Italian names). Only after much practice with attacks and counter-attack moves would we do practice competitions. Being a left hander gave me a distinct advantage as my body was not where it was expected to be. Lefties fencing lefties are on equal footing as we, too, are accustomed to fencing right handers. So even while I was at an advantage (being short makes for a smaller target and being a lefty makes for an unusual target) during the heat of a competition I’d forget much and just go on raw instinct. Only when moves and countermoves become kinetic memory do you get really good. I never got good as I spent too much time getting my programs to work instead of devoting energy to perfecting my fencing technique.

Bringing up this notion of practice led us to discuss what constitutes “practice” or “repetition of scales” for software developers. What do you developers or designers or analysts do over and over and over again until it becomes second nature and makes them good at what they do? Programming? Applying design patterns? Writing use cases? Learning how to ask probing questions? Well maybe. I’m not sure we software types have a clear equivalent of scales. Does repeatedly programming yet another JSP make you a better at it? Building consistency into your design makes your design better. But does it make you a better designer?

A second artful inspiration I’ve had is from Betty Edwards, author of Drawing on the Artist Within. Betty has inspired me as a teacher of design in how I try to break down design ideas and thinking for others. Betty claims that people are crappy artists because they don’t know how to see, and that by learning special ways of seeing, most of us could be able to become passable renderers of what we see. She believes everyone can be taught how to draw likenesses of what they see. I had a really bad pottery teacher in college who asked us to “feel what was in the clay and then create”. I was frustrated and created lumpy awkward pots because I lacked technique and this instructor didn’t teach any technique. As a teacher of software design I don’t like it when my students create lumpy malformed objects. I teach them a number of techniques for seeing good formations of objects—role stereotypes, a smattering of patterns, the notion of domain entities and value objects from Eric Evans’ writing, a sense of control style choices. But sometimes these ways of seeing don’t click in and my students create strange designs. Or worse yet they get frustrated and just want to know what steps to go through to create passable designs; to heck with all this technique. All I can say is that design takes practice and reflection and technique. I don’t know how to teach design as a rote process.

As a result of George’s tutorial, I got to know Henry Barager of Instantiated Software Inc. Besides being a skilled software architect, Henry’s a whiz at cryptic crosswords. Over lunch one day at OOPSLA Henry taught me about cryptic crosswords by working through one with me (Henry did most of the work but he patiently let me solve a few entries after explaining the basic idea). The key to solving a cryptic crossword entry is to figure out how to separate the word or word phrase you are solving for from the encrypting part. Then there are clues in the encrypting instructions part which may lead you to take some letters and jumble them (key words may imply that you create an anagram, wrap one word inside another, truncate a word, etc.) or not. For example: Flower came up. The answer is Rose. Rose is a flower, and “came up” is another meaning for rose. Simple, right? Well try this: Piece of technology in broken device tossed out. Give up? It is evicted (tossed out = evicted, that’s the definition. The rest of the encrypting part is this: A piece of technology is the “t”, broken device is “evice d”, device jumbled or broken).

Explaining the idea behind cryptic crosswords is fairly simple. Solving entries takes a lot of effort and getting your brain in a problem solving frame of mind. Solving them in real time as Henry does requires skill, experience, and intelligence. Teaching others how to solve them takes another kind of skill. The same goes for object design. Learning object concepts is trivial. Crafting simplistic solutions is, too. Putting together elegant designs that work for complex problems is much harder. It requires practices, reflection, as well as learning techniques from masters who shouldn’t try to solve all the hard problems for you. I wish I’d had someone who would’ve demonstrated and helped me practice good technique when I was learning to shape pottery or to draw. I was fortunate to rub shoulders with some very bright Smalltalk folks when I was learning how to think in objects. Thanks to all the folks at Tektronix and Instantiations for teaching me how to see and build object designs.

Musings of an OOPSLA elder

I don’t think of myself as an “elder”. But that is what Linda Rising, who led the 20th OOPSLA retrospective, labeled those who were at the first OOPSLA. I am one of five who received a perfect attendance ribbon (Allen Wirfs-Brock, Brian Foote, Ralph Johnson and Ed Gehringer are the others) for having attended all OOPSLAs. At the very first OOPSLA I felt like an outsider. I wondered how I could get involved with this conference. Excitement was in the air. Objects were the next big idea. Just exactly what could I do that would have an impact? My paper on Color Smalltalk was rejected (the reviewers’ commented that it talked too much about hardware details) so I presented it as a poster. It was good that they rejected it. Our work was premature. Three years later, when Tektronix Color Smalltalk was finally a product, I wrote a paper about the design principles and class libraries in Color Smalltalk that was accepted. This success made me believe in my writing abilityand led to my paper with Brian Wilkerson on Responsibility-Driven Design in 1990, and launched my enduring interest in design.

Thursday I had another elder moment. I was on a panel with Ed Yourdon, Larry Constantine, Grady Booch, Kent Beck, and Brian Henderson-Sellers that looked back at echoes of the past and structured design and into the future. Larry Constantine provoked us to bring theory, technique and transparent tools into all we do. Kent brought the house down by quoting from Structured Design. He noted that while Ed and Larry got a lot right, they missed out on the fact that systems need to change. Refactoring wasn’t part of Ed and Larry’s vocabulary. Ed, who has been an expert witness on software cases for the past few years, noted that there often isn’t even a shred of a plan or design or any documentation for software systems. Grady mentioned that increasing abstractions have been a big factor and challenged us to move to even further levels of abstraction. More down to earth, I spoke about how objects enabled me to think clearly, and that the power of abstraction, encapsulation, and thinking in terms of small neighborhoods of collaborating, responsible objects as a big step forward. What’s next? To me, it seems that even more effective methods and practices, powerful development and testing environments, expressive languages, patterns, and thinking tools are in our future. Innovation in our industry is a constant. Yet every once in a while it is good to reflect on what we got right and remember influences from the past. But I’m forward looking too. After every OOPSLA I come home charged with new ideas and the urge to do more, collaborate, and continue learning. What a blast!

Why Objects?

As I’ve been working on a position statement for an OOPSLA panel reflecting on the roots of modern software development practices while looking to the future, I’ve been thinking hard about why I got hooked on object technology. Compared with structured programming and design, objects seemed significantly better at handling complexity. Object programming languages were an earth shattering improvement over the procedural and assembly languages I used when I first encountered structured design techniques. Instead of simply following conventions, object programming language constructs forced me to bundle together meaningful operation and data. Object-oriented methodologies generally incorporate the principles of structured design but OOD seems much more than an incremental improvement over SD. Instead of focusing on a thread of control and managing its complexity via procedural decomposition and structured control constructs, object design enables me to break a composition into thousands of semi-autonomous entities with structured roles and responsibilities. Objects offer me a completely different way to think about computation. This way of thinking empowers me to deal with a level complexity that I could never have dealt with only using structured design techniques. Object technology encourages me to form abstractions—objects—and to design how small neighborhoods of them interact.

Responsibility-driven design offers thinking tools that enable developers to conceive of an implementation in terms of interacting roles and their responsibilities. It provides a vocabulary for describing designs that helps developers communicate complex ideas and make tradeoffs more effectively. Agile practices, by emphasizing working code that satisfies customers, seek to reduce accidental complexity by admonishing you to design simply and grow complexity only when needed. Eric Evans, in Doman-Driven Design: Tackling Complexity in the Heart of Software, offers tactics for identifying, preserving, and sharing a common domain model. Refactoring tools have taken tediousness out of making changes and modern application development environments have made it possible for development teams to “hum” by testing and building incrementally. These all represent progress.

But at the end of the day, they cannot reduce the complexity inherent using diverse tools, platforms, and technologies that make up a typical sprawling IT system. While OOD/OOP did give us an order of magnitude improvement over previous techniques and tools, we still don’t have the order-of-magnitude better approach we need to sort today’s complex environments and minimize the gaps and seams that are inherent when diverse technology comes together in a complex system. In the meantime, thank goodness for the framework builders who give us various ways of linking objects with relational databases and for little languages and tools that take the tedium out of repetitive (error prone) tasks of gluing things together. We live in a complex world where objects will continue to make a lasting, significant contribution. What will be the next breakthrough in software development that will subsume the principles of OOD (and transitively SD) and provide the next order of magnitude improvement? I’m not sure. While I don’t think there are any silver bullets out there, I look forward to discovering and encountering even more effective practices, technologies, and techniques that allow us to address inherent complexity head on.