Kevin P. Taylor

Agile 2010 Presentation: Programmer Self-Education

At the Agile 2010 Conference in Florida, I'm happy to be presenting a 30 minute experience report entitled, Programmer Self-Education: My Year Studying Programming Language Fundamentals on Tuesday at 11:30.

Official Session Description

After attending Michael Feathers's talk at SCNA 2009 titled "Self-Education and the Craftsman," Kevin Taylor made a commitment to himself to read the revered, and despised, MIT textbook, "Structure and Interpretation of Computer Programs" (SICP). Over the next year, he spent hours each week working through challenging programming exercises in Lisp. In this talk, Kevin shares some of the programming fundamentals he discovered, or rediscovered. Kevin also shares his insights on the importance of self-education (knowledge + practice) for software craftsmen and their journey toward mastery.

Additional Insights

This session is about programmer self-education first and the material contained within SICP, second. Unfortunately, after considering how much SICP material I should present, it became painfully obvious that I wouldn't be able to do justice to any topics from the book within 30 minutes.

Since many of us aspire to become masters of our craft, I am using this brief session to discuss:

1. How/why I chose to spend my time with SICP, a seemingly impractical book.
2. Brief highlights of material I discovered/rediscovered in the book.
3. My general approach to self-education, which is applicable to any topic worth aspiring to master.

Frankly, this experience report could be expanded into a whole day or semester of material, so be prepared for a whirlwind, if you attend.

EDIT 1/10/2012: Here is a link to the presentation (this one given a few weeks after the agile conference):

http://vimeo.com/14611112

Conversations over RFPs

I had a conversation recently with a friend who also runs a software development company. During the conversation, the topic strayed (as it often does), to how we each find new clients. I was shocked by his response. His relatively successful company finds many of its new clients by responding to RFPs.

For those of you who haven't had to deal with them, RFP stands for Request for Proposal. Companies write RFPs that explain a problem that needs to be solved and then the company invites one or many vendors to respond with proposals describing how the vendor would solve the problem and how much it would cost.

It sounds wonderful for a client company. The company has an opportunity to compare multiple proposals against each other and choose the most appropriate one. And, in fact, RFPs are used successfully in many business situations, such as building out a new data center or replacing a roof.

But, when a company is looking to purchase custom, creative services such as software development, RFPs become an obstacle. We all know that one of the primary determinants of a successful software project is the cooperation between the different members of the team. The product owner, business stakeholder, developers, and designers need to be pulling toward the same goal. There must be trust and collaboration.

How are potential trust and collaboration measured via an RFP process? Well, they aren't, of course. So, a critical aspect of the client-vendor relationship is left eerily unaddressed during the RFP process. The crucial question of, Can we successfully work with these people?, is left unasked and unanswered.

So, instead of responding to RFPs outright, we always attempt to engage the company in a conversation. We do this because, quite frankly, we don't want to take on doomed projects. Only through the series of conversations and brainstorming/planning sessions that happen during the sales process can we get a read on whether we think we can trust and collaborate with the potential client. And, I want them to take that same read on us.

Ultimately, if the company is unwilling to discuss their problem with us outside of the RFP process and iterate with us over possible solutions, we disqualify them from our sales pipeline and move on to prospects who are looking for a relationship based on trust and collaboration instead of a relationship based on commoditization.

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.

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.

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.

The Coin Flip Game

We enjoyed an opportunity to hang out with Jeff Patton in the Obtiva office for a few days recently. He was pairing with Dave on Mad Mimi most of that time. But, we all know that all work and no play makes <fill in name> a dull boy, so being geeks, we took a break to play a new game that Jeff suggested.

The Coin Flip Game (my name) demonstrates the efficiencies gained in a Lean/Agile production environment when compared to waterfall environments. The concepts this game demonstrates are explained by the Theory of Constraints and optimal work queue sizing. The idea is to deliver several coin flipping "projects." The first project is waterfall-style with Requirements, Design, Implementation, Verification, and  Maintenance phases. Running the waterfall project will give us a baseline process cycle time, or the time it takes to send a given batch of work through the process from start to finish.

