Kevin P. Taylor

"Self-Education and the Craftsman" SCNA Presentation

My favorite conference of the year was, not surprisingly, this summer's Software Craftsmanship North America, which was co-organized by Obtiva.

The presentations were challenging, diverse, and at times, uncomfortable. Because of several of those presentations, I've since had opportunities to question my own closely-held beliefs about our profession and my career as a professional programmer.

The presentation that had the biggest impact on me personally was Michael Feathers' "Self-Education and the Craftsman." (See the whole presentation.) Maybe this is because I am largely a self-educated programmer myself. And, many of the best hackers I've worked with have been self-educated. (That is an interesting phenomenon in our industry, which I'll save for a future post.)

Instead of a list of flavor-of-the-day APIs, frameworks, and languages, Feathers gave us a laundry list of important programming language topics that are widely-unknown or misunderstood among otherwise well-heeled programmers. These are topics that separate the master from the journeyman.

(Of course, it takes more than knowledge to achieve mastery. As George Leonard explains in Mastery, "to achieve mastery, you must practice a new skill patiently, diligently, and consistently."

Language Topics

In Feathers' talk, there was hardly a mention of Ruby on Rails or Spring 2.x or the JVM. Instead, he gave us this list of topics to wrestle with:

• Big-O, Little-O, Theta Notation,
• Covariance and contravariance,
• Types,
• Objects are closures,
• State machines,
• Regular expressions and automata,
• Turing machines,
• Halting problem,
• Worse is better,
• Redundancy is not a strength: How to make logic stronger,
• Security on Sand: "On Trusting Trust"
• Location transparency is a myth,
• Objects are clay.

Book Recommendations

In addition to the above list of topics to review or introduced myself to, as the case may be, Feathers gave us this list of must-read books:

• Structure and Interpretation of Computer Programs, by Abelson and Sussman
• Designing Object Systems, by Cook and Daniels
• Graphs: Theory and Algorithms, by Thulasiraman and Swamy
• Compilers: Principles, Techniques, and Tools, by Aho
• Discrete Mathematics with Combinatorics, by Anderson
• Introduction to the Theory of Computation, by Sipser

SICP Study Groups

Another of the outcomes of the Feathers presentation was the formation of several SICP study groups, based on his recommendation of the book.

Compilers: Principles, Techniques, and Tools study group, anyone?

SICP Study Groups

One of my favorite outcomes from this summer's Software Craftsmanship North America conference, which Obtiva co-organized, is the SICP study groups. SICP refers to the MIT computer science textbook, Structure and Interpretation of Computer Programs, which is one of the most lucid, and challenging, foundational texts on the subject of computer programming languages.

The reason I am so inspired by the SICP study group phenomenon is that it highlights what I love most about programmers, and more specifically, software craftsmen. Even before we used that label, passionate hackers have been forming user groups, book clubs, IRC channels, and mailing lists, to gather, discuss, and challenge each other's ideas. And, through that, refine their own.

SICP itself is a walk through the esoteric Lisp dialect called Scheme. While on that walk, readers learn about abstractions, objects, closures, recursion, meta-programming, logic programming, and interpreters and compilers.

In fact, there are no mentions of any of the exciting new technologies, frameworks, or languages that will help land a gig. Nothing learned in the book will immediately increase the value of a resume or cause said resume to trigger a recruiter's keyword search on Dice.

So, why are dozens of experienced programmers, many of them the alpha-geeks on their teams, spending their time working through this difficult textbook together? They want to understand. The fundamentals. The whys. The history. The art. The craft. They want to understand the field.

The best professional basketball players on a team are also the last to leave the court after practice has ended. They continue to practice their free throw, their lay up, and their jump shot, long after teammates have showered and left the building.

We are practicing our jump shots.

Transitioning to a Second Stager, or "Damn, we did it!"

You're the leader of a multi-million dollar business. You have begun putting your management team in place. But, you work 50-60 hours a week. In fact, you are still involved in most day-to-day operations. You know you need to slow down, think strategically, and improve the business's ability to grow sustainably. 

If these statements describe you, congratulations! You've grown your company into a second-stager. It is no longer a startup.

As you'll have seen, a startup must do three things to prove itself: validate its business model; sell reference clients; and, of course, get its hands on cash. This is an all-or-nothing proposition, and the founders of a successful startup will be intensely-focused on succeeding on all three counts.

Then one day, the founders will pull their heads out of the oven, look around, and think, "Damn, we did it!" Keep a watch out for this moment. It will happen if you are one of the fortunate (yes, fortunate) few who make it this far.

The pull-your-head-out-of-the-oven-look-around-and-think-damn-we-did-it moment is an inflection point. It is a point on the growth curve of every business where the founders need to decide what is next and what needs to improve in order to get there. Chances are good that nobody on the team has thought quite that far ahead. Why bother thinking about market share, management teams, advisory boards, business efficiency, vision, BHAG, or mission, before a fledgling business has proven itself in the marketplace?

If you don't recognize the inflection point when it occurs, your company's growth will flatten out. The three concerns of the startup described above are not the only, nor likely primary, concerns of the second-stager. Not recognizing this will mean the founders will be focusing on the wrong priorities. Growth will stagnate, or worse, will become uncontrolled and possibly threaten the company's existence (the proverbial implosion).

To sustainably grow a second-stager, its leaders must embrace the following mandates:

1. Create a management team
2. Create organizational clarity
3. Over-communicate organizational clarity
4. Create systems to reinforce organizational clarity

Looking forward, in which of the above areas must you focus to move your second-stager forward?

Software Craftsmanship North America, August 26th, 2009

Software Craftsmanship North America is scheduled for August 26th, 2009. Conveniently, it will be held the same week as Agile 2009, also in Chicago. Even more conveniently, it will be held across the street from Agile 2009!

So, what is Software Craftsmanship and why am I linking a Software Craftsmanship conference to an Agile conference? I encourage you to visit the Software Craftsmanship Manifesto and the active Software Craftsmanship Google Group, to form your own opinions.

For me, Software Craftsmanship primarily represents two things: A school of thought within Agile that advocates the quality work and the collaboration that we see in developer-centric Extreme Programming teams; and, a focus on a holistic view of programming as a profession, with a beginning and a middle and an end, that can span a lifetime.

I am proud that my company, Obtiva, in collaboration with 8th Light, is organizing Software Craftsmanship North America. I am also excited to participate in the panel discussion, "The Business of Craftsmanship" with my friends, Carl Erikson and Micah Martin.

Upcoming Eclipse RCP TDD Tutorial at EclipseCon 2009

I am somehow continuing to push test-driven development in the Eclipse RCP developer community. My Test-Driven Development (TDD) for Eclipse RCP presentation that I gave a few times in 2008 has been promoted to a 4 hour tutorial for the upcoming EclipseCon 2009 (March 23-26).

When I give this talk, I always hear Eclipse developers ask, "I am a big proponent of TDD and use it in my projects. But, why do you think the larger community hasn't widely adopted it." I think this is primarily because the core Eclipse code base largely pre-dates TDD's rise--it is legacy code. It is simply difficult to TDD many situations unless you understand the techniques that I illustrate in this tutorial.

I have high hopes that the growing awareness and (more importantly) adoption of TDD techniques among the inner circle of Eclipse developers will positively impact the architecture and code base of the upcoming Eclipse e4.

EclipseCon 2008 Presentations

I'll soon be on my way to San Jose to present my experiences with Eclipse RCP development at EclipseCon 2008. The conference will be running from March 17th to March 20th.

In the 2-hour tutorial "Test-Driven Development (TDD) for Eclipse RCP" Nick Malnick, a fellow Obtivian, and I will be demonstrating practical techniques and tools for TDD'ing Eclipse RCP applications.

Yes, there are plenty of unit tests in the core Eclipse code-base. And, many teams developing applications on top of the Eclipse RCP platform are writing unit tests. But, very few true test-first development takes place in the Eclipse RCP community. People want to test-first—but the Eclipse code-base and architecture are simply not test-friendly.

Need an example? Try mocking out an SWT control using JMock or MockObjects. These are commonly used libraries in Java test-first development and totally unavailable to Eclipse RCP developers.

But, by putting the right tools in place, such as using the Model-View-Presenter (MVP) pattern and PDEUnit, true test-first development is within reach and, yes, practical.

Red, Green, Refactor.

My long talk at EclipseCon 2008, "Creating Enterprise Business Applications Using Eclipse RCP", was originally presented with Scott Delap at EclipseCon 2007 as a tutorial. I'll be pairing down the material into a 1 hour format this time around, which should make it more focused.

"Creating Enterprise Business Applications Using Eclipse RCP" is a case study extracted from my experiences with a large (multi-million line, multi-year) enterprise Eclipse RCP project. The project goal was to build a CRM/Sales-Force Automation application that would eventually be deployed to as many as 40,000 users. The users had to have both connected and disconnected functionality, which required a local data store. When connected, the users needed the ability to sync up with the mother ship, or home office, of the client company. Finally, the business application was a shrink-wrapped flagship product for the client company and it needed to be branded, have a friendly installer, allow updating over the Net, and look good!

Fortunately, Eclipse RCP turned out to be a great platform for developing this rich client business application both because it allowed powerful UI paradigms but also because it was highly responsive when users engaged in extended periods of data entry. The downsides? Well, let's just say that there were some interesting ones. Come to the presentation in March to get all the details.

EclipseWorld Expert Panel

 

The opening night of the conference saw an expert panel assembled with Michael Milinkovich, Bob Martin, and David Intersimone. These three guys seem to have such different technology backgrounds and current pursuits that the resulting discussion turned out to be quite dynamic. Here is a sampling of comments from each. (Any mistakes are my own.)

Bob: Those doing Java now will be doing Ruby in 5 years. Mark my words, this train has left the station.
David: Eclipse is an enabler. Eclipse is primarily by vendors for vendors.
Mike: Over time there will be a convergence between Web applications and desktop applications.
Bob: JavaScript is an interesting language based on Scheme. It will have a bigger role to play than just as a silly Web 2.0 scripting language.
Bob: Visual Studio has done a tremendous job of ignoring what developers really need.
Mike: Visual Studio does a good job of pursuing a singularity of vision. But they are sitting on a 10 year code base that is past the "best before" date.

Destination: EclipseWorld 2007

Andy Maleh and I are on our way to present at EclipseWorld 2007 in Reston, VA. We arrived at Midway Airport in record time so we had about 1 1/2 hours to hang out at the food court. Andy had Chinese from King Wah and  I, unfortuately, had a Gyros sandwich.