Ken Auer

''Since much of the initial stuff on this page was written, I started my own company (Role Model Software - rolemodelsoftware.com ). You can find out more about me there (www.rolemodelsoftware.com ). Although most of this page has been rewritten, I have left snippets of old stuff in italics that I think is less relevant today to allow people to see how some of my thinking of what was important has evolved through the experience of the last few years (my initial wiki pages were written sometime in 1995 I believe). To see what I think were the major contributors to where my head is now, skip the rest of the italics. -- Ken Auer''

In 1998, I decided (through divine prompting) to turn my business from a one person company into something bigger. This is taking the form of the Extreme Programming Software Studio (TM). As you can read about the marketing view of it there, I've decided to use this space to give a little more background of how I got to this place.

I was first introduced to Patterns by Ward And Kent at the 1987 OOPSLA Workshop hosted by Norm Kerth. Of all the presentations and discussions there, I was most intrigued by Patterns

(not to mention Ward And Kent) as they seemed to be very practical vs. theoretical

(although first swags at them tend to be theory based on practice). I accosted Kent Beck after the workshop and introduced myself to him, asking him for some career advice and complementing him for being a "guru"... this inflated Kent's ego and earned me the right to hang around him at later OOPSLAs. Although I didn't really do anything about patterns for the next few years, they were always in the back of my mind and I felt that they addressed the real "stuff" of building software

(and possibly doing other things less nerdy).

Shortly after OOPSLA '87, I left Paradyne Corporation and entered the world of Consulting, becoming the second full-time technical guy at Knowledge Systems Corporation.

(Sam Adams being the first). Although Sam and I had very different personalities and approaches to things, we were always interested in practical "stuff". We hooked up with Ward at OOPSLA'88 to learn about what Ward had been doing with CRC cards.

I've found to this day that CRC cards are a great way to introduce people to working in teams on the same problem and to focus on the responsibilities of an objects (which I believe is essential to keep in mind throughout development). I make heavy use of them in the "Object-Oriented Thinking & Techniques" course I use, and have found them to be one of the best ways to get people to think OO. CRC is probably a better tool than anything I've seen to get people in sync on big picture issues. The thing that I think many people have missed over the years is the importance of the group dynamic and how CRC promotes it rather than breaks it down via the issues in Design Reviews Hurt The Team.

In 1988, I also attended Norm's second workshop in 1988 where Patterns came up again

(Ward Cunningham and Roxie Rochat presented some findings of Monday School, a Tektronix study group). About that time, the Tek group started moving on to other things. Ward joined Knowledge Systems Corporation for a short time before deciding he didn't really want to move away from Portland, but long enough for me to benefit from more of his wisdom and develop a professional and personal friendship. For the next few years, it seemed all of us were learning all kinds of Patterns, without necessary realizing that this is what they were. Although I wasn't at the OOPSLA '91 Architecture Handbook Workshop that brought Patterns back to life, I heard about their resurgence through my relationship with Kent Beck and caught the bug again. Kent invited me to the first Generative Patterns Workshop in Colorado (as payback for inflating his ego back in 1987) and we were off.

The key for me about patterns is the ability to capture wisdom that can be shared whenever necessary and force people to express their wisdom... many people have it but only express it as facts. Without elaborating the "why", people don't learn as well or as deeply. Worse yet, they may reject it because of the lack of understanding.

Since then, I've written a bunch of patterns in an attempt to extract the knowledge that's in my head from doing "stuff" with Smalltalk and other areas of expertise (building frameworks, using Java, leading teams, mentoring) into a form from which I hope others can benefit. As the industry has taken off, I had been finding it harder and harder to transfer that knowledge in a one-on-one basis... it used to be a lot easier when I could only find about one person at a time who actually thought they could learn something from me and wanted to put up with me to do it.

