Summary of Martin's Craftsmanship Under Pressure

I've already mentioned some of the notes I took from the Software Craftsmanship of North America (SCNA) Conference, but I also wanted to give a summary of Robert Martin's closing keynote. Martin's talk was a lot of fun, as he really engaged the crowd. I was impressed; he’s a very talented presenter. If you've read some of Martin's stuff then you're probably familiar with many of the things he mentioned, though this time he framed his thoughts around the idea of craftsmanship and professionalism. Overall, it was a good talk.

My notes are as follows:

What is a professional? A professional is someone who is cool under pressure. But why is pressure such a big part of a software developer's job? Because people want stuff from us yet don't care about the other stuff that we care about (like clean, maintainable code). Thus we feel pressure, which is the fear of missing or breaking a commitment. However, commitments are necessary and inevitable; all professionals have to make commitments, and we have to provide estimates for these commitments. Nonetheless, our estimates will most likely be wrong, and work will take longer than anticipated. Then what?

The common reaction when the pressure mounts is to rush, but can you really go any faster or smarter? No, you can't. Rushing means you have to leave something out - some of your free time, part of a feature, etc. But more importantly, rushing means you stopped caring. Thus the definition of rushing is carelessness. Now you could say that you're merely acquiring some short-term "technical debt", but it's really just a mess - and messes slow us down. You'll never go back and clean the code (you'll fix bugs in the code, but not actually clean it) because your estimates are wrong, forcing you to be short on time.

Professionals, however, don't rush - meaning they care about their code. And because they care, they follow some principles of software craftsmanship:

First, do no harm

Do no harm to the code, to the functionality/behavior, or to the product. Our expectation should be that QA finds nothing wrong with our code (though they will). But how do we know that we're not doing harm? Our tests ensure that we're doing no harm, so we should strive to write many tests and get as close to 100% code coverage as possible (though we know that may not be possible). Furthermore, we need to be able to make changes to our software without exorbitant cost. But how do we make our software easy to change? By actually changing it! The very act of changing makes it changeable. You change the code, find out why it was hard to change, and then make it easier to change. Changeable software is software that has been mercilessly refactored.

But despite our efforts to write software that's well-tested and easy to change, we still could harm the software. When are we most likely to cause this harm? When we rush. Yet professionals don't rush, thereby requiring a tradeoff in order to prevent the rushing and its subsequent harm. The tradeoff might be putting in overtime or changing scope, but it's never quality.

Craftsmen have a work ethic

Craftsmen don't just code for fun or for themselves. They will work hard for their employer and deliver value to the customer. So they can't just focus on cleaning code; they must also deliver value. Craftsmen therefore must give forty hours a week to their employers. Things like on-going learning is done on your own time, not your employers – compare it to your expectations of your doctor, where you expect him or her to learn more on his or her own time and money.

So you're giving forty hours a week of hard work to your employer, but what happens to this work ethic when you're under pressure? Since you never compromise quality, another tradeoff must be made. You could put in some overtime (and thus tradeoff your free time) so long as it's not too much overtime - like a week or so. If a project requires more overtime than that, then you should talk to the project stakeholders about trading off something else, such as scope. This discussion can be difficult and awkward, but professionals are willing to have uncomfortable discussions when necessary.

Craftsmen know their field

You need to know principles, patterns, methods and processes, several languages (that are radically different from each other), algorithms, etc., etc, etc. If it's related to software, then you should learn it. And remember, education is your responsibility, not your employer's. Taking responsibility for your career is at the core of the craftsmanship movement.

Craftsmen are continuously learning

Craftsmen never stop learning. They practice software because they love to learn and live to learn. There's all kinds of learning, including: reading (books, blogs, articles, Twitter), going to conferences and user groups (own your own time, not your employer's), and practicing (like actually writing code). Utilize all of these types of learning, and keep pushing yourself. We need to always try to step outside our comfort zone in order to truly learn more and keep improving.

...and this is unfortunately where Martin had to be cut off, as he was already thirty minutes over his allotted time. Nonetheless, he packed a lot into the keynote, and it was not only entertaining but also informative and inspiring. He seemed to capture the key themes and overall spirit of the day, making it a great end to a great conference.

Notes from the Software Craftsmanship North America Conference

(Note: Dang, I thought I already posted this but apparently have not. Oh well, better late than never.)

I attended the Software Craftsmanship North America (SCNA) Conference, had fun, and took a bunch of notes. A summary of my day follows.

Ken Auer delivered the opening keynote, Swimming Upstream, Sprouting Legs, and Running Free, where he described his technical and personal development over his career. He mentioned that modern American culture doesn't allow much overlap between work, learning, family, church, etc. Thus Auer started looking for ways to break the boundaries between the different aspects of his life in order to develop an integrated lifestyle. He then began describing his experience in mentoring an adolescent apprentice but unfortunately ran out of time before he could go into much detail. Nonetheless, Auer's talk was a great start to the day, being both motivating and full of interesting ideas and observations.

