Kevin P. Taylor

Software Craftsmanship Spikes

Over the past year, we've had many people drop by the Obtiva software studio for short volunteer stints of codesmithing and geekfesting with us. The visits lasted for a few hours or a few days.

Some of the notable visitors (in no meaningful order):  J.B. Rainsberger, Amanda Laucher, Uncle Bob Martin, Corey Haines, Paul Pagel, Jim Suchy, Obie Fernandez, Jeff Patton, and Brian Marick. Thank you, all!

But, we also get a second type of visitor. These are folks who are not necessarily well known. They are apprentices and journeymen who are eager to come pair with passionate fellow craftsmen and share their knowledge with us. And hopefully after a few hours or days, they leave with new tools, techniques, and experiences to power their careers forward.

We've taken to calling this second type of visit a Software Craftsmanship Spike. Just as we do code spikes to gather more information before proceeding with a course of action, visiting craftsmen come here to gather more information about themselves and their careers. Information about technologies, about agile practices, about apprenticeship, about what it is like to work in a craftsmanship environment, or about what they want to do next in their career. 

For example, pair programming might sound cool but if you haven't done it full time for days or weeks, how do you really know you want to take that new gig where you'll be pairing full time?

Or, maybe you've been doing TDD for a year or two. But, you have lingering doubts about whether you are really enjoying the full benefits from it and you want to see how it is done by other practitioners.

In fact, we just had a Software Craftsmanship Spike take place last week.

Interested in participating in a Spike? Contact me. Or, leave a comment below and share your ideas on how this concept can be evolved to become more useful to the participants and more widespread in the craftsmanship community.

"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?