In 1993, I'd half-written a Pattern Language For Using Envy Developer (different in many ways from the stuff that Bobby Woolf wrote... but he did read mine first and probably improved a bunch of it), and a bunch of individual patterns for various idioms in Smalltalk. Since the early days of my time at KSC, Sam Adams and I were big proponents of not accessing instance variables directly. Ward And Kent always argued with us about it. So, in 1994, I saw patterns as a means to put down on paper exactly why I was right, and Ward And Kent were wrong. At the second Hillside Group meeting, I worked with Richard Helm and Bruce Anderson to discuss how the different pieces of my coding philosophy would fit together to solve all the forces I felt it solved. It was a neat exercise in pulling patterns out of ones head and into a "mostly ordered" group of patterns that together generated something much bigger. The current result of this is in the PLoP'94 proceedings, Chapter 27, "Reusability through Self Encapsulation". (By the way, I still haven't converted Ward And Kent, but they at least appreciate the benefits and I've even heard Kent Beck promoting the patterns at times, although he may not admit it publicly)... I approach Java a bit differently for a variety of reasons. As soon as I figure out and find the time to articulate them, I may produce related patterns there.

While I was still there, I looked at my patterns role at Knowledge Systems Corporation as a mentor and promoter. I pushed Patterns there, and about half of the staff actually bought the PLoP book. In addition to writing some of their own patterns many of the KSC staff (e.g. Bobby Woolf, Kyle Brown, Dana Anthony) began incorporating them actively into their training and consulting gigs, with great success I might add... these are all pretty well-known people in the patterns community now and have a great track record.

I also co-authored the Lazy Optimization Patterns for Efficient Smalltalk Programming with Kent Beck. Both of us wanted to write them but neither of us wanted to take the time away from family and other commitments, so we compromised and did them together. Actually, we took turns writing drafts and e-mailing them back and forth. I like the way it worked out, although I'd like to add a few more patterns to it someday.

I consider myself a Reflective Practioner and Technical Leader. I make sure I keep my hands dirty coding in between helping others understand how to apply the technology and getting a better handle myself on what works best and what is just noise. I am not a methodologist and don't aspire to be one, but rather a master craftsman. One of my favorite sayings is based on something Kent Beck said at one of the Hillside Group gatherings, "We're either going to do stuff, or talk about stuff, but we don't want to start talking ABOUT ABOUT stuff!". My pet peeve is methodologists or high-level consultants who draw pretty pictures that simplify what needs to be done and then say something like "the rest is just an implementation detail". Implementation details and what some would call low-level design is what I focus on (although I realize the higher level stuff is necessary and valuable... it's just not very valuable if it doesn't result in something that runs). I'm skeptical of people who want to avoid "low-level design" because I fear that they really don't know enough to realize the implications their high-level design has on the "stuff" that actually has to get done. I'm also very interested in the people side of getting software developed as I've seen so many projects go wrong due to everything but technology issues. Not to mention I think people are more important than things, even soft things.

In fact the "people" side of things is what eventually led me to leave Knowledge Systems Corporation. The corporate culture started as one that encouraged a great team to cross-fertilize each other with wisdom gained from doing practical stuff while having great respect for the individual and their personal growth. As one person put it when we were talking about our corporate values, "We believe everyone has a life outside of work or should get one." This never kept us from aspiring to do (and accomplishing) great things... in fact it did quite the contrary. At the time I left (and several years before) that had changed. The demise of KSC (at least my analysis of it) is something that I'd rather leave off the net. I will say that in order to stay and be appreciated by those in power I felt I would have had to work long hours and fly all over the country as a high-paid individual working the politics, mostly on projects I wouldn't have chosen as good business in the first place... maybe I was wrong in thinking that, but that's water under the bridge. It certainly made me realize what I didn't want to do.

For several years, I saw that the company had taken a turn for the worse on many fronts, but staying there was still more attractive than most of the long-term alternatives I saw and I've never been one to "go for the quick buck". The Lord used that time in my life to learn a lot about various aspects of business and solidify my thoughts on how a business should be run. Eventually he led me to take the step of faith and form my own company. Although I had a pretty good reputation in various pockets throughout the country, my family was more important than the prestige, so I decided to focus on work I could do while being at home almost every night. I examined what I could do best, and realized it was building long-lasting assets and teams that could do so. Although I'd had a fair amount of success improving software and teams that were in a mess before I got there, I found I was better at keeping things from getting to that state in the first place and enjoyed it more. Unfortunately, few people in the area knew that. My dream was to get a bunch of local clients with whom I would build great teams to build great software. But where could I start?