I then attended Michael Feathers's Self-Education and the Craftsman. In this talk Feathers opined that he was scared that the stuff he values and considers essential knowledge about our industry isn't as valued by others. He then proceeded to describe some of the concepts that he deems important - things like algorithmic complexity, covariance and contravariance, types, state machines, regular expressions and automata, worse is better (the best solution doesn't always win), and several more. He then mentioned a list of books to read. It was interesting to hear him state the importance of some things that I haven't even thought of since college, as well as mention some things that I haven't heard of. Staying true to the idea of continuous improvement, a theme of the conference, the session definitely gave me a list of topics to brush up on and learn more about.

Afterwards I went to Fred George's Observations From an Old Warhorse, where George described some of his observations of the software industry, drawing upon his decades of experience. Some of his more interesting comments included:

• If is suspicious, and else is almost always wrong - meaning that if you're using a bunch of if/else statements, then you could probably find a better way to write your code.
• Management should focus on feedback cycles and eliminating waste.
• Status reports are a waste; use a visual wall instead.
• Iterations are dead. In his experience, they keep getting smaller and smaller in duration (from Scrum to XP to his work with one week iterations at ThoughtWorks to incorporating iterations into the daily standups) to the point that there's really no reason to plan around and formalize the idea of an iteration.
• His current company doesn't write unit tests. The units of code for their applications are small enough that if something doesn't work, they just throw it away and write something else. Furthermore, the company doesn't have testers. In fact, the team members really don't have rigid roles; they both write code and test - and if they find a bug, they don't log it; they fix it, as logging is a waste.

George's talk was amusing and thought-provoking. You could tell that he has loads of experience, is extremely knowledgeable, and is extremely practical.

The morning ended with Jim Weirich's talk on a Grand Unified Theory of Software Design. There are currently several varying opinions on what we should look for in a good software design, but could we come up with a more objective, unified idea of good design, similar to how physics is seeking a Grand Unified Theory? Weirich believes so and thinks connascence could be the start of such a theory. Two pieces of software share connascence when a change in one forces a corresponding change in the other. Weirich then described and provided examples of several types of connascence. He also mentioned a couple of rules: the rule of locality, which states that as the distance of locality increases, connascence should be weaker; and the rule of degree, which states that higher forms of connascence should be converted to lower forms of connascence. Weirich also mentioned the book that originally discusses connascence - What Every Programmer Should Know About Object Oriented Design by Melir Page-Jones. This topic was new to me, but I find it very interesting and hope to research it some more soon.

The afternoon kicked off with Ward Cunningham's talk, What If Bacteria Designed Computers? The talk was about his hobby wiring tiny computers together to make them work like bacteria/cells. It's doubtful that I'll ever practically apply anything Ward mentioned to my work, but the talk was nonetheless fascinating - plus I'm glad that I got to attend at least one of Ward's talks in my lifetime. And I think the talk fit perfectly into this conference, as Cunningham shows that, despite it being just a hobby, his eagerness to learn more and drive to keep at it lead him to accomplish some impressive stuff. These qualities are definitely needed in a craftsman.

I then attended a discussion on The Business of Craftsmanship, which included panelists Micah Martin, Kevin Taylor, and Carl Erickson, three entrepreneurs whose companies value craftsmanship and have some sort of apprenticeship. The panelists broached a variety of topics, but they talked a lot about their experiences working with apprentices and honing an apprenticeship program. A few of the comments I found interesting:

• Making an apprentice find a master and having the master personally accept the responsibility of teaching them has been effective for the companies, as opposed to having the company accept the responsibility.
• Passion and motivation in an apprentice is essential.
• The panelists' felt that they had a definite competitive edge over companies that didn't practice craftsmanship and apprenticeship.

Then I went to Bobby Norton's session on Test-Driven Learning. Norton mentioned that seeing working code doesn't lead to mastery. Repeated study isn't enough. You need repeated practice, which requires recall coupled with active thinking. This approach leads to greater than 150% long-term retention. Unit testing is a great way to acquire this repeated practice, as you're working with the language or technology hands-on while using it in an engaged manner, as opposed to just copying example code from somewhere. Thus Norton devised an application called the shubox (found on GitHub) that creates a sandbox that you can use to write unit tests that explore a language.

The day concluded with Bob Martin's closing keynote, titled Craftsmanship Under Pressure. Martin's talk was good, and the entire crowd was entertained and engaged. I wrote the most notes during his talk, so I'm going to make a separate post for them.

The only other thing I want to mention is the book Structure and Interpretation of Computer Programs by Harold Abelson, Gerald Jay Sussman, and Julie Sussman. This book was named in multiple talks and was highly recommended, so I'm going to have to pick up a copy.

Overall, SCNA was a good conference - particularly for the price. I was exposed to a bunch of fascinating ideas and had fun. But more importantly, it was invigorating being around other people who share the same values that I do. At the onset of the day, we were asked why we were at the conference, and the answer was because we care about software. I was happy that I could show my support for this movement and am glad to see this attitude becoming more and more popular in our industry.