(equal? (+ vim screen) '(lisp programming environment))

For the past few months, I've been involved in an SICP study group that uses Scheme as the programming language of choice. As most programmers know, Emacs is the de facto standard tool for Lispers. But, Vim + *nix shell is my preferred toolset: at least until I am convinced that another, more specialized tool is warranted. I don't dislike Emacs (that much). Since the SICP material is challenging enough, I decided not to complicate things by fiddling with Emacs.

So, instead, I was able to fiddle with Vim and cobble together a reasonable Lisp programming environment using Vim, screen, and the Scheme interpreter of choice for the SICP book, MIT/GNU Scheme.

To get this to work, I assume you are working on some *nix operating system, such as Mac OS X or Linux.

1. Install MIT/GNU Scheme
2. Install GNU screen
3. Install the Screen (vim + gnu screen) Vim plug-in
4. Add the following configuration lines to your .vimrc file (located in your home directory):

   "For screen.vim send block
   "to SendScreen function
   "(eg Scheme interpreter)
   vmap <C-c><C-c> :ScreenSend<CR>
   nmap <C-c><C-c> vip<C-c><C-c>
   

   These two lines map the CONTROL+c CONTROL+c (double Control-c) key sequence to the Vim command "vip" and then send the result of "vip" to the ScreenSend function (provided by the Screen plug-in). The net effect is that double Control-c will highlight whatever block of code your cursor is in and send that block to whatever process ScreenSend is mapped to. In our case, that will be the Scheme interpreter.
5. Now, we are ready to open a console window, fire up Vim, and write some Scheme code. After opening Vim, execute the ScreenShell command:

   :ScreenShell scheme
   

   This command will launch a screen instance, attach the currently running Vim process to the upper screen window, and then launch a new Scheme process and attach it to the lower screen window. This gives you a nice two window setup with your editor above and your interpreter below. Now you should see something like the following:
6. Let's go ahead and type some Scheme code in the top window, the Vim buffer:

   (+ 1 1)

   With your cursor somewhere on or between the opening and closing parentheses, type the double Control-c key sequence. You should see the code highlighted and then interpreted in the bottom window:
   

Tada! You now have a simple Lisp REPL programming environment.

There are lots of enhancements you'll want to make to this basic set-up if you plan to do any significant Lisp coding. For instance, you'll want to add plug-ins for syntax highlighting and parenthesis matching. But, this is a good start for exploring Lisp in your favorite editor.

Let me know other ways you've set up Vim to work with Lisp.

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?

Hackerpreneur's Schedule

The maker's schedule is for those who create. Whether it is programs, prose, or polynomials, makers need uninterrupted time to imagine, build, and deliver.

The manager's schedule, on the other hand, is for those who lead, facilitate, and measure. Their most valuable tool is the meeting. Whether via status meetings, sales meetings, planning meetings, or board meetings, managers must hold meetings to be effective. In his essay, Maker's Schedule, Manager's Schedule, Paul Graham describes these two conflicting schedule paradigms.

Graham points out that meetings are rarely for the maker's benefit. Meetings are organized by managers for the benefit of managers. According to Graham, they are often outright disruptive to makers. A seemingly harmless half-hour meeting scheduled in the middle of the afternoon can derail a maker for hours.

In his essay, Graham describes himself as being on the maker's schedule. But based on his description, it is more likely he is on the hackerpreneur's schedule. Hackerpreneurs, like Graham, intersperse making with managing, managing with making. The hackerpreneur has a company to build and software to build. The two schedules compete for the hackerpreneur's time.

The hackerpreneur's schedule is for the person who refactors code in the morning and grabs coffee with clients in the afternoon; who takes pleasure in designing class hierarchies and organizational hierarchies; who calls Object.new one moment and calls prospects the next.

Understanding and managing these competing scheduling needs has been a challenge for me, also, since founding Obtiva in 2005. During our first eighteen months, I coded on projects 40-45 hours a week. I was on the maker's schedule. Then, we began to bring in new and more challenging clients‚ and the people and complexity required to service them. My manager's responsibilities began to outweigh my maker's.

For the next two years, I did little coding. The only pitiable device I thought up was to black out a few days or weeks a year to devote uninterrupted time to coding. But, as you can imagine that was a bit disruptive to Obtiva. The business demanded that someone manage it.

Graham doesn't offer suggestions on how to manage the hackerpreneur's schedule, saying only, "Those of us on the maker's schedule are willing to compromise." (Remember, he is not yet aware that he is on the hackerpreneur's schedule.)

This year, the solution to this common scheduling dilemma revealed itself to me very simply. This year I took on a new project, Eventwax.com, that has yanked me back into the world of making. EventWax is an online event registration application and also a bootstrapped start-up.

Our coding practices at Obtiva (and Eventwax) include pair-programming. In order to ensure I have time available to code with my developer pairs, who tend not to be available at midnight, I schedule blocks of coding time throughout the week and label them "EventWax Pairing" in Google calendar. These are best scheduled in half-day increments. Some days consist of two back-to-back half-day coding blocks, but most often I can only pull myself away from my manager's duties for a half-day of coding at a time. But, just as I don't let myself get pulled out of a scheduled client meeting, I don't let myself get pulled out of scheduled coding time.

Though the amount of time the hackerpreneur devotes to making vs. managing will evolve—or swing wildly—over time, the solution is clear. Schedule time for making. Block it out in your calendar. Set its priority as high as any of your other commitments.

Why Build Custom Software?

In Code rant: Why is 'Buy' not always better than 'Build', Mike Hadlow opens his blog post by stating that "Building software is hard." He goes on to describe how this fact eventually leads most organizations to ponder the universal question: Should we buy or build our next software system?

As Hadlow explains, commercial off-the-shelf (COTS) software is often a great choice for common business needs, such as word processing. I would go a bit further and say that COTS software is a viable choice for any business need that isn't, and shouldn't be, a competitive advantage for your organization.

What does that mean? Well, if your accounting system is unique to your organization, watch out. Worst case, your system may not follow GAAP accounting principles. More likely, it is simply not very effective software and doesn't follow industry best practices. This will be true for many business functions, such as call-center management, document management, and email marketing. Chances are slim that there are any ways your company can gain a competitive advantage by building its own software for any of these common business needs.

But, what if the software system in question provides functionality that you consider a competitive advantage? For instance, if you run a large head-hunting firm should you use a COTS system for finding, tracking, and managing your candidates and clients? If you are large and successful, the way your staff finds, tracks, and manages candidates and clients should be a competitive advantage. Why would you give up that advantage by moving to a COTS system that your competitors can also purchase?

If a COTS solution is better than your current solution for a business function that should be one of your competitive advantages, you need to rethink, and possibly re-engineer, how your company performs that function. For instance, a large e-commerce organization should have plenty of competitive advantages built into its warehousing, customer-service, on-line shopping, and vendor management systems. If not, they may be in trouble.

Buying versus building makes sense in many cases. But, without even considering the hidden costs of customizing and integrating COTS systems (which Hadlow covers nicely), it is often the case that building a custom software solution is the only choice that makes strategic business sense.

Definition of Hackerpreneur

Hackerpreneur

-noun

a leader who combines the skills and passions of a software hacker or craftsman, with the drive and passion of an entrepreneur, to successfully create and market new software products or services.

See also:

• Hacker: "a person who enjoys exploring the details of programmable systems and how to stretch their capabilities, as opposed to most users, who prefer to learn only the minimum necessary." —Eric S. Raymond
• Software Craftsman: a software developer who ascribes to the Manifesto for Software Craftsmanship.
• Entrepreneur: a person driven less by making money and more by a need to see her new product or service succeed in the marketplace.

Examples:

• Paul Graham: a programmer, entrepreneur, and writer. Paul is known for being an advocate of the Lisp programming language and for co-founding Viaweb, which eventually was purchased by Yahoo! and became Yahoo! Stores. He is also a co-founder of Y Combinator, which provides seed funding to hi-technology startups.
• Joel Spolsky: a software engineer, entrepreneur, and writer. Joel is the founder of Fog Creek Software.

Build Trust Box Relationships

Remember your last road trip through the countryside? As you drove down that country road, chances are good that you spotted a trust box or two sitting alongside the road.

A trust box is one of those unmanned "for sale" stands you'll see sitting off the road, near a farmhouse. They'll typically consist of a weathered sawhorse or table, a basket of farm-fresh tomatoes or a few cherry pies, a rusty coffee can, and a big, hand-written sign spelling out the terms: "Tomatoes: 50 cents each or 3 for a $1. Put money in can. God bless!"

Image by keeeks

If you buy or sell contract software development services, what can you learn from a trust box? Let's walk through how a trust box works and see what it provides.

In the best case scenario, a customer picks a tomato from the basket and puts money into the can. Everyone is happy. The customer gets a fresh tomato at a low price. The farmer gets to spend more time farming. The cost of the relationship between the farmer and the customer is at its lowest possible level.

Now, what happens when the customer picks a tomato but doesn't put money into the can? If it only happens occasionally, the farmer can simply factor that slippage into his prices and carry on.

However, the trust is diminished and the cost of the relationship increases.

What if we take it to an extreme and imagine that lots of customers regularly don't pay for the tomatoes they take? At the end of each day the farmer has a good chance of having very little or even no money. Now uncertainty exists. The farmer can no longer trust his customers to meet their commitments (to pay for the tomatoes).

Of course the farmer wants to continue selling tomatoes--this is his livelihood. So, he locks down his processes. Yep, he pulls up a lawn chair and mans his tomato stand, dog gone it. He still sells his tomatoes but what are the repercussions? The customer pays more. The farmer farms less.

The trust is gone. The cost of the relationship goes even higher.

So, what can we learn from a trust box? Trust is a lubricant. The more trust, the less friction. The less friction, the more everyone benefits.

In software development, devices such as contracts, upfront deposits, specifications, change orders, CMM Level 5 certifications, and multiple sign-offs are all used to lock down the process and control uncertainty. But, each of these increase the friction in the relationship. It gets pushed further away from being a simple trust box.

Build trust early and work hard to keep it strong. Its value is quantifiable.

Quality, the Four Variables' Stepchild

We've all heard of the four variables (a version of the Iron Triangle) that comprise the inputs of a software project (or any project, for that matter).

1. Time: The calendar time required to complete the project, i.e., the completion date.
2. Resources: The cost of the project in scarce resources, such as salaries, tools, data center space, or bandwidth.
3. Scope: The value to be delivered. In software, this is typically measured in business value via story points, features, or a similar measuring unit.
4. Quality: How well the scope is delivered.

Arguably, the most controversial and difficult to define of the four variables is quality. 

Some people believe quality and scope cannot be separated. They believe that scrimping on quality is just an underhanded way of reducing scope. Others believe that quality is not a variable at all. These folks would argue that the quality of the output of a particular team is a given, not a variable. Others even believe that quality is an absolute. Quality must always be at 100%. But, 100% of what?

I tend to think of quality as the professional practices of the development team. How rigorously do they follow good (XP) development practices? Are they pair programming and testing first? Are they using continuous integration? Are they designing maintainable software using techniques such as the open-closed principle and refactoring?

If defined in this way, quality can be a useful variable. For instance, a team may choose to do without pair programming during an iteration  in order to increase scope. Or, they may choose to delay particular refactorings until a later date (or forever). Or, a startup may have limited financial runway and simply will not takeoff without massively reduced quality. How many successful products, such as Microsoft's Office or Amazon.com would not exist today if they hadn't scrimped on quality early on in order to get to that first revenue producing stage.

Is reducing quality always the right or wrong approach? It usually will be the wrong approach just as would be paying your mortgage on a credit card. Eventually, most reduced quality must be repaid with interest. 

But, by evaluating potential project input decisions within the framework of the four variables, you can make tradeoffs intentionally and increase the chance a challenged project will be considered a success by the stakeholders.