The first goal was to make sure my family ate without compromising on the travel and the quality of the work. The Lord sent the work and I did most of it by telecommuting. We had just begun Home Schooling officially, and having everyone at home at once was really cool. I wouldn't trade that time for anything, but working by myself at home was far from building a team (other than the team of my family which was doing fine and aren't really interested or currently able to program worth a lick).

The Lord has really used working out of my home and Home Schooling my children to reshape my thoughts about the importance of working in the same building as other people... He is continuing to increase my understanding on all this. On the one hand, being in the same building as my family has made a huge positive impact on our relationships and their ability to help me be more effective. But some of the ideas of Extreme Programming (Pair Programming, etc.) resonate with my other experiences. Yet, I found I was more productive at home (when I applied myself), than I had been in recent years because I get to crank without many interruptions and I was also much more productive when I went to a client's office because I knew that I'd spend more time away from home if I didn't get everything I needed to get done there. I wondered how much the effect of Kent Beck not being at Chrysler all the time actually helped make him more effective. I couldn't find a Process Pattern that explained what I was thinking and thought I might have to write one.

At the same time, the Lord was using what I was learning with respect to Home Schooling, His church, and what I had learned all those years at Knowledge Systems Corporation about the importance of life-on-life learning. I realized I was applying these principles well in other areas of my life, but not in my workplace. I had seen, been a part of, and created many productive and wholesome teams, but not since I started my business. I had been discussing Extreme Programming with Kent Beck and resonating with what he was doing based on my experience (there is not a single practice I hadn't done in some way, but never all together at once in the way he was suggesting/doing), but my desire to telecommute made it hard to adapt it.

Then, the work I was doing making myself known in the area and the Lord's timing kicked in. I started getting local clients. When I telecommuted with them, it wasn't the same. I started doing Extreme Programming with great success for a week or two at a time, and was seeing most of the benefits on a small scale, but then go back to my office by myself. For a day, things were fine, but it became very obvious that it wasn't as good.

Anyway, the Lord is giving me a (currently fuzzy, but getting clearer everyday) vision of where I'm heading with all of this. My current vision http://www.rolemodelsoftware.com/moreAboutUs/missionVision.php www.rolemodelsoftware.com statement uses some phrases that are jam-packed with meaning for me, but hard to articulate succinctly: Unusually Adaptable Software, Inter Generational, Biblical Model Of Training.

(1998) I built a bigger office up in my attic with the idea of Extreme Programming in mind... unfortunately it is too small to do it on the scale I envision (10-20 people working on 2-4 projects at any one time), but we will get there in due time... I am currently scoping out some real estate close by. I have also found ways to get my family more involved in my business and that is evolving as my children grow, so we are not really sacrificing family time for the business. (There have been times that have been a strain... growing a business is not easy). I want other employees to bring their family into the workplace whenever it makes sense. (see below).

I hired an apprentice, Nathaniel Talbott, and determined that we were going to do everything as Extreme as possible. He has been working here since December 1998 and we have added others since then both permanent and subcontractor. We will grow as fast as the Lord wants us to. Sometimes that seems too fast, sometimes it seems too slow, but it is always just right.

I would love to have the customers come to our studio, but we are not ready for that yet and neither are they in general. So we have been doing most of our work with our clients at their site and incorporating their developers into our team (see Xp Carolina). As we get a better understanding of the client domains and better relationships with the customers, we are hoping to do more at our studio. We are also doing some tools and R&D stuff in the studio.

Most of the above was written in 1999-2000. Here is an update.

The Xp Carolina project continues without our help. Product has been released and XP has infiltrated more of the company in a variety of ways.

We have done work with some other clients and have actually built the studio in the confines of a business condo. We're doing more and more of our work at our own studio. If the client let's us, we configure some space at their place. So far, we have not gotten any customers to "live" there, but several visit. They like to come to the studio. We've found ways to make things work without Customer On Site, but still find it better when the Customer is actually there. We've learn to live with Customer Always Available.

We've had Laurie Williams and some of her students observe the environment and they are amazed at the productivity of the environment.

As of December, 2000 we had 8 full-time developers (plus a part-timer), one full-time Operations Manager and part-time Director of Business Relationships. In January 2005, we have up to 10-12 people working in the studio at a time and have found ways to decrease overhead (non-software-development people) to a minimum.

We just purchased some land (April 2005) and have subdivided it to build a community from the ground up and, if/when we nail it down (and build it up) I'll be moving my family and the business there so I can walk to work. We are hoping to be moved in sometime in 2006 (best guess as of December 2005 is summer of 2006 - our county is definitely not agile... don't get me started)... initial plans are to work from a large area attached to, but separate from the house. We are also reserving a lot next to us to put up a slightly larger building at some future point. (Right now, many of our employees work at local client sites where we've configured several team rooms... it's hard to say how much space we'll need long term, so we're trying to stay agile - I still have the business condo and won't sell it until I know I don't need it). Several others who work here have shown interest in moving close to the new studio, too. Stay tuned...