To run the waterfall project, start by creating stations at a table for each of the 5 waterfall phases. Have one person man each station. Line up 10 coins at the Requirements station, all facing heads up. Start a timer. Each station must flip all 10 coins. Once all the coins are flipped, the coins are pushed to the next station. Each station flips and pushes. Once the last station has received and flipped all the coins, the timer stops. Record the time taken as the process cycle time.

For the Agile project, set up the coins and stations exactly as above. This time, though, each person flips and pushes the coins in units of 5 instead of 10. Again, time the result.

Run another Agile project, but with 2 coins being flipped and pushed at a time, and, finally, with only 1 coin at a time.

The theory is that reducing the size and increasing the frequency of the work unit batches being pushed through the stations should increase the overall efficiency of the entire process. Playing the game demonstrates that process cycle time is directly related to batch size but inversely related to batch frequency. If each station receives smaller and more predictable work batches into their queue, it should be easier to manage, and there should be less time spent on low value activities while waiting for another large batch of work to hit the queue.

We took 26.2 seconds to deliver our coins via waterfall. The last Agile project we delivered had 1 coin iterations and was delivered in only 13.1 seconds.

Evolving the Simplest Tools that Will Work

Our company, Obtiva, is an Agile software development company. But, Agile principles permeate all aspects of Obtiva and go well beyond our software projects. We are an Agile Business. As such, one of the core Agile values that we strive for in our business operations is simplicity.

Simplicity manifests itself in many forms during our daily routines while running business operations. The use of lightweight tools is one obvious example. For instance, we leverage Google Apps extensively for email, collaborative documents, and a shared calendar. In most cases, a new business tool begins life as a Google spreadsheet.

Over time (days or months) those spreadsheets and shared documents become less and less effective. The spreadsheet may have only been conceived of as a business logic prototype. Or, a particularly useful spreadsheet may offer significant business value, and the promise of much greater value, if it only had x (feel free to name x).

At this point, we have a choice: invest time and money in an off-the-shelf tool that we can customize to some extent or build our own one-size-fits-one tool. Using Ruby on Rails and other lightweight technologies, we are surprisingly often able to spend only hours to convert a spreadsheet into a Web-based business application.

Even better, our one-size-fits-one applications start life with only the smallest kernel of high priority features, maximizing ROI. Over time, we can continue to add features, of course, as our business needs evolve. We are not locked into any particular vendor's feature set (not enough, too many, or the wrong mix) nor are we at their mercy for bug fixes or upgrades.

First, view you initial application needs through a minimalist's eyes (What is the simplest thing that will work?). Second, leverage the flexibility and productivity of tools like Google Apps, Ruby and Ruby on Rails to deliver just the right level of functionality vs cost.

Sprint Like a Hippopotamus

I had the opportunity to visit one of our clients this week, which happens to be a Fortune 500 company. As with most Fortune 500 companies, this client's I.T. organization is a behemoth.

Doing a bit of googling, I discovered that the word behemoth comes from an Egyptian word for hippopotamus. As everyone knows, the hippopotamus is an enormous, lumbering animal that enjoys wallowing in mud.

Or is it? Referencing Wikipedia, I discovered that although the hippopotamus is enormous (only elephants are consistently larger) and does spend its time wallowing in mud, it is not necessarily lumbering. Only most of the time.

When aroused or threatened, the hippopotamus will sprint at up to 30 miles per hour for short distances and is one of the most dangerous mammals in the wild.

Like the hippopotamus, I.T. in the Fortune 500 consistently moves slowly and awkwardly, year after year, fumbling through costly projects and delivering dubious returns. Occasionally, however, one of these behemoths will raise its belly out of the mud and get its ire up. Very occasionally even enough to do a 30 mph sprint.

The particular client that I visited is in the middle of its own 30 mph sprint. Disappointed by the internal I.T. teams' ability to deliver value rapidly, they set up a special projects team outside of the confines of the rest of the I.T. organization. The team was given the leeway to deliver projects they way they saw fit. The catch, though, was that they had to deliver. The team leaders chose to use eXtreme Programming (XP) and a lightweight, open source Java technology stack. After 5 months of development, the first application was released to production with great fanfare.

If you work within an I.T. behemoth, do not resign yourself to the lumbering pace that is the norm. Find a way to get the ire up in your organization, spin off an agile team, and sprint like a hippopotamus.