There's a push for telecommuting by lots of software professionals (and everyone else). But our society has adopted a lot of things over the years that keeps people from having to deal with other people and I believe it's not a good thing. There are many things that are better done in teams than by yourself. Building physical structures that people live in is one (ever try to put up sheetrock by yourself). I'd argue that building software is another.

I still telecommute at times. It can be great at times. But it's not the best way to build great software no matter how good a developer you are and it doesn't do much for the life-on-life angle. I've found that very few people who have telecommuted for extended periods of time, and value the benefits of being a part of a productive team, find telecommuting being a big issue to them later (they'd rather work in a good team environment). Although having the option of working at home every once in a while, or for a few hours at a time is almost always desirable... I already offer that to my employees, and plan on continuing to offer that. Once someone is part of the team, there is very little question as to when it makes sense and when it does not. Until they are part of the team, there is very little reason to encourage telecommuting. How long it takes for them to really be part of the team will depend on the team and the individual. Nathaniel originally desired to spend more time at home, and I insisted he came here to which he submitted. Now he works at home every once in a while and it's not an issue. There are very few tasks which he should be doing by himself and he knows it. When they come up, he simply tells me that he thinks he'll just stay home for a day or half-day and does it.

If you only lived a few (e.g. less than 5) minutes from your place of work, and the company gave you the freedom to go to/from work when needed, would telecommuting be an issue? If not, the question then becomes one of moving closer to where you work or working closer to where you live.

I believe the perfect (or as close to it as is possible on earth with humans) would be to have a place of business with the people's families within a short walk away, coming and going as it made sense... (e.g. "I need to take a long lunch with the kids while my wife has a doctor visit", etc.). This would include employing the wife and children at times for tasks at the place of business. I may end up moving someday to build just such a place, but the need isn't that great for me to do so right now and I'm not sure how realistic it would be to both find and purchase the right place and get everyone else to move there, too.

Personal Info:

Because I believe people are more important than things, when I'm not working, I spend very little time dealing with computers. Until I got serious about starting my own business I didn't even own my own.

After trying to run my own life and impress people for many years as to how important I was, I realized that any significance I have is due to what the Lord has done for me (I'll be happy to share how the Lord brought to this point to anyone who cares to hear it). I believe we are on this earth to serve God and in so doing, encourage others to reach their full potential by accepting Jesus Christ as their Lord and Savior who will take them just as they are and then enable them to be all they can be (which is far more impressive than anything they can achieve on their own). I live in a rural area south of Raleigh with my wife and two children and try to spend as much time as I can there with them and other people. I take my responsibilities of training up my child in the way she should go (Proverbs 22:6, Deuteronomy 6:4-9, Ephesians 6:4) and loving my wife as Christ loved the church (Ephesians 5:25) as two of the most important things I can do on this earth. As cool as patterns are, they're basically insignificant in the grand scheme of things.

I've built a trail system in the woods we own (and are adjacent to) and love being in the outdoors (hiking, walking through the stream, making smores by the campfire) and feel that being outside helps me focus on the One who created us all and the world which we live. If you're ever in the area and want to take a stroll through the woods and discuss patterns or life, look me up.

Joshua 24:15b "As for me and my household, we will serve the Lord"

Ken, refactoring another page led me to add a link above to the Monday School. -- a Wiki Gnome

Ken, enjoyed reading your story -- another Brother -- Bruce Pennington Category Home Page

See original on c2.com