Which theory fits the evidence? There are two schools of thought about the practice of managing software development (the theory of managing software development is of little use to us because “the gap between theory and practice is narrower in theory than it is in practice”).

One school is that everything is fully deterministic in practice (“Theory D”). If development appears, from the outside, to be probabilistic, it is only because we haven’t discovered the “hidden variables” that fully determine the outcome of software development projects. And, since we are talking about development in practice, it is practical to measure the variables that determine the outcome such that we can predict that outcome in advance.

The other school of thought is that development is fully probabilistic in practice (“Theory P”), that there are no hidden variables that could be used to predict with certainty the outcome of a software development project. Theory P states that the time and effort required to measure all of the variables influencing a software development project precisely enough to predict the outcome with certainty and in advance exceeds the time and effort required develop the software.

Theory P does not mean that software development cannot be managed in such a way that the desired outcome is nearly certain: the flight of an airplane is fully probabilistic as it encounters atmospheric conditions, yet we have a huge industry built around the idea that airplanes arrive at their destinations and land on the runway as planned.

why do theory p and theory d matter?

Understanding whether software development follows the Theory D (fully deterministic) model or the Theory P (probabilistic) model helps us set our expectation for the relationship between what we plan and what transpires.

If we believe Theory D, we believe that it is possible and practical to plan software development entirely in advance. Therefore, when things do not go as planned, our first reaction is to either blame the planners for faulty planning or to blame the implementers for failing to carry out a reasonable plan. Believing in Theory D, we believe that we ought to have a plan that can be carried out to perfection.

Programming is not complicated because computers are complicated—it’s complicated because your requirements are complicated (even if you don’t know it yet).

If we believe Theory P, we believe that it is only possible and practical to plan some part of software development in advance. Therefore, when things do not go as planned, our first reaction is to embrace the new information and update our expectations. Believing in Theory P, we believe we ought to have a process for continually updating a plan that asymptotically approaches a description of reality as the project nears its conclusion.

belief drives behaviour

Our belief about which theory is true drives the way we manage software development projects in almost every way. Here are three examples: the way we manage software design, the way we manage time estimates, and the way we manage selecting people.

If extra time is required, people on Theory D projects work nights or weekends, or they cut testing time. They do this because their belief is that if a task takes too long, the fault lies with the estimate or with the worker carrying out the task, and by working overtime they can “make up for their fault.”

Theory D adherents believe you can design software in advance. They believe it is possible to collect all of the information needed about software’s requirements and the technical elements of its construction, such that you can fully specify how to build it before you start. In short, Theory D adherents believe in Big Design Up Front.

Theory P adherents believe that software can only partially be designed in advance. They believe that requirements suffer from observation, that the act of building software causes the requirements to change. Theory P adherents also believe that technical factors cannot be perfectly understood, that only the act of trying to build something with specific components will reveal all of the gotchas and who-knews associated with a chosen technology strategy. They believe that software design is an iterative process, starting with a best guess that is continually refined with experience.

Theory D adherents believe it is possible to estimate the amount of time required to develop software (in both the large and the small) with precision. This is partly a consequence of their belief that you can know the requirements and design in advance, and therefore you can plan the activities required without uncertainty. Theory D adherents do not plan to miss milestones. Theory D adherents do not, in fact, have a process around re-estimating tasks; instead, they have a mechanism for raising exceptions when something goes wrong.

Theory D adherents believe that the normal case for software projects is that tasks are completed within the time estimated. (If extra time is required, people on Theory D projects work nights or weekends, or they cut testing time. They do this because their belief is that if a task takes too long, the fault lies with the estimate or with the worker carrying out the task, and by working overtime they can “make up for their fault.” Theory D managers often “game” their workers by “negotiating” estimates downward in a cruel game of “guess the estimate I’m think of.”)

Theory P adherents believe that there are lies, damned lies, and software development estimates. This is partly a consequence of their lack of faith that the requirements are truly fixed and that the technology is fully understood. If you don’t know what you’re doing and how you’ll do it with precision, how can you know when it will be done? Theory P adherents build processes around re-estimating estimates, such as burndown charts and time-boxed iterations.

Theory P adherents are always fussing with an updated view of how long things will take. They talk about “velocity” or “effective vs. actual programmer-hours.” Theory P adherents believe that the normal case for software projects is that tasks are rarely completed exactly as estimated, but that as a project progresses, the aggregate variance from estimates falls.

Theory D adherents believe that the most important element of successful software development is planning. If a plan is properly constructed for the design and development of a software project, the actual implementation is virtually guaranteed. Theory D adherents invest most of their human capital in “architects” and “managers,” leaving little for “programmers.” They often have architects, senior developers, and other “valuable resources” involved in the early stages of projects and then moved to the early stage of other projects, leaving the team to implement their “vision.” They likewise believe that you can “parachute” rescuers into a troubled project. Since the plan is perfect, it is easy to jump in and be productive.

Theory D adherents believe in “architecture by proxy,” the belief that using frameworks, components, programming languages, libraries, or other golden bullets makes it possible to employ lesser talents to perform the implementation of software, since the difficult decisions have been made by the creators of the pre-packaged software. Theory D adherents also believe in “success by proxy,” the belief that using methodologies, practices, SDLCs, or other buzzwords makes it possible to employ lesser talents to perform the management of software development, since the difficult project management decisions have been made by the “thought leaders” who coined the buzzwords.

Theory P adherents believe that the most important element of successful software development is learning. They invest their human capital more evenly between implementers and architects, often blurring the lines to create a flatter technical structure and a more egalitarian decision-making environment. This is a consequence of the belief that learning is important: if you invest heavily in a few “smart” people, you have a very small learning surface exposed: there is only so much even very bright people can learn at one time. Whereas when the entire team meets a certain standard for competence, there is a very large learning surface exposed and the team is able to absorb more information.

Theory P adherents believe that there are lies, damned lies, and software development estimates.

They strongly prefer to have the same team work a single project from start to finish, believing that when a member moves on to another project, crucial knowledge moves on with them. They likewise abhor bringing new members onto a team late in a project, believing that the new people will need experience with the project to “get up to speed.”

Theory P adherents use frameworks (especially testing frameworks), but are skeptical of claims that the framework eliminates technical risk or the need for talented contributors. Theory P adherents, even Agilists, are skeptical of methodology claims as well. They do not believe that a deck of slides and a nicely bound book can capture the work required to learn how to develop software for a particular user community in a particular environment.

Theory D and Theory P adherents are easy to distinguish by their behaviour.

so which theory fits the evidence?

Which theory fits the evidence collected in sixty years of software development?

To date, Theory P is the clear winner on the evidence, and it’s not even close. Like any reasonable theory, it explains what we have observed to date and makes predictions that are tested empirically every day.

Theory D, on the other hand, is the overwhelming winner in the marketplace, and again it’s not even close. The vast majority of software development projects are managed according to Theory D, with large, heavyweight investments in design and planning in advance, very little tolerance for deviation from the plan, and a belief that good planning can make up for poor execution by contributors.

Does Theory D reflect reality? From the perspective of effective software development, I do not believe so. However, from the perspective of organizational culture, theory D is reality, and you ignore it at your peril.

Do not confuse Computer Science—the study of the properties of computing machines—with Software Development, the employment of humans to build computing machines. The relationship between Computer Science and Software Development parallels the relationship between Engineering, the hard science of the behaviour of constructions, and Project Management, the employment of humans to construct engineered artefacts.

---

(A portion of this essay originally appeared in What I’ve Learned from Sales, Part II: Wanna Bet?.

Update: D is for “D’oh! We should have gone with P!” and The Myth of Project Management, a SFW retelling of Project Management is Bollocks!.

Labels: agile, popular

  ¶ 11:38 AM

  Still failing, still learning The good news: I’m still learning.
The bad news: …from failure.

This post officially announces that my side project (originally named cause & effect and later named certitude) is over.

What I wanted to achieve

For those of you who weren’t subjected to one of my enthusiastic rants, here was my Graham Question: Can we predict the outcome of a software development project with objective observation?

I have always believed that the answer is Yes. And I manage projects that way. But I also strongly believe that the only way to prove that we have an objective understanding of an algorithm is to mechanize it, to write a piece of software that executes your algorithm.

So I set out to write a piece of software that, pure and simple, would look at a software development project and show you a traffic light: a green light would mean that the project looks like it’s on track, a yellow light would mean that the project needed help, and a red light would mean that there is no hope.

I won’t go into a lot more detail, mostly because this isn’t a story about teeming hordes of customers and me not being able to finish by deadline. It’s a story of inventing a great solution to a problem nobody cares about. But if you absolutely must visualize the application, think of something that gobbles up your MS project files, your bug tracking data, even your burn down spreadsheets, and belches out that traffic light when it’s done. That’s it.

So how and why did I fail?

Project management software is social software

Reason zero, just as Paul Graham warned, my age. Really. I remember how much code I could crank at age 22, and now that I am double the age, I write an order or magnitude less. I’d like to say that my code is that much better that it makes up for the lack of volume. That might be true if I start a project with a specific end in mind, but the act of experimenting, tinkering, and exploring benefits from being able to turn large amounts of code around in short amounts of time.

This is reason zero because I wanted to get it out of the way before explaining why I think I still would have failed if I were 22. But it’s still important to understand, because I might have known that I was going to fail two years ago, instead of today.

Reason one that I failed—and this is the most important reason I failed—is that I was trying to tackle a social problem with technology. This can work—ask any dating site zillionaire—but it is a very high-risk strategy for software. Not just for making money, but for what really matters, adoption.

Project management is a social problem.

Project management is a social problem. It is 99.5% about getting everyone who knows something about the state of the project to share what they know with everyone else. Getting all the relevant information is 99.5% of the problem, analyzing the information is 0.5% of the problem.

Joel likes to brag about how much trouble FogBugz goes to to make it easy to enter bugs, about how certain kinds of reports are not available to discourage punitive social behaviours like punishing developers who generate too many bugs. This is a strong hint that getting good information is all about managing people’s perception of the likelihood of punishment for telling the truth.

Sitting here typing this, I think the company who can do the best job of predicting the outcome of software development projects is Inkling Markets. That’s because their entire business is about finding a way for people to communicate what they really think of something, not just what they think other people want them to say about something. I think Todd Proebsting would agree.

This problem isn’t limited to dysfunctional environments where people cower in fear of saying anything except “Sir, Yes Sir” when told to change the laws of physics.

Lemons, damned lemons, it’s always lemons

Project management suffers from a real lemon problem. I quoted Bruce Schneier at length about this already, so this time I’ll explain things directly:

Most managers, especially those with limited experience shipping software on a predictable schedule, do not know how to correlate what they’re told about the project with the likelihood that the project will succeed.

Some information is valuable, some is junk. The problem is, managers “buy” information. They trade favours like letting you keep your job for information about how well you are doing your job. So there is a market for information just like a market for cars.

They also “sell” information, literally: they have to make a report or a presentation to their superiors, or to stake holders, or to their fellow founders at the YCombinator dinner.

When a manager cannot tell the difference between information that is useful for predicting the outcome of a project and information that is not useful for predicting the outcome of a project, she thinks about the next best thing: the “resale value” of the information with people one step removed from the project, like her own manager. So she values things like pretty PowerPoints about the architecture higher than finished pieces of functionality.

(This is why I have always sweated my heart out to give good presentations. My teams have depended on me being able to take good information and sell it upstream just as if it were CMM Level Five Buzzword-Compliant Junk).

Do managers further removed from a project always value pretty junk more than good, solid information? Not always, but often. And that’s enough for people to be pressured to give the bad information that sells to their manager, while hiding the good information that doesn’t sell. Exactly like the owners of good cars taking their treasures off the market.

Lemon and bay leaf crème brûlée

Why does junk information outsell good information? Nice PowerPoint isn’t a good explanation by itself: there are nice PowerPoints explaining Agile, but managers still prefer waterfall.

Consider a not so big design. Let’s call completing that design good information: we’ve done a good job finding out what’s really important for the project and making a design that emphasizes the way this project is unique, not the technology stack.

Now consider a typical technology design, emphasizing frameworks and technologies. Fully buzzword-compliant.

Which one sells better? The technology stack does. Why? Well, for starters, managers have been exposed to seventeen billion dollars worth of advertising talking about the benefits of technology stacks. Nobody is advertising the specific ways the not so big design helps the project. How could they? Those are specific to the project, that’s the whole point.

And managers are like anyone else, they compare what you are doing to successful projects they have seen in the past. Once again, the not so big design doesn’t have anything in common with other projects, but the technology stack does. (There are lots of failed projects with technology stacks, of course. But who cites those when bugging the team about whether they will use Hibernate as their ORM?)

How did this happen? How did things that have no correlation to the success of a project become more attractive than things that do?

Quite simply, people have an incentive to look successful. So they imitate the outward appearances of successful projects. We have a really simple way of completing successful software projects: we put successful people on them. But we have a broken way of thinking about it: we don’t like to think of the people as being special, we think that what the people do is successful.

And by that logic, we can take anyone, have them do the same things as successful people, and our projects will succeed.

In a manager’s mind, the measure of whether information is good or not is, Does it measure whether people are doing the same things that successful people have done on projects I’ve been told were successful?

This is not the same thing as measuring whether the project is on its way to success at all. This measures the outward appearance of a project. Things that can be measured easily are rarely the most significant things. Behaviours that can be “gamed,” like how many hours a team is working, will be gamed.

And as above, even if a manger knows better, does her manager know better? If not, good information will be difficult to sell and she will be under a lot of pressure to serve Lemon Pie.

Off balance sheet transactions

There’s another important reason that projects have bad information: the best information is off balance sheet. That’s an expression meaning something a businessperson sweeps under the rug. Try Googling Off Balance Sheet Transaction. It’s never pretty.

In essence, project plans and reports never include the most important information about the likelihood of project success. Never. (I mean never in the same sense that Joel Spolsky means “nobody,” as in “fewer than 10,000,000 project plans”).

Let me give you a recent example. I was discussing a project with a certain manager in a client organization, and there was a rather linear series of releases. Her question was, Can’t we shorten the plan by looking at the dependencies and starting some releases in parallel with others?

Of course we could, but in doing so, we increased the project risk. Just as a single developer has a problem keeping multiple tasks in one brain, a team has the same problem: when working on several unrelated pieces of software at the same time, the individual developers may only work on one thing at a time, but the managers and the testers and especially the stake holders who are thinking about functionality and exercising change control are overloaded, so they will make poorer decisions.

And worse, although you might think that there are no dependencies, you only think that at the outset of a project because of assumptions you are making now, before you fully understand what you are getting into. All in all, there’s a reason Agile projects have a practice of working on iterations with single themes, and the reason is to reduce risk.

Does this mean that manager wasn’t making a reasonable trade off between risk and time? Maybe she was making a very reasonable choice. But let me ask you this: where on the plan would you see the risk component of the decision? If you were comparing Plan “A,” with the linear releases that finish in August, and Plan “B” with some parallel releases finishing in July, how do you decide which plan is better?

Right, you can’t see anything except the difference in dates, so you choose Plan B. The risk component of the plan is off balance sheet. Enjoy your lemon.

(And it is very hard for a manager’s people to explain, for the twentieth time, that it is a mistake to try to optimize a project by having everybody working at once, because that crystallizes certain architecture decisions too early, and haven’t you read any Eliyau Goldratt, whose novel The Goal explains what’s wrong with optimizing resource engagement when you should be managing project risk? The incentive is for them keep their own counsel and put their résumés up on the web. Such is life.)

A more striking example comes from another project where, for various reasons, there was nearly 100% turnover of the senior staff, and finally an outside firm was brought in to clean it up. Do you think there was a notation on the plan for staff turnover? That has to have a huge risk implication, but the plan where you use the same team from start to finish looks exactly like the plan where new people are brought in for each phase or iteration.

Why is risk off balance sheet? I think it’s because people have a blind spot for risk in projects. After the fact of a project, you can always do a postmortem and say, “if we had done this, and this, and if we didn’t do that, we would have succeeded.” So you blame yourself for poor execution.

There’s a culture of Boolean thinking about projects and plans. They worked or they didn’t. We’ll be done in July or August. Not “With Plan A, we’re 90% August, 8% September” and “With Plan B, we’re 12% July, 56% August, but 23% September and 7% October!”

Decisions that add risk to a project, such as excessive parallelization, or the use of unproved people, or the use of team who have never worked together in the past, or of forcing decisions prematurely, all of these things are not reflected in the plan.

(This is another reason there is pressure downwards on developer competence in many organizations. Consider two managers: the first staffs up quickly by selecting available developers, who may not be particularly good. In fact, they are less good then the existing team average. The second moves more cautiously, only adding to the team when the addition improves the average competency of the team. Do you think the second manager will keep their job long enough to finish a project? No, because the ticking time bomb of hiring certain types of developers is off balance sheet, but being understaffed is out there for everyone to criticize.)

I had this hope that through a kind of collaborative filtering I could have a piece of software notice that linear plans or plans involving hiring too quickly or whatever had less variance than parallel plans, and adjust the traffic light accordingly. Regardless of what people would say, it would shrug its shoulders and remorselessly remark on the actual historical averages.

Nice idea? No, it’s a dud. (Or at least, my execution was a dud!)

Somebody set up us the bomb

The second major reason I bombed is that I couldn’t find any buyers. Quite simply, the people who understand these principles are running successful projects. I know lots of people who agree that there is a problem and agree this would help, but they don’t think they need help.

I couldn’t find anyone holding their head in their hands, saying, “If only I could get the truth about our projects, I could open my budget and shower you with gold.” The people who were aware of the problems with project information were busy using decidedly low tech tools—like hiring good people and having daily meetings and estimating tasks in spreadsheets—to solve their problems.

And the people who could use some help quantifying the consequences of their choices—like managers who insist on calcifying decisions very early in a telephone book design document so that they can demonstrate progress in the form of an architecture—they don’t think there’s anything wrong with their approach.

Why is that? My conjecture is that people want help with things that fit their model of what’s important. Someone who uses skilled practitioners and XP thinks that limiting risk is important: that’s why they use two week iterations and merciless refactoring rather than up-front design.

Someone using a classical BDUF management approach thinks maximizing resource allocation and managing task dependencies is important, that’s why they spend all of their time looking at GANNT and PERT charts. When you try to sell either of them something, they want to know how it will fit the model they have in their head about how to succeed with software development, not why they should consider a new model.

And I’m not sure they’re wrong about what’s important to them, personally.

If one of those BDUF projects fails due to the architecture being a poor fit for what the team discovers is really important about the projects, or from poor decisions being made in haste at the beginning of the project, well… managers will say that the problem was with the people making poor decisions. Such managers are not shopping for tools to help them understand the trade-offs, because they do not believe they are making trade-offs.

Something I learned from selling Macintoshes back in the day is this: only make one sale. Convincing someone they have a problem is one sale. Convincing them you have the solution is another. And convincing them that today is the day to act is a third. If you have to do all three at the same time, you are doomed.

This is why experienced companies distinguish sales from marketing. The first two steps are marketing, the third is selling. When you are a new company, you don’t have the resources to market and sell. You have to work with an established pain point (eliminating the first hurdle), then use PR and limited marketing funds to get the word out that you have solved the problem (the second hurdle). You only have time and energy for the third sale, separating customers from their money.

But trying to convince managers that they’re doing it wrong (tactfully), then convince them that they want your product rather than some big rigid waterfall thing or three by five cards and XP, and then convince them that they should write a cheque today…

Bad idea. I should know, I discovered that I was trying to do exactly that.

Now you understand why I have used so much of this post to rant about the state of project management in software development. When you understand what most companies are doing and why, you understand what will sell, and why. And when I understood that the things my project were measuring and reporting were of little interest to the people who were my market, well...

The not so big business plan

I think there are lots of things that will sell, that do sell into this market. When you understand that this is a social problem, when you understand that most information is bad and that the incentives are to value bad information, and for managers to value activities that produce bad information over activities that produce good information, you can make something people will buy.

Like books, lectures, methodologies, and video training. If people have a social problem, a social solution is a natural fit.

There were interesting possibilities like selling this to BigCo for “process improvement.” But whenever I thought about such ideas, I noticed that the software wasn’t in there. I could have written a book and lectured on these ideas. I could have done a “search and replace” of agile for certitude.

A good business plan is one that is really specifically about you and your software. If your plan could be executed by someone else, or with a different project, it simply isn’t the right plan. And all variations of turning this into ConsultingWare were excellent ways of monetizing Reg Braithwaite the brand, but not ways of spreading the adoption of certitude, the product.

And so… and so I looked the sunken cost fallacy straight in they eye and said, no more. As much as I hate to lose, I have folded my project and I am sharing with you the important lessons I learned.

Lessons learned

Well, the good one is this: Paul Graham is right. If you phrase your venture as a question, you will walk away with something very valuable. I now know a lot more about project management and the culture of software development than I did when I started the project, and I wasn’t exactly a Spring Chicken. And set out to learn about Bayesian Networks and Supervised Classification, but I ended up learning about Unsupervised Clustering and Collaborative Filtering.

What a journey.

And there is the one I ignored for far too long: Always Be Selling. I can thank friends like Leila Boujnane, Sutha Kamal, and Erich Finkelstein for reminding me about this, incessantly. Asking people to “buy” your idea forces you to make something people want. That being said, I think there’s a right amount of “push.” You can’t invent by polling the market. Quickly now, jump in your time machine and go back to 1981 or so. How many people wanted a mouse for their computer? But yet… Always be selling!

(There’s a bunch of other stuff that is far more personal, and maybe some of it will appear one day in public, but I wanted to keep this post to essay length, so it’s almost entirely about products and markets.)

So, here I am. Older, wiser, and ready for life’s next adventure. It might be more consulting for BigCo. It might be joining a start up and helping someone else’s dream flower. I don’t know, but if you have an idea...

My brain is open.

Labels: agile, passion, popular

  ¶ 6:49 PM

  Business programming standards have become higher in 2007. Learn to love it. From time to time people suggest that fundamental computer science familiarity is irrelevant to the work of a business programmer. I am talking about a knowledge of recursion, operations on data structures, code generation, and other topics that are often derided as being “unnecessary” in a business programming context.

Hmmm.

I think this is wrong in 2007. It may not have been wrong in 2002, perhaps such knowledge was a bonus but not a basic requirement. But today, I think you need to have it. And I don’t mean, you need to have it on your resumé. I mean, you will use it on your job from time to time.

Now, I know that some readers are shaking their heads, no. And some are nodding their heads, yes. It’s easy to think this is all about culture, and some kind of weird hacker fraternity, or whatever. It’s especially easy to dismiss stuff you never use: if you never needed it before, why would you need it now?

That’s the Blub talking. Your toolbox is good enough because you've never needed anything else to do a job... up to now.

No matter what you think of Lisp, Google-style interviews (do you remember when they were “Microsoft-style interviews”?), or optimizing code, please put that aside and try to read this post as objectively as possible. I’ll lay out my thinking for you.

When you say “these things are not relevant for the job,” how do you know? Ok, you have twenty years of experience. And you’ve never used recursion or you’ve only used it once or twice. So you won’t need it now, you’ll find a way to use iteration. And who cares what a suffix array is, you’ll look it up in wikipedia if you need to implement one.

That’s what people have done for quite a while: wire existing frameworks together. What programmers need to know is how to Google stuff, and what a programmer need on her desktop is an IDE that auto-completes stuff so she’ll know what the methods are called. And of course, static typing to make sure she gets the method parameters right. Good to go.

There are jobs out there like that. Last year’s jobs.

Well, there are jobs out there like that. Last year’s jobs. But how do you know the one I’m filling in 2007 is one of those? Because I told you that for this position we are working with one of the world’s largest financial institutions on a public-facing J2EE application that has been in service for more than five years?

Now, I agree that you have figured out 98% of what we do. Most of the time, we mess with XSLT, message queues, JDBC through a DAL, and other buzzword compliant tasks. The keys to success for those items is less about programming brilliance than around discipline, process, requirements management, and the other stuff the “no hard CS” folks want to talk about in the interview.

And of course, we care about skills in those areas. We have to, we can’t hire someone who can distribute data sets across a grid but is unable to negotiate requirements effectively with a business analyst. But let’s talk about the other 2%.

The top two percent

From time to time we get some challenges. Here are some recent examples:

As part of a refactoring effort last year, we wrote some Java that used Reflection and Dynamic Proxies to replace an entire layer of the application that used to include extensive hand-coding of stuff that was repetitive and error-prone. This saves us 80-90% of the code in that layer when we add new stuff to the application. A testing utility the year before used Reflection to automatically write a certain JUnit suite.

You know how bit-twiddling in Java is irrelevant because you’re waiting for the database any ways? Well, we can’t afford to wait for this particular function, it’s one of those AJAX-y things that happens in real time. We can’t wait to go back to the database.

We’re working on something right now that is highly performant. We have a seven-figure user base, and peak loads are intense. You know how bit-twiddling in Java is irrelevant because you’re waiting for the database any ways? Well, we can’t afford to wait for this particular function, it’s one of those AJAX-y things that happens in real time. We can’t wait to go back to the database. So we have to load something into memory on the server, build a compact data structure, and traverse it quickly. And oh yes, we can’t have a lot of layers of crap, we need to get a response back to the browser with every key press.

For another client, we had to build a task dispatching system. It was like building a piece of a very lightweight fault-tolerant operating system. That operated across data centres in three different cities, moving jobs around from centre to centre. If you were in an interview and someone posed one of those hypothetical “how would you design a …” problems, would you think they stole the problem from some Amazon programmer’s weblog? Would you think “you don’t need that for business programming?” Well, we built that. For an ordinary, brick and mortar business that makes physical stuff.

That 2% figure? That was in 2006. In 2007, it will be way more. Standards are rising. We’re doing more and more work that steps outside of the usual CRUD development.

Here’s the big reason why. Have you read people grousing about interviews where they’re asked about how to implement a search? And about what a waste it is because 99% of the time the database does it, and the rest of the time they stick it in a hash table? Well, in 2007 search matters. The database is a big part of that, but it’s not as easy as SELECT foo.* FROM bar WHERE ... any more.

The Google Effect

Google has become the “start page of the internet.” As a result, everyone now thinks that the way to find stuff is to do a full text search. Everyone thinks that relevant results should be first. And I mean everyone, not just your “early adopter” users, you now have Joe Average calling your customer support hotline and complaining that the search page on your application—the one with a different field for each column in each table—is too hard and why can’t he just type something and get an answer?

This stuff isn’t rocket science. And you don’t need Common Lisp or Haskell to pull it off. You can do it in Java or C#.

Just how do you plan to implement full text search? Buy it from Google or Oracle? And do you think you can do the “Google Suggest” thing with the drop down? In real time?

Users now love having a single search box. They don’t want to have one box for searching on product SKU and a drop-down for searching on supplier name. One box. And if you want to make searching for supplier name easy, give them an auto-complete. Users don’t like to be given an application that basically has the implementation protruding into the interface.

They don’t care that you store first name and last name in separate columns, they want to search for “Reg Braithwaite” and find him, even if “Reginald” is what’s stored in the first name column and there are 3,215 Braithwaites in the table. You figure it out, possibly by word stemming, possibly by statistical analysis. Or maybe you’re just doing some untrained bayesian classification to cluster the “Reginald Braithwaite” record with some other things the user is looking at right now so you put that record at the top of the list you returned.

Hmmm, we’re not in Kansas any more. It isn’t all about has_one, has_many, or has_and_belongs_to_many, and you don’t have to be a high-profile start up to care. Jane Average uses stuff like this when she reads her mail and books her vacation. But does her office HR support application work half as well? Why not?

This stuff isn’t rocket science. And you don’t need Common Lisp or Haskell to pull it off. You can do it in Java or C#: we do it and there are thousands of places just like ours where people just like us are doing it every day.

But in 2007, you do need to let go of the idea that all we’re doing with “business programming” is building web applications that are replacing the client-server applications of the eighties and nineties that themselves replaced the green screen terminal applications of the seventies and eighties.

The “leading edge” interface and ideas employed by Google, Amazon, eBay, and Yahoo! are suffusing our culture to become the standard user interface of web applications. And programming the standard user interface is a basic job requirement. Learn to love it.

---

Do you love applications like Google Mail? Would you like to write stuff like this, even if it’s less than 100% of the time? But are you looking for a stable company working on stuff you can explain to your neighbors? Michael Lucas is hiring intermediate and senior developers for positions in Toronto, Canada. To be considered for a position, please send Michael an email with your answer to the following question:

Name three features from public web ‘sites’ like Google, Amazon, and YouTube (you can pick any site or sites you like) that will make the jump to business applications in 2007.

Labels: agile, popular

  ¶ 12:59 PM

  What I've Learned from Sales, Part II: Wanna Bet? In Part I of “What I’ve Learned from Sales,” Don’t Feed the Trolls, we looked at why resistance to a new idea is expressed as a never-ending series of objections. We looked at one powerful way to avoid objections, by identifying a real, urgent problem that needs to be solved. The next installment, Part III, How to use a blunt instrument to sharpen your saw, describes the mind-set that there are opportunities for improvement to be found everywhere.

In this part, we’re going to disregard my advice to avoid objections and talk about one way to respond to many of the objections raised against new ideas.

---

Can we overcome objections?

Right off the top, I want to say that I don’t believe you can “overcome” an objection by frontal assault. And furthermore, you shouldn’t try. You cannot persuade someone to consider an idea by debating them into submission.

My belief is that you must discover and address their true problem. The first reason to do so is that if they do not have a problem your idea can solve, there is no reason for them to “change for change’s sake.” The second reason is that if you are not solving a real, genuine problem for them you will get caught defending an idea against an endless series of objections.

That being said, there are some circumstances where it is important to respond directly to objections. Even if we have carefully qualified someone’s problem and explained how a new idea will solve their problem, a prudent person will analyse the idea carefully, looking for fatal defects that could prevent it from solving their problem.

Another common circumstance is when there are several parties involved in presenting, discussing, and analysing an idea. Although one of the parties may be bringing up irrelevant objections to resist the idea, you may need to persuade another of the parties that these irrelevant objections do not have merit.

For example, you may be suggesting that agile meta-programming will solve a company’s problems to the CEO. You may have carefully qualified the CEO’s priorities. But the company’s IT department will raise objections because your proposals do not address their personal and departmental problems. So you will need to respond to some of their objections as part of a campaign to neutralize their influence.

What is overcoming an objection?

Overcoming an objection is, to borrow a phrase from law, “A sword, not a shield.” When you overcome an objection, you point out that the reason for not considering your new idea is fallacious, or does not apply in this case.

However, overcoming the objection does not actually provide a reason to change: it merely removes a reason not to change. This is why Part I goes on and on about discovering an immediate problem your idea can fix. If you overcome an objection but have not presented a compelling reason to change, nothing will happen.

In other words, if someone says “I like your idea, however...” you should attempt to overcome the objection. If someone says “Your idea stinks because...” you really need to gidentify a problem to solve.

One model for responding to common objections

A gotcha objection is a proposition that your idea is false based on a premise that is true infrequently or only true for some small number of cases.

Let’s assume you are going to respond to an objection, and you have good reason for doing so. Here’s one common form of objection, and a method for responding to the objection. In essence, I am going to share a pattern with you.

First, let’s look at one of the most common kinds of objections. Here are some examples. They all have something in common:

• “Sometimes you are gonna need it, so you’re wasting time if you don’t build it in from the beginning. Therefore, we should build what we know we’ll need.”


• “Some bugs simply can’t be found through automated unit tests, sorry. This is why we have to use a programming language with static typing.”

What these objections all have in common is what I call the “gotcha!” fallacy. The underlying assumption is that if your idea does not work 100% of the time, on 100% of the cases, it is no damn good. And thus I call an objection based on the gotcha fallacy a Gotcha Objection. A gotcha objection is a proposition that your idea is false based on a premise that is true infrequently or only true for some small number of cases.

P is for Pharmaceutical

Think about therapies in medicine. None of them are deterministic! Every pill, every technique, every therapy is described in probabilistic terms: When compared to the control group who drank a glass of red wine daily but did little exercise, 36.7% of those who combined daily exercise with a glass of red wine had an average improvement of 22.1% in their combined evaluation scores for cardiovascular health.

Try this the next time you’re at the doctor’s office: point out to your physician that you have heard that some people who exercise drop dead right after their daily run. Use this as an excuse not to exercise.

Now, software development is not the same thing as medicine, and I am not suggesting you respond to criticism by saying that since some drugs do not work for some patients that your ideas have merit regardless of evidence or suggestions to the contrary. But I will walk you through the reasoning that leads to the same conclusion.

How to respond to gotcha objections

Our pattern for responding to these gotcha objections is to establish that software development is probabilistic in practice. Once we establish this premise, we then turn the debate from whether there are cases where a particular practice does not appear to be optimal to whether the overall results of applying that practice is better than not applying that practice.

That’s it, and if you’re in a hurry you can stop right here: everything else is an elaboration of this idea.

Exempli gratia: the technique in action

Objection: “Sometimes you are gonna need it, so you’re wasting time if you don’t build it in from the beginning. Therefore, we should build what we know we’ll need.”

Response: Well, sometimes you need it, sometimes you don’t. And when you don’t need it, you save the code you would have written as well as all the other design that becomes coupled to the code you end up throwing out. Of course, sometimes you end up throwing out some stub code, but think about the possibility that you will wind up getting more features done, earlier in the cycle where we can get feedback and reduce risk. Why don’t we look at whether, in aggregate, more projects will succeed using YAGNI than will succeed using “Build everything we might need”?

Objection: “Some bugs simply can’t be found through automated unit tests, sorry. This is why we have to use a programming language with static typing.”

Response: Sure enough, some can’t be detected with automated unit tests. But our choice of a dynamic language provides us with many other benefits, most especially in the areas of metaprogramming and code reduction. By writing less code, we may even have fewer bugs overall. Shouldn’t we try to compare similar projects written in a static language against those written in a dynamic language, and see whether the projects in the dynamic language had fewer bugs and whether the projects written in the dynamic language were more likely to be successful?

Now that you have seen the results of applying the technique, we will patiently examine the reasoning in detail.

Theory D and Theory P in Software Development

Theory P states that the time and effort required to measure all of the variables influencing a software development project precisely enough to predict the outcome with certainty and in advance exceeds the time and effort required develop the software.

There are two schools of thought about the practice of managing software development (the theory of managing software development is of little use to us because “the gap between theory and practice is larger in theory than it is in practice”).

One school is that everything is fully deterministic in practice (“Theory D”). If development appears, from the outside, to be probabilistic, it is only because we haven’t discovered the “hidden variables” that fully determine the outcome of software development projects. And, since we are talking about development in practice, it is practical to measure the variables that determine the outcome such that we can predict that outcome in advance.

The other school of thought is that development is fully probabilistic in practice (“Theory P”), that there are no hidden variables that could be used to predict with certainty the outcome of a software development project. Theory P states that the time and effort required to measure all of the variables influencing a software development project precisely enough to predict the outcome with certainty and in advance exceeds the time and effort required develop the software.

Theory P does not mean that software development cannot be managed in such a way that the desired outcome is nearly certain: the flight of an airplane is fully probabilistic as it encounters atmospheric conditions, yet we have a huge industry built around the idea that airplanes arrive at their destinations and land on the runway as planned.

Which theory fits the evidence collected in sixty years of software development? To date, Theory P is the clear winner on the evidence, and it’s not even close. Like any reasonable theory, it explains what we have observed to date and makes predictions that are tested empirically every day.

(Sidebar: do not confuse Computer Science—the study of the properties of computing machines—with Software Development, the employment of humans to build computing machines. The relationship between Computer Science and Software Development parallels the relationship between Engineering, the hard science of the behaviour of constructions, and Project Management, the employment of humans to construct engineered artefacts.)

The first response to the gotcha objection

The race may not always be to the swift nor the victory to the strong, but that’s how you bet
—Damon Runyan

Before we can go anywhere with gotcha objections, there is something you absolutely, positively must do when you respond. And it must be the very first thing you do. You must establish the fact that the premise of the objection is not universal and not predictable, it is probabilistic.

The objection is of the form that “since your idea works out badly some of the time, your whole idea is bad.” You must respond by establishing that some of the time the idea doesn’t appear to work out, and some of the time it does appear to work out. It isn’t universally bad or universally good.

If you are in a face to face discussion, you can solicit agreement from the objecting party. For example:

• “Well, sometimes you need it, sometimes you don’t, sometimes you’re wasting time, sometimes you aren’t. Is that right?”


• “So there are some bugs that can’t be found with automated unit tests and some that can—am I understanding you correctly?”

In a less interactive environment like a running language flame war on Usenet, you can start by simply stating that the premise is not universal.

Having established that the premise is not universal you must then establish that the cases where the premise applies are not easily distinguished from the cases where the premise does not apply. Establish that nobody knows whether the premise will apply or not until after it has happened.

We simply can’t tell in advance whether the bugs that would be caught by a static type system will end up being significant to the outcome of a project. We can’t tell in advance which constructs will end up being a waste of time. And we can’t tell in advance which people will fail when they try to pair program. (The last point is absolutely true if the people involved are not doing the arguing about whether pair programming will work. If the programmers involved do not believe it will work, they may have a point.)

This is the other aspect of establishing that the premise is probabilistic: not only does it only apply some of the time, but we don’t have a good way of knowing in advance when it applies and when it doesn’t.

Okay, we’ve gone through all of this dry pseudo-academic talk of theories and probabilistic development. Time for a vacation to Las Vegas.


How do casinos make money?

The casino’s strategy is so secure, there is just one danger to its profits: if the casino plays very few games for very high stakes relative to their capitalization, they could lose their capital.

Casinos make money by wagering money on the outcome of games with gamblers. (If the gambling industry offends you, I apologize. We could choose to look at how insurance companies make money, it is entirely the same thing.) The games are arranged in such a way they the casino holds a small mathematical edge on each play. Over the long run, with many gamblers playing the games many, many times, the casino inexorably makes money. The casino may lose games here and there, and some gamblers may enjoy temporary winning streaks, but overall, the casino wins more than it loses.

The very briefest exploration of statistics reveals the following facts about the casino’s strategy for making money:

1. The casino must have an edge on each play;


2. The more games played, the more likely that the casino will profit overall;


3. Runs of good luck for some gamblers are offset by runs of bad luck for other gamblers.

In fact, the casino’s strategy is so secure, there is just one danger to its profits (besides the obvious fear of losing their license to print money): if the casino plays very few games for very high stakes relative to their capitalization, they could lose their capital. One celebrated “whale,” Akio Kashiwagi, won more than $19 million in one casino and on another occasion won $6 million in a siangle session playing baccarat for $200,000 a hand.

Therefore, the casino’s prime safeguard is to avoid risking large amounts of capital on games played very few times.

To summarize, the casino’s strategy is to:

1. Arrange a small advantage on each game played;


2. Play a very large amount of games;


3. Ignore good and bad runs, they will offset each other;


4. Do not risk large amounts of capital on games played very few times.

Now that we know the casino’s strategy, let’s consider how they evaluate games. Imagine them sitting around a conference table, and someone suggests, “Let’s create a new game, Alaska Freeze.” What do they use to evaluate whether to add this new game to their casino?

Space in a casino is at a premium. If Alaska Freeze goes in, something else comes out. So there has to be an Incremental Value calculation: do they make more money with Alaska Freeze in and something else out? Or less? This calculation has two simple components: does Alaska Freeze have a larger or smaller mathematical edge than whatever it replaces, and will Alaska Freeze be played more or less often than whatever it replaces?

Ok, let’s return to handling gotcha objections. I’m sure you knew all of this, I was just presenting it in a palatable morsel so you can feed it to someone objecting to your idea.

From casinos back to objections

The process of developing software is just like the business of running a casino.

You are handling an objection and you have established that its premise is neither universal nor predictable, it is probabilistic. Well, if it has an uncertain outcome, it is just like a casino game. And the process of developing software is just like the business of running a casino.

So the question is not whether a new practice ever has a case where it appears to “lose,” for the same reason that evaluating a new game for a casino does not involve worrying about whether gamblers will ever win.

The way to evaluate the idea is to examine it and see whether it fits the casino model:

1. Does it offer a probable advantage each time it is employed?


2. Can it be employed many times?


3. Do streaks of “losses” and “wins” offset each other?


4. Can we avoid risking the entire outcome of the project infrequent events?

And if it does, to identify what idea or practice it replaces to determine whether it is a net win or a net loss overall:

• Does it offer a larger or smaller mathematical edge over the practice it replaces? In other words, does it lose less often?


• Can it be applied more or less often than the idea it replaces? In other words, how much benefit can we obtain from it?

Now, I am not going to say that XP, YAGNI, or dynamically typed programming languages necessarily fit the casino model and are necessarily better than the practices they replace (Classical Project Management, BDUF, and static typing). But what I will say is that there is a huge difference between saying “some of the time, for some of the people, that idea loses” and saying “overall, when applied to an entire project, the project does worse than whatever idea it replaced.”

So to handle a gotcha objection, we establish that it is probabilistic in nature, then we analyse it as we would analyse any other probabilistic practice: we look at the overall effect of the practice on the entire project, comparing it to whatever practice it would replace. And I have some easy-to-remember phrases for doing that.

The second response to the gotcha objection

The next step is rather obvious. You have to state the payoff those times that your idea or practice “wins.” And to be fair, you also have to agree to the cost of your idea or practice when it “loses.”

• “When teams are disciplined about not writing code that won’t be needed in the current iteration, we get more of the features developed earlier, where we can analyse and learn from them. This lowers our technical and requirements risk. Of course, sometimes this means that they have to throw stub or temporary scaffolding code out later, so there is some wasted code.”


• “When projects are written using dynamic languages, they can use techniques like meta-programming to write less code and to concentrate the green code in one place. Of course, we do not have the compiler telling us about certain types of errors.”

Needless to say, if you are in a face to face meeting you should solicit agreement to this second response as well. If you can’t establish that there are any benefits to your suggested practice, you have a great deal more work to do to handle this objection.

The third, and final response to the gotcha objection

The final step is the clincher. Having established that the objection’s premise is probabilistic, and that for those times the idea or practice “wins” there is a positive payoff, it’s time to compare the overall benefit of the idea or practice to whatever it replaces. You want to shift the debate from debating the premise to debating the overall benefit.

And in fact, there are two different forms of the clincher. You can use either, or preferably both:

1. Ask whether you can balance the benefits of using the practice when it wins against the cost of using the practice when it loses, and evaluate the overall benefit in comparison to the benefits and costs of the alternative and see whether you would get more of a benefit over one entire project, or;


2. Ask whether you can compare the success rate of teams using the practice to the success rate of teams using the alternative in aggregate, or;


3. Both.

And here are the example responses again, demonstrating the three forms of clincher:

Objection: “Sometimes you are gonna need it, so you’re wasting time if you don’t build it in from the beginning. Therefore, we should build what we know we’ll need.”

Response: Well, sometimes you need it, sometimes you don’t. And when you don’t need it, you save the code you would have written as well as all the other design that becomes coupled to the code you end up throwing out. Of course, sometimes you end up throwing out some stub code, but think about the possibility that you will wind up getting more features done, earlier in the cycle where we can get feedback and reduce risk. Why don’t we look at whether, in aggregate, more projects will succeed using YAGNI than will succeed using “Build everything we might need”?

Objection: “Some bugs simply can’t be found through automated unit tests, sorry. This is why we have to use a programming language with static typing.”

Response: Sure enough, some can’t be detected with automated unit tests. But our choice of a dynamic language provides us with many other benefits, most especially in the areas of metaprogramming and code reduction. By writing less code, we may even have fewer bugs overall. Shouldn’t we try to compare similar projects written in a static language against those written in a dynamic language, and see whether the projects in the dynamic language had fewer bugs and whether the projects written in the dynamic language were more likely to be successful?

Good luck handling objections. What is your experience: do you have another technique you can recommend?

A Personal Note

As Mike pointed out in the first comment, this post explains how to handle this one type of objection, the gotcha objection, by moving the debate away from the exception case and towards the overall case. But it does not follow up by presenting hard data to justify the example ideas presented.

First, I want to say that even with hard data you will not foster change with numbers: you need to show how your idea addresses an urgent priority. That should have happened before you got to this point. If you have addressed the problem correctly, it really is sufficient to point out the fallacy in the objection and allow your original argument to stand.

Second, there is a dearth of hard data about anything to do with software development. Repeat after me: “the plural of anecdote is not data.” If you have a source of hard data about any practice, be it programming languages, practices, or even interviewing techniques, I would very much like to read and learn from it.

Does this mean that we should never change, that since there’s no proof that new ideas are an improvement over old ones?

If you are happy with your current situation, maybe not. If you are unhappy with your current situation, if you want things to be better, you may want to change something. It’s your call.

Labels: agile, popular

  ¶ 5:16 PM

  What I've Learned From Sales, Part I: Don't Feed the Trolls This is the first part of “What I’ve Learned From Sales.” In this part, “Don’t Feed the Trolls,” I present my explanation for why people act like “trolls,” raising objection after objection to new ideas, and I suggest how to side-step this behaviour and deal directly with their concerns.

(Part II, Wanna Bet?, describes how to handle one very common form of objection. Part III, How to use a blunt instrument to sharpen your saw, describes the mind-set that there are opportunities for improvement to be found everywhere.)

---

“Oh no,” you must be thinking, “another Guy Kawasaki wanna-be trying to tell me how to sell things.” Well, yes to the wanna-be accusation, but no to the proposition that this is a general-purpose article about sales. I am not going to pretend to tell you how to promote your business, turn your product idea into a money-maker, or even how to sell yourself to an employer.

What I am going to share with you is some experience I have had with sales that strongly parallels my experience discussing new ideas with people. (I know, reasoning by analogy is often faulty. But it’s what we humans do, we’re pattern-matching machines.) If you find that people seem unreasonably resistant to good ideas like more powerful programming languages, putting people before process, or valuing working code above documents, you may find this helpful.

Our model here is that the mental process of considering a new idea is the same as the mental process behind buying something. If you are discussing a new idea with someone—even if you aren’t actively trying to “sell” it to them—they are still going through the buying process. And if they have trouble accepting the idea, they will resist, or in sales jargon, they will “raise objections.”

Do you think this is specific to sales? No, when we see new ideas like the Ruby programming language, we encounter objection after objection. Some are ironic: Some Java enthusiast objects to Ruby on performance grounds: perhaps they are too young to remember when the C/C++ folks objected to Java on performance grounds? Or perhaps it will be the IDE support objection, or the Not Invented By Microsoft (a/k/a Not a Corporate Standard) objection, or any of a million others that are not completely unreasonable, but are also usually irrelevant.

What is an objection?

On the face of it, an objection is an expression of a discrepancy between your idea and what someone wants. So if they say “Lisp has too many parentheses,” you might think that they are saying “I would use Lisp if it didn’t have so many parentheses.”

The great secret we can learn from sales is that this is not true. As we will see below, people say what they think other people want them to say. So someone might be thinking “Lisp is too hard for me, all this talk of let and lambda and closures and tail recursion is confusing.” But they are embarrassed to admit this, so they seize on something that sounds more reasonable, like “the syntax is weird.”

We need to understand this, because the absolute worst thing you can do with an objection is answer it directly. If someone is really thinking “Lisp is too hard,” what good does it do to try to persuade them that parentheses are their friends? They don’t really care. Worse, if you trot out the benefits of homiconicity and its applications to macros and introspection and meta-circularity, you’re actually making Lisp sound harder, not easier.

At one time I was a Macintosh salesperson. I used to sell Mac SEs and Mac IIs in “The Dark Times” after Steve Jobs was expelled from Apple by the vile and treacherous Prince John…

Let me give you an example from my own experience in sales. At one time I was a Macintosh salesperson. I used to sell Mac SEs and Mac IIs in “The Dark Times” after Steve Jobs was expelled from Apple by the vile and treacherous Prince John… but I digress. I was a Macintosh salesperson at a time much like this time: nineteen out of twenty computer sales were PCs.

You would think that selling Macintoshes would be a lonely existence. But no, the phone would ring regularly and customers would visit the office on a daily basis, always with the same question, Why should I buy a Macintosh instead of a PC? And at first, I would answer this question. Macintoshes were superior to PCs in every way. (Actually, this was technically very true at that time. Why, you could run as many as six monitors on a Macintosh II! But I am digressing from my digression.)

I learned a funny thing about answering people’s questions. I would answer their questions, and they would argue with me. I would say that you could run multiple monitors on a Macintosh II, making yourself more productive. And they would say “but I don’t need to be that productive, so that doesn’t count.” Or I would say that the mouse and windowing interface is easier to use, you can learn to use more programs. And they would say “but all I need is a word processor and a spreadsheet, so I don’t need to learn new programs.”

(Why would they do that? It was so that if someone asked them, “did you shop around and make an intelligent decision?,” they could reply, “why yes, I shopped around, I checked out Macs and PCs, I did a lot of research, and surprise surprise, I ended up with the exact same thing that my neighbour Bob has, except mine is running at 12Mhz and poor Bob is stuck with 10Mhz.” It may sound to you like they are doing an awful lot of work just to be able to say that one thing with a straight face, but I can tell you that there is this multi-billion dollar automobile industry that works on this principle: people want to be a little better than their neighbour, but not so much better that they are different than their neighbour.)

I can give you many more examples, but the interesting thing is not whether people wanted this stuff or not, but no matter how convincingly I answered their question, they would just ask another one. Their questions had nothing to do with how they were making up their mind.

What people think often bears no relationship to how they behave

I learned very quickly that what people think often bears no relationship to how they behave. People usually say the things that they think other people expect them to say, but they go ahead and do whatever it is they always wanted to do. In the case of buying computers, my observation is that most people want to buy whatever it is that most people are buying. They want to belong, to fit in. So they are going to buy a PC. Or an iPod.

So what was really on their mind was fitting in, even though they argued about the Macintosh’s technical merits.

The lesson I learned is that before we can introduce a new idea to someone, we first need to understand what is really on their mind.

Salespeople call this “uncovering the hidden objection”. They have all these elaborate techniques for figuring out what’s really on a prospect’s mind when they encounter resistance to the sales pitch. I’m not going to suggest we do that. Instead, I’m going to suggest we avoid the objections in the first place by “qualifying.”

The most important principle of effective selling is that qualifying the customer is more important than overcoming objections.

What is “qualifying” and why is it the most important step in the sales process?

Many people say the most important step is “closing,” the art of getting the prospect to hand over the money, the end of the sale. If you judge by the behaviour of people selling time shares, fitness club memberships, and automobiles, this is the only thing salespeople work on: haranguing prospects and ‘overcoming objections’ by arguing.

Experienced and successful salespeople follow a different path. Experienced salespeople believe that the most important step is qualifying, the art of discovering whether a prospect has an actual need for the product, the beginning of the sale. Salespeople who are strong qualifiers spend almost no effort on closing because they are always working with prospects who want to buy.

On the other hand, if you do not discover their real problem, you extol virtues that have no attraction for them and neglect to address any perceived issues in their mind. The principle at work is that if you know what someone really needs, you address their needs from the very beginning. When you arrive at the conclusion, you have already addressed any questions they may have.

This is true for sales. It is also true for new ideas. If someone fears that an idea like learning Lisp (or meta-programming, or designing a program in the technical interview) would be too difficult for them, you will only be successful if you first explain how easily they will learn the new idea, and only then explain how wonderful the idea is.

If someone doesn’t have a headache, you cannot establish the value of an aspirin for them… Don’t focus on how you think your new idea can help them be better. Instead, focus on whether they have an urgent problem that your new idea can fix.

Although there are various models for understanding people’s motivations—such as Maslow’s Hierarchy of Needs, or the Greed-Belonging-Exclusivity-Fear Quartet—for development tools and methodologies my experience is that the simplest model fits best: people are motivated to solve their problems: if you can identify a problem they think they have, you can show them how to solve it.

People without problems are not good prospects for lightweight development methodologies, new development tools, programming languages, or any other “change for the better.” Just the other day I was lunching with Dmitri from Opalis. We were talking about a development tool I am trying to build, and Dmitri was suggesting that it was a “vitamin” and not an “aspirin”.

I was taken aback. Isn’t improving software development important for everyone? Then I remembered my sales training and asked him about how things were going at Opalis. Dmitri admitted that his team was performing well and that he had built a lot of trust with his organization. So he didn’t have a problem. Quite simply, if someone doesn’t have a headache, you cannot establish the value of an aspirin for them.

Now, even Dmitri’s team has room for improvement, so it is not correct to say that there is no value in improved methodologies, tools, languages, or anything else for him. However, such things may not be a priority right now. This is exactly the same case as trying to sell a Macintosh to Bob’s neighbour: I believed that absolutely everyone could have benefited from owning a Macintosh. However, Bob’s neighbour didn’t think he had a usability problem, he thought he had an urgent “keeping up with Bob” problem.

And there’s the key: Don’t focus on how you think your new idea can help them be better. Instead, focus on whether they have an urgent problem that your new idea can fix.

Discovering their priorities shouldn’t difficult. Why don’t we simply ask them? Well, there’s a trick to asking someone about their priorities. Remember, they will tell you what they think other people want to hear, not what they are thinking. Here’s an example concerning agile development:

Agilist: “What’re your priorities for the development team in the next 60-90 days?”

Manager Says: “I have a total commitment to process improvement and faster response to business initiatives,” …but thinks… CMM Level Four—or, God willing, Level Five—will get me a higher profile and a shot at the CIO position. I need some consultants in here to start imposing some bondage and discipline over our development processes.

The trick is to get specific and objective. Never take objections as evidence of their real needs, and never accept vague feel-good values at face value. Top salespeople don’t. Try calling a busy estate agent and saying you’d like to buy a house. I guarantee that the agent will ask you, “when do you need to buy a new house?” And so it is with new ideas:

You cannot position lightweight development, tools, languages, or any other type of change without being able to fit them into the specific and objective problems someone is trying to solve. You need to relentlessly pursue the immediate, urgent priority:

Startup Founder: “I’ve heard that Agile stuff is crap—it only works for star programmers who would be good no matter how you manage them.”

Agilist: “Well, there’re a lot of opinions out there. Tell me, what would you say is the most pressing issue facing your development team right now?”

Startup Founder: “Well, we have hacked together some great stuff, but we need to scale, and to scale without imploding we’ll need some discipline, some real management of the development team. That’s why we need a real methodology.”

Agilist: “I can understand the importance of scaling up. So, have you set some specific objectives for scaling up over the next month or two?”

Startup Founder: “For the next couple of months? Oh, it’s all about recruiting, definitely recruiting. I need another two or three top people to work on a new project that could be worth millions. We’ve identified some good candidates, but it’s very difficult to get them to accept an offer from a start up.”

Agilist: “You know, we really ought to consider whether using Agile might help you recruit—have you considered the possibility that some star candidates might be looking for an environment that is more Agile than the one they are leaving?”

Startup Founder: “Hmmm…”

As you can tell, once you have a specific problem with specific dates attached to when the problem needs to be resolved, you can discuss a specific solution. You’ve side-stepped the useless “objections.” One more time: do not accept vague objectives, get specific objectives with near-term dates attached to them.

If someone really doesn’t have any applicable near-term objective, you will not be able to introduce a new idea to them. So don’t be surprised if they express very little interest. But when you have an immediate, specific objective in hand, you can position the idea as a solution to their problem.

And that works for almost any idea. Say you had a new programming language designed for set-top boxes. But it turns out nobody has a “programming set top boxes” problem. So they raise objections about the speed of your virtual machine, or the fact that programmers cannot manage memory in your language, so they cannot squeeze programs into very small spaces.

Should you keep pounding away at that? Or go looking for an immediate problem people have, like building web applications?

If you side-step their objections—like memory management—and get to the root of their immediate needs, you might be able to introduce a new popular programming language. Good luck!

Part II, Wanna Bet?, describes how to handle one very common form of objection. If you liked this post, you might also like a related post, The false dichotomy of choosing between your values and expediency.

Labels: agile, popular

  ¶ 12:47 AM

  You call this progress?

One of the things most people want to measure is progress towards project completion. But you can’t measure project completion progress unless you have completed features: developed, integrated, and tested features. A completed feature is done enough for someone to use.

I can’t emphasize this point strongly enough. In a mini-presentation on connecting outcomes to project success, I suggested that when measuring progress, evidence of achieving the “ends” is more valuable than evidence of achieving the “means.”

In other words, evidence of completed features, things of use and value, is more useful than evidence that we are “on plan” or “in compliance with the methodology.”

Always.

Labels: agile

  ¶ 11:11 AM

  Repost: How to Manage an Iteration with a Cork Board and a Stack of Three by Five Cards On a recent project, we had very good results managing the work within iterations with a giant cork board. The board was divided into columns.

To begin, stories were written by a program manager. He owned the absolute right to define “done-ness” for a story. The stories were written on three by five cards and placed in the first column, “story”.

Programmers were assigned to work with the program manager to size stories. They would usually, but not always, end up working on the code. But first, they negotiated acceptance tests with the program manager. Both sides had a veto on the test suite (an acceptance test is not exactly the same thing as a unit test: see How to Use Acceptance Tests to Ship Software).

When they agreed on a set of tests, the tests were documented (preferably on the card) and the card moved to the next column, “accept-able”.

The programmers were blocked from coding or estimating until this point. Very important! Now they negotiated estimates. When an estimate was done, the card advanced to “sized”. But no programming started.

Based on estimates for most or all of the stories, the stories were prioritized and some could be dropped or delayed. The stories that would be in the iteration stayed in “sized” but now would have names attached to them. By convention, we placed the assigned stories in the lower half of the board.

Now a date was set for the entire iteration and coding would begin.

When a story was ready for testing, it advanced to the next column, “test-able”. The program manager would validate the story, and it would advance again to “accepted”.

If it didn’t validate (boo) it bounced back to “sized”: we had no column for “work-in-progress” (the assumption was that if a story was sized and assigned to someone, they were thinking and/or coding).

When all the stories were “accepted,” we’d do a big acceptance test again, catching any regressions. Some of the stories would bounce to a “penalty box” in the lower right hand corner of the board. We felt it was important to highlight the shame of something being “accepted” but breaking.

The iteration was done when all of the stories were simultaneously “accepted.”

So the columns were:

1. Story


2. Accept-able


3. Sized:
   
   
   
   • (upper) Not Assigned
   
   
   • (lower) Assigned
   
   


4. Test-able


5. Acceptance:
   
   
   
   • (upper) Accepted
   
   
   • (lower) Penalty Box
   
   

That’s it!

The Benefits

This process was really light weight. That made it possible for us to have more iterations within the project; we worked on one and two week iterations.

The visibility of the cork board was invaluable: everyone knew where we were, every day. This created a sense of urgency right from the start of each iteration: “we have to get all this done for next Friday? let’s get those acceptance tests defined right now!”.

The process was rigid where we needed it to be rigid (acceptance tests before estimates), but flexible where we needed to be flexible (negotiating acceptance tests, locking down the set of stories after estimates)

Putting the entire team into binary, project-wide iterations really lowered our integration grief.

The Fine Print

Other methods were used for choosing themes for iterations and managing the project as a whole. This is just how we worked within an iteration. In fact, by strict definition the cork board didn’t manage the iteration so much as help us understand where we were and help us follow a set process for movement: I call this Administration rather than Management.

“Now a date was set for the entire iteration and coding would begin.”: That’s a lot of hand waving! Deciding what to include and what to drop is a really complex weaving a deep understanding of the project risk factors, a desire to show constant visible progress (“Demo or Die”), negotiation with stakeholders, negotiation with the developers… A very hard problem.

(Many thanks to Eric Torreborre, whose post Writing on the Walls reminded me how important the physical manifestation of a project is to getting the project done.)

Labels: agile

  ¶ 12:12 PM

  Five things customers want to hear from you

When we’re in front of executives, we quickly learned to talk about only five things:

1. How do we increase revenue?


2. How do we reduce expenses?


3. How do we bring in more customers?


4. How do we get more business out of each existing customer?


5. How do we increase shareholder value?

When we work with teams, we teach them to follow the money and look for the pain. Somewhere in your organization, someone is feeling pain because they aren’t getting the answers they want to one of the questions above.

Labels: agile

  ¶ 2:33 PM

  Three questions and three answers about Wasabi and Rotten Fish I have read some questions about my post Wasabi cannot cure rotten fish. Here are the questions and my replies:

Reg, are you really saying "a good team will succeed despite methodological strategy"?

No. I'm saying that a "good" methodology cannot save a bad team. That does not mean that a good team can survive a bad methodology. There are four critical parts of a successful software project, and in my experience you cannot succeed if any of them are missing. People are the first of those, management the last. Methodology is a part of management in my view. In some situations, strong management can impose an informal rather than a formal methodology. But it would be stretching a point to claim that such situations lacked process or had a bad process.

Reg, when you say "the quality of the result is almost entirely driven by the quality of the programmer", are you also saying "the quality of the tool employed is irrelevant to the quality of the result"?

No, although I might have chosen better words for this idea. What I'm saying is that the difference in results between good and bad programmers using the same tool is much, much larger than the difference in results for programmers of equal abilities using good and bad tools. The good tools are wasted on bad programmers, who find ways to write Visual Basic in any language. The bad tools are the source of frustration for good programmers, who waste time and energy "greenspunning" the bad tools into passable tools.

So I am not saying that (good programmer, bad tool) == (good programmer, good tool). I am saying that:

(good programmer, any tool) - (bad programmer, same tool) >
(any programmer, good tool) - (same programmer, bad tool)

So it is to your advantage to combine good programmers with the best tools available to them. It is always possible to cause a project to fail by selecting bad tools. There is still a difference in result between a good programmer with a good tools and a good programmer with a bad tool. Just because it is a much smaller difference than the difference between good and bad programmers doesn't change the fact that there is a difference.

As Paul Graham and Assaf have pointed out, tool selection strongly drives your ability to attract and retain good programmers. So while in theory you may be able to combine good programmers with bad tools, in practice you may have programmers who are experts in buzzword obfuscation and UML refactoring, but they are not competent in actual programming.

Some "bad" tools have such fatal flaws that it is unrealistic to expect even talented teams to overcome the weaknesses in the tool. In that case my expectation is that a good programmer will fail just like a bad programmer, but the good programmer will alert you to the tool's weaknesses much earlier than a bad programmer, perhaps in the exit interview. Good luck with any project where your best people quit because of poor tools, management, or working conditions.

Finally, in some situations management does not restrict themselves to only prescribing a poor tool but compounds the error by proscribing effective use of the poor tool. In plain English, they don't just force their "A" programmers to use a "C" programming language, but they tell them to write software that they think a "C" would be comfortable maintaining.

(Aside: The usual intent is to "make the code easy to read and maintain." But the measure of "easy to read and maintain" is wrongly "would an inexperienced programmer write the code this way." This is not the same thing as "would an inexperienced but motivated programmer be able to study this code, learn from this code, understand this code, and then maintain this code.")

There is a much larger difference between good programmers using good tools and good programmers forced to use bad tools and bad programming practices. There is some debate as to whether my assertion holds for this "worst case scenario" (such organizations often go for broke, treating the Joel Test as a golf score and do things like demand that their programmers wear ties or refrain from using the Internet).

It may be that the formula becomes:

(good programmer, good tool) - (bad programmer, good tool) >
(good programmer, good tool) - (good programmer, bad tool+bad practices) >
(bad programmer, good tool) - (bad programmer, bad tool+bad practices)

Reg, I don't get the connection to the Wasabi DSL!?

The title was actually snarfed from Guy Kawasaki, who wrote this aphorism approximately twenty years ago. It may be traditional Japanese wisdom. Then again, it may not.

Reg, not everyone can hire the top 1%, 5%, 10%, or even 50% of all developers. So isn't your simplistic "hire great developers" suggestion broken?

(Make that four questions and answers)

You know, this kind of question reminds me why I'm prejudiced in favour of working for CEOs that have a background in competitive fields like sales or competitive team sports like Soccer.

In sales, nobody abandons the idea of hiring good salespeople because "not everyone can hire the top salespeople." Imagine being appointed coach of an Ultimate team. Do you abandon the idea of recruiting the most gifted athletes you can find because every team ought to be able to do the same thing and therefore you will have to settle for average players?

No, obviously not. There can only be one top company. There can only be one championship team. To win in a competitive arena, you have to have better people, and better strategy, and you have to out-execute your competitors. Your goal is to be the one company, to be the one team.

Of course your strategy won't work for everyone, it won't work if everybody tries it. By definition, in a competitive (or "zero-sum") game there is no strategy that can help every player win.

That's ok, you are not interested in World Peace, in every company providing nice working conditions and good management for programmers. You are ruthlessly attempting to beat those companies into oblivion. You want them closed, bankrupt. If they have any talented programmers you want to hire those programmers away from them and put them to work building your dream while their former employers mumble platitudes about "methodologies that produce great results from mediocre people".

Consultants can wander around selling utopian visions of methodologies that work for every company and every programmer, no matter how inexperienced or incapable. Language and tool vendors can spend billions convincing everyone that their silver bullet eliminates all of the bugs that cause projects to fail. IDE mavens can tout the code generation and auto-completion bells and whistles that will give every programmer, no matter how mundanely talented, the productivity of a wizard.

These people have a vested interest in maintaining the illusion that software development is a positive sum game where everyone can win, where every project can succeed, where every product will make money.

But if you are working in a start up where you have to compete for talent, compete for funding, and compete for business success, you do not care whether your strategy can work for 100% of the projects in the world. You care whether it works for just one project, yours.

If you are working on an internal project where you compete with the prospect of your work being outsourced, where you compete for funding with other projects, where you compete for executive mind share, you do not care whether your strategy can work for 100% of the projects in the world. You care whether it works for just one project, yours.

Honestly, what matters to me is how I manage my own projects.

post scriptum: Not everyone wants to be the top salesperson, some people play competitive sports for the camaraderie, not to win, and some people go to work for the purpose of collecting nothing more than a pay cheque. If this describes you, you may find a kindred spirit in the "Angry Aussie": In praise of an average career.

Labels: agile

  ¶ 10:25 PM

  Wasabi cannot cure rotten fish There is only one problem with development methodologies. Just one. It affects all methodologies, agile and otherwise: No methodology can 'fix' projects that are staffed with underperforming people. People are more important than process, period.

This is the underlying issue with the language 'wars' as well. No magical combination of JSON, static typing, design patterns, IDE whizzies, and frameworks will somehow help a million monkeys produce any of Shakespeare's works.

If you want to build a ship, don't drum up people to collect wood and don't assign them tasks and work, but rather teach them to long for the endless immensity of the sea.

Steve Yegge has suggested that if 90% of the projects adopting a methodology fail, you have to stop blaming the people. You have to stop saying "you're not doing it right." You have to say there's something wrong with the methodology itself if 90% of the projects fail to use it properly.

Sounds reasonable. But why would this be true for methodologies but not true for programming languages?

99.999% of the software written in almost any language (including Lisp, Python, and Ruby) is buggy. Yet we readily say that the problem is the programmer. We think that some languages are better than others, that some languages help eliminate certain classes of bugs, but we take as a given that good tools are not sufficient unto themselvesfor good results. We know that the quality of the result is almost entirely driven by the quality of the programmer.

I have the uncomfortable feeling that others are making a religion out of it, as if the conceptual problems of programming could be solved by a single trick, by a simple form of coding discipline!

Home Depot might suggest that buying a new table saw will cause beautiful woodwork to appear in your home. Yet just because a duffer with a table saw cannot make built-in closets all by himself, we don't abandon table saws outright. We assume that good woodworking is better with good tools. And if we are blessed with the skill to make a built-in closet with a hand saw, we know that we can also make the closet with a table saw, and we judge the table saw on whether and how it can improve the results we could have obtained with another tool.

This is my criteria for judging a methodology. Can it improve a team that is already fundamentally qualified to write software?

If you want to stop reading here, my statement is that you can only judge a methodology on the basis of the results it delivers for a team that has already proven it can ship software. You judge it on the basis of incremental value. You don't compare its results to the results some other team gets, or to your fantasy of what results the team 'ought' to get.

The mythical marginal

What I've written seems obvious. Yet, billions of dollars are paid every year to people who are selling a different perspective. What is it that causes companies to buy silver bullet after silver bullet? Why do companies lurch from consultant to methodology to programming language like infomercial junkies looking for something that will flatten their tummies without sweaty exercise or unpleasant diets?

I bifurcate teams into those that are fundamentally qualified and those that aren't. And I believe that to fix an unqualified team, you start with the people, not the process or the tools. So what could the rest of the IT industry possibly believe?

I have observed a belief in a marginal team. A team that is somehow straddling the fence between incompetence and competence. They can ship software, but only with help from their process and tools. If 'marginal' is too perjorative a term, you could think of them as having unactualized potential.

In truth, I have worked with several such teams, so I believe they exist. However, I believe that such teams are quite rare, while proponents of silver bullets make a living convincing customers that marginal teams are commonplace.

The primary example I have observed of a marginal team is a team composed of individuals who are not working together well, yet they have achieved success on other teams in prior roles. Something like the Los Angeles Lakers before Phil Jackson arrived. There is a lot of latent championship potential in the individuals, but the team isn't performing.

Shipping software is not an emergant property of competent programming, nor is it a consequence of management technique.

Why does the IT industry believe that perhaps most teams that fail are marginal teams? They have to believe this, otherwise they wouldn't waste time and money trying new silver bullets ("everything should be a stored procedure," "tests are the only documentation that matter").

It always comes back to hiring

My broken-record assertion is that the industry as a whole embraces the above model of a marginal team: latent potential in the individuals. The difference between the industry and I is that I have an objective measure of latent potential: has the individual demonstrated success shipping software in the past.

True happiness comes from the joy of deeds well done, the zest of creating things new.

The industry doesn't apply this test rigorously, if at all. A typical interview with a developer focuses on patterns and archiecture, on talking about past achievements. Developer's don't juggle. Developer's don't design software. And especially, managers don't hire developers with super-strong references from strong employees that have worked with the candidate in the past.

Basically, managers ask developers if they can ship software and then take the candidate's word for it. If you take only one thing from this blog post, take this: shipping software is not an emergant property of competent programming, nor is it a consequence of management technique. Someone can demonstrate the ability to write software but lack the ability to actually ship software.

(Update: nothing in this post should be construed to suggest that people cannot become better developers through study, mentorships, or training. However, training is to hiring as tools are to skill. And they are not mutually exclusive, any more than good programmers and good tools are mutually exclusive.)

I believe that the reason why the IT industry believes that most failing teams are marginal rather than outright incompetent is that they believe that these teams are composed of individuals who can write software and managers who can direct work. All they need are the right tools to write software "better" and better software will emerge. All they need is a methodology to manage software development better and software will ship.

If you have a marginal team, a team composed of individuals with proven ability to ship working software, you might have something there. But if a team isn't even marginal, no methodology will help. And that's why a useful methodology can still fail to help 90% of the teams that try it.

For the same reason that Wasabi makes Sushi divine.

Follow-up: Three questions and three answers about Wasabi and Rotten Fish

Postscript: The difference between Sashimi and Nigiri

If we're judging success or failure of a development methodology, we have to judge the results on whether the development itself was successful. We can't judge whether the software made money, or whether the company's stock soared. Such things can be studied, however those are product management problems, not software development problems.

People have criticised Google, saying that althought it has a track record for shipping products, only one, AdWords, is financially successful. If you want to compare product management methodologies, that's fine, but you aren't talking about software development. You have to compare similar kinds of projects, for example you can't compare an in-house IT project with a known ROI (reduce the time spent entering a new Blort Ticket by 50%, saving $47.32 per week per Fizbang team member) to speculative product development like a new Web 2.0 calendar.

Who else is trying to create new products? Apple? Microsoft? Dan Bricklin? Compare them to Google, and if they are doing a better job of making money with their projects, post a critique of Google's product management on your blog.

-r.b.

Labels: agile, popular

  ¶ 8:13 AM

  Dear Agile Metaprogrammer I read and enjoy your weblog. You are fairly witty and your stories about attending Woodstock-like love-ins are always amusing. And although I have no intention of even trying Ruby on Rails, Lisp, Python, Haskell, Lua, or whatever else you are fawning over at the moment, there are some snippets of interesting technical knowledge to be gleaned from your experiences.



For example, just the other week I realized that with fewer than 500 lines of intricate code and a few pages of boilerplate interfaces (I was going to have to define all those Java types and methods anyway, so it's free, right?), I could use an InvocationHandler to remove some duplication from my code. I would never have thought of that if I hadn't read about how Ruby lets you make delegates with one line of code.

Philip would be proud of me. But let's get to why I'm writing, ok?

Your posts are getting tiresome.

Blah, blah, blah the indexing takes about 20 lines of code and took less than 10 minutes to get working. Blah, blah, blah magic models. Blah, blah, blah rewrite reddit in Lisp in one hundred lines and twenty minutes. Worst of all, blah, blah, blah $800,000 contract. That's real money!

I don't mind fanboys, lusers that brag about these 'metaprogramming' languages but never actually do any work with them.

But how irritating to hear yet another Rubyist, Pythonista, or Lisper brag about getting actual work done in half the time, with half the effort, then taking the rest of the day off to enjoy the Real World.

Some of us are busy doing Enterprise work, you know, and we're man enough to put in seventy hour weeks debugging our XML parsers, Front Controllers, and verbosely typed languages (VTLs). We don't want to hear about your Euro-style three hour lunch breaks and incremental delivery schedules.

We do the heavy lifting and we have the GANTT charts to prove it.

So just cut it out, ok?

p.s. I'm sorry I'm so testy, but I've been up all night trying to talk to our QA team located in Bangalore. It's bad enough that I don't speak any of their five mother tongues, but it looks like their QA plan is based on a different version of the specs than we got in our supposedly locked down briefing package from the consultants that were hired to gather requirements.

p.p.s. And another thing, you Software As A Service gadfly...

Labels: agile, popular

  ¶ 9:46 AM

  Better Testing Presentation Here's a brief presentation I gave for the Toronto chapter of the Software Process Improvement Network ("SPIN").

Download "Better Testing" (584Kb, PowerPoint).

It emphasizes principles rather than giving specific tips, how-tos, or examples. This was written for the cerebral QA or development manager who is seeking some insight into why some things work well and others don't, rather than a prescription for an inexperienced manager looking for specific direction.

I started developing the presentation with a completely different plan for what it would contain and communicate. I really wanted to talk about burn-down charts and talk about various metrics I have personally found to be useful.

I imagined a kind of diagnosis model where the presentation would list specific project problems and talk about what you can empirically measure to confirm the problem. However, as I wrote out explanations for each metric, I noticed a problem.

Every time I'd explain a metric, I found myself writing out various caveats and disclaimers. The trouble is that metrics can be completely misused, causing teams to chase the numbers rather than develop software. So with each metric there are good things you can discover with measurement, but there are also pathological problems you can experience if you focus on the metric to the exclusion of the underlying principle.

After a while, I realized that this problem seemed more interesting to me than the metrics themselves. This is a cliché for programmers. We start developing a to-do list application and end up with an entire web development framework because we find the underlying common problem more interesting than the application.

So, this presentation is really about what makes some tests better than others, rather than specific tests. I'd appreciate any and all feedback, especially suggestions for improvement.

Labels: agile

  ¶ 10:21 AM

  Presentation: Four things I've learned from my failures ...and what Agile could have done to help...

Here's the final version of the presentation I gave on February 15th at the XP/Agile Toronto Users Group: [fourthings.ppt (updated)].

Labels: agile

  ¶ 1:08 AM

  PowerPoint Presentations on Software Development Here are four PowerPoint presentations I've delivered over the last few years. Caveat: I structured these decks as visual aids for extemporaneous talks. In other words, they do not provide a coherent, narrative story on their own.

(In future talks I plan to experiment with different structures. Some presentations, such as business plans, need to function as stand-alone documents because they are intended to be passed around and reviewed long without your presence.)

Scrum: One Person's Perspective: Shortly after obtaining my certification in the Scrum development methodology (I'm now a "Certified Scrum Master"), I gave this outline of Scrum to the Toronto Chapter of the Software Process Improvement Network.

Evidence-based Software Development Practices: How to develop higher quality software in less time with dramatically less risk by emphasizing the role of collecting and analyzing evidence. This is the cornerstone of my approach to delivering software on time and without drama.

Agile Development or Critical Chain? Yes!: An outline of the Critical Chain Project Management (CCPM) approach and how to integrate it with Agile approaches to software development.

Agile Methods in a Product Development Setting: Sharing my personal experience using Agile methods to develop software products, with particular emphasis on the ways in which product development differs from custom/project oriented work.

Labels: agile

  ¶ 9:51 AM

  What I've learned from failure

I have been fired from more jobs than most people have had.

Why does failure matter?

It's a funny thing. After almost twenty years of drawing a paycheque for creating software, people generally want to hire me because they want me to duplicate the successes I've had. The model seems to be "do the things you've done successfully before, and you'll be successful now."

My experience is that this has never worked on its own. Success in software development is at least as much about avoiding failure modes as it is about "best practices." I conjecture it's because software development on a commercial scale is so hard that almost any mistake will sink a project if left uncorrected or even worse, actively encouraged.

We tend to seek easy, single-factor explanations of success. For most important things, though, success actually requires avoiding many separate causes of failure.

With that in mind, I've taken a little time to jot down some thoughts about situations where I've personally failed. I'm not going to tell you about some theoretical anti-pattern, or relate some broken thing I've fixed, I'm going to share things that caused me to leap from the deck of a burning boat to avoid drowning.

If you decide to run with the ball, just count on fumbling and getting the shit knocked out of you, but never forget how much fun it is just to be able to run with the ball

Some of them, in retrospect, would be comical if it wasn't for the human misery, damaged careers, and money wasted on failed projects. Or worse, in my opinion, the opportunity cost of putting good people to work on things that never end up delighting the world. I weep for what might have been.

The four most important causes of failure

Things which matter most must never be at the mercy of things which matter least.

The first thing I've learned from failure is that the four things which matter most are:

1. The quality of the people doing the development
2. The expected value of the product to its stakeholders
3. The fitness of the proposed solution
4. The quality of project management and expectations communication

In my experience, you need all four working to have a successful project. I've personally failed when even one of those four things was bad and not corrected immediately. If two, three, or all four were wrong, my discovery is that I've been unable to avert disaster. (This list obviously doesn't cover all of the factors needed for business success: I'm just talking about getting the software to ship).

Now that I've learned this, I have four new things to evaluate when placed in charge of a new project. And regardless of what I'm told, I'm going to investigate these four things every time, right away, without fail.

I've never seen a project where strength in one area made up for weaknesses in others. I've never personally seen a great technology platform, for example, that magically enabled low-quality developers to produce commercial-quality results.

And don't talk to me about XP being a magic bullet: all of the good XP teams I've seen happened to have quality developers, a valuable objective, decent technology, and yes, good project management.

People

I think the root of your mistake is saying that macros don't scale to larger groups. The real truth is that macros don't scale to stupider groups.

I've been involved with strong teams and weak teams, and the weak teams always failed. Weak teams have individuals whose performance is weak. The strongest indication of a weak team is the realization that if you were to quit and start your own business, you wouldn't try to poach any of your colleagues.

Painful experience has taught me some of the signs that a team doesn't have the chops to perform up to par. The first sign of a weak team is poor hiring practices.

Developing software is a difficult job. It requires a panoply of strengths. Hiring good people is never as simple as interviewing three people with "five years of J2EE" on their résumés and making an offer to the best of the three. Strong teams have almost impossibly high hiring standards. Strong teams will always leave a desk empty rather than settling for less than the best.

Another sign of a weak team is poor development hygiene. There are dozens of development practices that seem trivial to the inexperienced outsider or to the manager focusing on "big wins." Examples of development hygiene include source code versioning, maintenance of an accurate bug or issue database, significant use of automated testing, continuous integration, and specifications that are kept current (whether incredibly detailed or high-level overviews).

One team I audited were not just unwilling, but were actually unable to build a product that was in sustaining development. In other words, the product was in the field, in use by customers, and the team were not able to rebuild it from source. They were issuing all of their bug fixes as patches on their existing binaries. This was not a good sign.

Does this mean that nothing can be done if the team is weak? Not exactly. Some of the time I've had the authority to replace members of the team. I've always had the ability to set an example and suggest practices. But sometimes I've thought that an organization would be unreceptive to calls for change. And for want of courage, projects have been lost.

The bottom line is that when I've failed to recognize weakness in the team and/or failed to take immediate and decisive action to bring the team up to world-class strength, I've failed.

Argue with idiots, and you become an idiot.
If you compete with slaves you become a slave.

I've mentioned that I've failed with weak teams. Would you believe I've compounded this failure by failing with weak stakeholders? Whenever I've had stakeholders who didn't have the horsepower or the will to recognize that a project was in trouble, I've wound up in the E.R. having the brick dust removed from my forehead.

A chicken and a pig decided to open a diner together. The pig asked the chicken what they should call their new restaurant. The chicken suggested "Ham and Eggs." The pig thought about it for a while, then decided she didn't want any part of the venture. "You," she told the chicken, "would only be interested in serving breakfast. I'd be committed."

Getting away from weak teams, another source of failure is the omnipresent threat of "chickens." A chicken is not necessarily a weak individual, but a sign of a weak management structure. A chicken is an individual who has significant authority over your project, but does not make a personal commitment to the success of the project. Significant authority includes the authority to impose constraints on the team.

Even a single chicken can take a project out. Chickens are a special case of "external dependencies." Special, because they are often politically entrenched. I've worked with teams where the pay scale was determined by an edict from H.R. They were literally prevented from hiring top talent, and it wasn't a question of budget: they did not have the freedom to replace three mediocre programmers with two good programmers for the same price.

Another situation involved a team that were continually pestered to include functionality and architecture for "strategic" reasons by a Business Development person. Although senior management made the importance of the strategic functionality clear, they were unwilling to relax tactical requirements like the ship date or the target revenues. They had to constantly manage the "chicken" in order to succeed.

I've managed around chickens here and there, but I've failed to deliver a successful project whenever I've failed to limit the effect of chickens on the management of projects.

Action

Always dive down into a problem and get your hands on the deepest issue behind the problem. All other considerations are to dismissed as "engineering details"; they can be sorted out after the basic problem has been solved.

The next thing I've learned from my failures is something familiar to the test-driven development crowd. It's mandatory to fail early. You need to know you're in trouble right away. That's essential when taking over an existing project or starting something new. You have to find out how you're doing within weeks. Not quarters, not months. The longer you wait, the more inertia the failure will have.

You have to come in, take over, and establish some incredibly short-term goals and be prepared to take action based on the project's performance. I've learned that there's no such thing as too little time between milestones. Looking back at projects where I've failed, many contained some uncertainty or risk that I didn't address immediately.

In one case there was a critical piece of functionality that was so important the entire architecture was designed around it. The CTO and every developer swore it was the greatest thing since sliced bread. I made a back-of-the-envelope risk calculation and scheduled testing of that functionality to begin three months before the project was to be delivered.

A week before the function was to go into test, the technical lead informed me that it didn't work, had never worked, and that no attempt to fix it would work, because there was a major, glaring flaw that had been overlooked. A rewrite would be required.

The stakeholders agreed and appointed a new team to handle the rewrite. Needless to say, the old team's job security suffered a major hit.

Today, older and wiser, I would demand immediate proof of feasibility of all critical pieces of the product, no matter how obvious things may be to everyone else. I should have said "Great! It's a slam dunk! Wonderful, let's schedule a demo next week." At least we would have felt the pain early.

Details

Whenever I've allowed the details of a project to escape me, I've failed. On one project, the technical lead was a Ph.D. and refused to describe his work, saying that although I was the managing product development, he wasn't going to try to explain his rarified code or architecture to a layperson.

No, I'm not presponsible for what happened. I'm accountable for how we dealt with it, but I'm not responsible for it.

Needless to say, I was unable to ship a successful project. On another project the CEO would ask me the same question every few days: "draw on my whiteboard who's working on what." I had no trouble with this on that particular project, but looking back there have been projects where I was not tracking people's work on a day to day basis.

And I can tell you, whenever the details of a project have slipped from my grasp, the project has started to drift into trouble. I make no apologies for now insisting on knowing exactly who, what, where, when, and why. There's a big difference between being asked to explain your work in detail and being told how to do your job.

My personal experience is that attention to detail has always accompanied successful projects.; losing track of the details has always accompanied failing projects.

The Schedule

In most companies if a good quality project ships late then the managers will still get it in the neck whereas if poor quality project ships on time then the managers say "we did our best - obviously the dev team seem to be of a poor standard".

Dates are sacred. I've learned this lesson in good times and bad. Stakeholders treasure good dates. Stakeholders despise bad dates and the people who make flawed promises. That would have been me, more than once.

Every time, the lesson has been clear. Don't get the dates wrong. I'll confess: I don't really think Scrum is an order of magnitude more effective than anything else at producing beautiful, world-changing software. It may be worse. But it does produce software every month, month after month.

And every time I've delivered software on schedule milestone after milestone, my influence and standing with stakeholders has grown. And every time I've missed a date, I've suffered, regardless of whether the late software was demonstrably better than what was originally planned for the missed date.

If documents don't serve to avoid stupid things, mitigate risks or calculate budgets then what are they for? They're to show you have a "process" and a "paper trail" so that you can get ISO certified. That's all they look for, they don't care if you read them or not.

Back to the measurable processes. I've learned from failure that stakeholders like to know what's going on. I hate producing useless documentation. The net result is that I've tried to find the happy medium where I generate weekly management reports on projects.

A management report is something that is used to actually make a decision. Everything else is garbage. I've learned that when I haven't had management reports for a project, failure has resulted. Worse, sometimes I've had documents and metrics that were used to justify bad decisions that sank the ship.

So my lesson from these failures is that every project needs a set of regular reports that contain information you'll actually use to make decisions.

Software

Few projects are cancelled because their designs and implementation weren't complicated enough. Many are cancelled because they become so complicated that no one can understand them anymore; any attempt to change or extend the system results in so many unintended side effects that continuing to extend the system becomes practically impossible.

One of the reasons people associate me with "Agile" development approaches is that I'm always trying to simplify, simplify, simplify. This is because almost every time I added something to a milestone, I've gotten burned. It seems like it's always better to say "just finish what we planned, get that 100% functional, and then we'll add foobars."

I recently got burned twice in the same project adding functionality in between milestones. Both times I was sure that the changes were low risk. Both times I burned myself. Now I'm licking my wounds and swearing I'll never, ever break my agile principles of restricting scope changes to between increments.

It's important to remember that when you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time. First of all, you probably don't even have the same programming team that worked on version one, so you don't actually have "more experience". You're just going to make most of the old mistakes again, and introduce some new problems that weren't in the original version.

Here's something that I've screwed up repeatedly. Sometimes I've bounced back, sometimes the project has paid the ultimate price. The grand "this time we'll get it right" mantra is absolute garbage.

It had taken 3 years of tuning to get code that could read the 60 different types of FTP servers, those 5000 lines of code may have looked ugly, but at least they worked.

Don't talk to me about porting to Java, or new design patterns. If you must refactor, refactor here, and there, and there to solve this, and that, and the other specific problem that has a specific feature or bug attached to it. And show me that you had 100% unit testing coverage on the affected code and completed each refactoring in a day or so and then ran all the unit tests and got a green light.

If you can't do that, you're going to fail. I know it, because I've failed when I didn't do that. And when I cried on a friend's shoulder, he told me "I also made that mistake once, and I suffered the same horrible fate."

Thinking that a major rewrite is going to solve all of your problems is just revisiting my four things that matter most and planning on having one, the fitness of the proposed solution, overpower defects in the people, expected value, and process. It won't happen.

A major rewrite should produce a major new product that offers an order of magnitude more expected value. And you'll need to be 100% sure your team has the horsepower to get the job done and is going to use a process that can handle the load. I say this because I've tried and failed to rewrite entire applications, and I've taken over other people's rewrite projects and failed there too.

Power

Some days you are the bug, some days you are the windshield.

I've learned a little about politics from failing. What I've learned is that if you stick your neck out and evangelize change, you will be blamed if you do not achieve results. You may or may not care about that. But be aware of the fact that making changes involves spending your personal credibility. If you don't want to lose it, don't ante up: get out of the project.

Don't have good ideas if you aren't willing to be responsible for them.

And if you decide to make changes, have the courage to go 100% with your gut. I've failed more than once when I watered down my convictions in order to appease dissenters. The only thing worse than evangelizing change and failing is looking back and realized you might have succeeded if you'd held firm on your convictions. What a waste!

Making an employee work and profiting from that work are two different things.

I've seen a number of "sweat shops," and I've worked in several places where long hours and rhinoplastic intimacy with the grind stone were demanded of the team. I can honestly say that hard work makes no long-term difference to failing software development teams.

I disagree with those who say that long hours are 100% detrimental to software development: I''ve seen lots of situations where people worked around the clock, motivated by passion. But those were successful projects.

I've learned that redoubling effort when a project is in trouble has not fixed the project. The conclusion I draw is that although teams have worked long hours on many successful projects, there is no causal relationship between long hours and success (It's another example of the fallacy of "best practices": copying a single element of a successful project does not guarantee that another project will be improved).

My experience with failing projects is that the exhortation "Ahh, I'm going to have to go ahead and ask you to come in on Sunday, too..." has always been interpreted as punishment, not a meaningful way to fix the project. It has had no effect on under-performing members of the team and tends to strongly demotivate the people who are pulling more than their fair share of the weight.

It is impossible to sharpen a pencil with a blunt axe. It is equally vain to try to do it with ten blunt axes instead.

Good luck convincing stakeholders of this. One of the reasons people love to hand out overtime like candy is that hours in the office are measurable. The team's behind? Make them stay until midnight every night. Even if it doesn't work, the executive handing out this order can be sure she can measure compliance.

The bottom line is, it's easy to measure how many axes you're using to sharpen a pencil. When you discover that a blunt axe isn't sharpening the pencil, how do you propose to measure "sharpness"? How do you measure "working smarter"?

If we wish to count lines of code, we should not regard them as lines produced but as lines spent.

So another thing I've learned about failure is that when things start to go wrong, stakeholders want two things:

1. New processes
   
2. A way to measure compliance with the new processes

Overtime meets both criteria nicely, as do other simple panaceas like generating reports with every build or compliance with coding standards.

Fixing failing projects demands lots of things that are easy to measure and some that aren't. I've learned that if you don't control your stakeholder's expectations around change, you'll find yourself fending off demands for things like overtime and reports.

History

Even when my proposals are seen as significant improvements, they are often rejected on the grounds that they are not intuitive. It is a classic Catch-22: The client wants something that is significantly superior to the competition. But if it is to be superior, it must be different. (Typically, the greater the improvement, the greater the difference.) Therefore, it cannot be intuitive, that is, familiar. What the client wants is an interface with at most marginal differences from current practice... that, somehow, makes a major improvement.

When I've been brought in specifically to "work out" a failing project I've failed when I didn't have the authority and support to make major changes. This is saying the same thing I've said several times already, but it needs to be repeated.

Often, the stakeholders have just finished casting someone into the darkness and think that they've cast failure into the darkness with him. Take a moment and look up the definition of the word "scapegoat." They may have symbolically cleansed the project of sin, but the sins remain, and I have inherited them whenever I've allowed the project to continue to do business as usual.

The most damaging phrase in the language is, It's always been done that way.

I've heard dozens of variations on the same line (yes, I've failed dozens of times!) The line is "Well, so-and-so failed because he didn't x. But now you're here, you'll get x cleaned up, and we'll start succeeding right away. We were hardly failing, really, a little behind, nothing serious."

Every time I've been told that, things have ended up being seriously dire. No, it wasn't as simple as implementing monthly sprints or formalizing acceptance tests or nightly builds. The rot went right to the core and the stakeholders were usually (unwittingly) enabling it by not understanding or being in denial of the real problems. When people don't see the depth of the problem, they don't accept the importance of making changes.

It has boiled down to something so simple that you've probably heard it described in jest as the definition of insanity. If a project has been doing things a certain way, and the stakeholders are not 100% happy with the results, doing things substantially the same way will not produce substantial changes in the results.

Finishing

There are two kinds of people in the world: those who finish what they started.

Getting back to failing early, I've learned it's important to completely fail. Get fired. Shoot the project, then burn its corpse. Melt the CVS repository and microwave the backup CDs. When things go wrong, I've often tried to play the hero from start to finish. Guess what? Some projects are doomed no matter what. Some need skills I don't possess. And some need a fresh face.

The best way to fix a bad project is to not be part of it.

I've ridden more than one project down in flames, and as painful as it is to 'fess up and admit defeat, it's important to know when to fold your cards and quit. Yes, that sounds defeatist. But most success stories are comebacks from personal failures, not wondrous turn-arounds.

Sometimes you shouldn't finish what you started. Sometimes you shouldn't finish what somebody else started.

Every essay ought to end with a summary. Since this isn't an essay, I'll end with an adaptation of a Taoist story:

A musician performed a new piece he had written for his best friend. The friend sat in wonder and listened to the entire piece. When it was over, he nodded and told the musician that the music was wonderful. But what, he wondered, did the piece mean?

The musician nodded at this question and bent over his instrument, then played the entire piece again from the beginning.

Labels: agile, passion

  ¶ 7:33 PM

  The goal of QA is to provide an ongoing induction of reality Jim McCarthy on QA:

"If QA feels its charter is to test the product that Development has created--or Development is convinced that its job is to create a product that QA then tests--some alarm bells should go off...

"QA's principal function--and it is a principal function--is to continually assess the state of the product so that the rest of the team's activities can be properly focused.

"QA's ongoing assessment is integral to the act of software creation, not an ex post facto event. Naturally, a good deal of testing and analysis is required to properly gauge status, but the goal of QA is to support the product development process by providing an ongoing induction of reality."

Labels: agile

  ¶ 4:29 PM

  How to reduce testing time From How Long Should the Testing Take?:

Here's what I have noticed from my work with multiple organizations. The groups who want to decrease testing time tend to perform the least proactive work reducing the overall number of defects...

"If you want to reduce testing time, create a low-defect product, test all the way through with a variety of test techniques, and use iterations, so you know at the end of 2-4 weeks where you stand with defects. The lower the number of defects and the more sophisticated your tests, the faster your testing time will be.

Also:

• A Measured Response: Useful Metrics to Give Managers Numbers to Back Up Project Hunches
• Testers and Developers Think Differently
• Test Driven Development

Labels: agile

  ¶ 9:51 AM

  Do programmers create intellectual property or merely transform it? The late mathematician Paul Erdös described a mathematician as "a machine for turning coffee into theorems" (Hoffman, P. The Man Who Loved Only Numbers: The Story of Paul Erdos and the Search for Mathematical Truth. New York: Hyperion, 1998, p. 7)

Once I stopped chuckling at the thought of programmers turning coffee into code, I was siezed by a question: do programmers create intellectual property or merely transform it? There is a marked difference between creating IP ("the creational model") and transforming IP ("the transformational model").

I'm going to hand wave over whether producing software is like making things in a factory. Let's grant that it may be: that doesn't affect whether programmers create or transform IP: if producing software is like a factory, we are now arguing about whether programmers produce the raw materials or simply work the machines.

In this model, there is IP that comes into the factory (perhaps in the form of "requirements" or "design patterns"), it is transformed into bits by some process, and the result is a software product of some value to consumers (by consumers I mean the users, stakeholders, and "product owners", not consumers in the broad market sense).

If programmers create IP, their ideas, designs, and problem solutions are part of the raw materials of the eventual product. If the quality of their ideas is poor, no wonderful practices or processes will save the finished work: poor programmers necessarily produce finished work of low value to its consumers (be they customers or stakeholders).

On the other hand, if programmers merely work the process, transforming IP, then the value of the finished work can be highly insulated from the quality of the programmers, just as minimum wage employees can be a part of a rigidly controlled production process. Poor programmers can produce finished work of acceptable or even high value to its consumers, provided the right process and tools are in place.

I've just talked about the effect of poor programmers in the factory. What about good or even great programmers? What about the mythical hacker? What happens when you use great programmers?

If programmers create IP, then great programmers produce great products. Of course, it is possible to screw this up with incredibly poor process (imagine a factory that collapses on its workforce), but having great programmers drives the value of the finished product on a polynomial or even exponential basis.

On the other hand if programmers merely transform IP, then great programmers will have very little effect on the value of the finished product. While they might finish work a little sooner with fewer defects, these benefits will not translate into higher value for consumers. Their efforts are somehow wasted.

I hear arguments for both models. I see this type of thinking reveal itself in the attitudes recruiters have when offering me candidates: "She has 5 years of C++ and three years of Unix, she has the experience you need."

The implication is that programming is a job with specific tasks and rote methods to be applied, like assembling parts in a factory. Requirements come dribbling down the conveyor belt, you apply the text editor and compiler tools, and the conveyor belt takes your work down the line to QA.

There are voices expressing dissent with the transformational model. One vociferous example is Joel Spolsky. Although he insists that API experience is necessary, he also insists that programmers be smart and get things done.

If I look at companies where programmers work, I see some places where the quality of the programmers (and their management) make vast differences in the value of the product they create. I also see others where the quality of the programmers makes little or no difference.

For example, start-ups need the best people they can find. Forget time to market, you have time to the next round of funding to deal with. People that get it, that can write robust software with high quality in impossibly little time can make or break a start-up, especially in this time when money doesn't rain from the skies.

On the other hand, some ISVs have relatively mature products with modest growth plans. I've heard at least one such company owner saying he'd rather have modestly skilled people with little appetite for solving hard problems. I suspect he's built his business in such a way that adding great people won't double or treble the value of his product.

And if you look at a business that isn't even in the software business, the outlook is dismal for programmers: do you realy think that delivering a big bank's application in half the time really makes a difference? Before you say "every bank wants to save $500,000 on their next big project," ask yourself why so many of them hire IBM Global Services. Not to save money.

Maybe it's because the real value of the project as measured by the people who fund it is measured in political points. And programmers don't generate politicial points, so they can't add value to the stakeholders.

So in the end I think that there's a continuum between programmers who create IP and programmers who transform IP. The difference is driven by characteristics of the environment. Specifically, it isn't "politics" or "culture" at the end of the day. It's the potential for the finished software to add value.

What does this mean if you're a software developer? If you really believe you are great, you must search for an environment where you have the greatest leverage. That's where you're going to make the greatest contribution.

Here are some key questions that have worked well for me in the past when evaluating opportunities to add value:

• Can you quantify the difference between failure, acceptable, and great performance of the project to the company? (Not yourself personally: if the project is high risk, high value, you'll have a great opportunity no matter what role you take)
• Who are the stakeholders in this project (who has the athority to make major decisions)?
• What is the impact of a project failure to the accountabilities of the stakeholders? (You won't get a straight "they'll be fired" answer in a job interview, but you can certainly get a feel for whether they care one way or another.)

The first question establishes whether there is in fact a wide range in expected outcomes of the project. If there is very little range between acceptable and great performance, then you are dealing with people who believe (rightly or wrongly) that programmers trasnform IP and that there is no opportunity to add value other than keeping your seat warm and following orders.

The second and third questions establish whether the factory's roof will stay on. The primary impediment to providing value in an otherwise promising environment in meddling from people who are not committed to the success of the project. And the main reason for a lack of commitment is having the authority to direct the project without being held accountable for the result.

Again, I believe that some factories provide an opportunity for great programmers to create IP, but some do not. And although I've cut myself short, I believe that it is possible to determine whether an environment will allow great programmers to create IP through judicious examination.

Labels: agile

  ¶ 8:31 PM

  Quiz Answers, plus "Instilling Responsibility" In Surprise Quiz!, I asked:

You have just been promoted to head of an important department in your organization. The previous head has been transferred to an equivalent position in a less important department. Your understanding of the reason for the move is that the performance of the department as a whole has been mediocre. There have not been any glaring deficiencies, just a perception of the department as so-so rather than very good. Your charge is to shape up the department. Results are expected quickly. Rate the quality of the following strategies for succeeding at your new position.

1. Always delegate to the most junior person who can be trusted with the task.
2. Give your superiors frequent progress reports.
3. Announce a major reorganization of the department that includes getting rid of whomever you believe to be "dead wood."
4. Concentrate more on your people than on the tasks to be done.
5. Make people feel completely responsible for their work.

In The Talent Myth, Malcolm Gladwell reported "how well people do on a test like this predicts how well they will do in the workplace: good managers pick (2) and (5); bad managers tend to pick (3)".

What I find interesting about this snippet is the relationship between the answers and Agile values: Frequent reporting and personal responsibility are key elements of Scrum, for example. I may be stretching here, but in my experience, one of the most valuable benefits of incremental delivery is the responsibility ethos it creates.

Yes, I know that I wrote an article where I described the benefit of incremental deliver in risk management terms. However, explaining things in dry terms "sells" better than explaining the effect on people, especially to management types. (Managers are often the least people-oriented people in the company.)

Back to incremental development. When a developer has a task, and you explain that they are on the critical path, and you show them a GANTT chart the size of the conference room wall, they're going to shrug their shoulders. Likewise, if you show them a huge baroque architecture and explain their component's place, they're again going to shrug their shoulders.

The twin problems facing us are that any task in a long, architecturally complex project suffers from a lack of urgency and a lack of importance, because over the remaining time in the project lots of things can change.

There's so much uncertainty in any project more than a month long that there's absolutely no way to instill a sense of urgency until about four weeks away from a milestone. And likewise there's absolutely no importance attached to any task until people can see that deliverable functions are going to break if the task isn't completed.

When you have milestones a month or so apart, there's a constant sense of urgency around the dates. Now what about responsibility? Well, if a developer's work is due by the milestone but it's hidden away in some dusty recess of the framework, there's urgency but no importance.

To instill responsibility, you need urgency AND importance. You add the importance by tying the work as closely as possible to functionality in the finished software. When a developer can see that her work must be done in the next four weeks otherwise some function that stakeholders/users/customers want will break, she's motivated. She can take responsibility.

Thus, incremental development. When you identify increments of the finished product to be delivered on a monthly basis, you are making urgency and importance plain and visible. And oh yeas, that buys you "frequent reporting."

Maybe Agile is, at the end of the day, just good management practice.

Labels: agile

  ¶ 8:38 AM

  Surprize Quiz! Try to answer this question honestly, without trying to "reverse engineer" the correct answer. This isn't a job interview, so you gain the most if you answer correctly and learn something about yourself:

You have just been promoted to head of an important department in your organization. The previous head has been transferred to an equivalent position in a less important department. Your understanding of the reason for the move is that the performance of the department as a whole has been mediocre. There have not been any glaring deficiencies, just a perception of the department as so-so rather than very good. Your charge is to shape up the department. Results are expected quickly. Rate the quality of the following strategies for succeeding at your new position.

1. Always delegate to the most junior person who can be trusted with the task. This gives juniors an opportunity to learn and develop, raising the overall competence of the group.
2. Give your superiors frequent progress reports. This makes your star shine brightly, obtaining support from stakeholders. More importantly, frequent reports are opportunities for frequent feedback, keeping the group's direction in harmony with the organization's goals.
3. Announce a major reorganization of the department that includes getting rid of whomever you believe to be "dead wood." Letting go of "C" players is harsh, but it's just as important as hiring people who are "smart" and "get things done." The team is only as strong as the weakest link.
4. Concentrate more on your people than on the tasks to be done. Process, process, process. Experienced people know how to do their jobs, but the performance of the group depends on motivating the team and process improvements.
5. Make people feel completely responsible for their work. If no-one is accountable for results, there's no accounting for the results you'll obtain :-)

This question was crafted by Richard Wagner, a psychologist at Florida State University (I have added the italicized points to the strategies). I found the question in The Talent Myth, an excellent article by Malcolm Gladwell (author of The Tipping Point) on the relationship between talent and job performance.

Gladwell's explanation of the results, plus a comparison to my experience with Agile practices, can be found in Quiz Answers, plus "Instilling Responsibility".

Labels: agile

  ¶ 8:29 AM

  Agile is an attitude, not a product

Ken Schwaber, creator of the Scrum product development methodology (I reproduce his remarks with permission):

"At XP/AU 2004, I kept hearing the question of how to "sell Agile to the executives." I also heard a lot of discussion about "crossing the chasm," the book about the evolution of products from early adoption to mainstream to late adoption. I got a chance to talk about this with several other people (whose names I will only disclose under duress), and I had the following insight: Agile is not a product. Because it isn't a product, we shouldn't be thinking about selling it, we shouldn't be thinking about it crossing a chasm.

"Thinking of Agile as a product is particularly damaging because it will cause Agile to have the same failure that CMM had when it was viewed as a saleable commodity, as a product. People believed that they could market it and make money from it.

"People who bought it thought that they could then install it, train people on it, and then they would be better. Bob Schatz from Primavera has often pointed out that bringing Agile in is the start of an extensive change process. Deciding on Agile is a commitment to an effort, not the purchase of a solution. I've been concerned for a while about organizations having some success with Agile and deciding to go "Agile" whole hog.

"Their comments reflect a belief that Agile is something that can be implemented, solving a problem, and then they can move on. More to the truth, Agile is a commitment to collaboration, empowerment, respecting each other, courage, flexibility, facing the truth, and trust. It is about people, not products and solutions. I think people who think they can buy an "Agile" product are going to be in for a rude shock.

"I believe that Agile is part of a social revolution to help people learn together to collaboratively figure out how to work and live in an increasingly complex world. Agile is an attitude, not a product. Agile is spirituality, not a religion. We don't have to sell it as a product. We don't have to evangelize it. We simply (and with difficulty) have to live it. People will observe us and envy our joy at work, and quake in fear and be defeated by our productivity. For the old way of doing things doesn't cut it anymore. The Agile way is the appropriate response to our complex times.

"So, be wary, Our culture thinks of everything as a saleable product. It is the metaphor of our consumer society. We will fall back into thinking of Agile as a product over and over, and it will confuse our thinking. Whenever this happens to your neighbor, help them out.

Note that Primavera develop software for managing projects and portfolios in the Classical, Analytical model. And yes, they use Scrum to develop their Classical project management software, because they understand that building software is not like building bridges.

Deb Hartmann pointed out that Ken's remarks have sparked a lively thread on the Scrum Development mailing list. You can read more on line here. Warning: Intrusive Flash advertising.

Labels: agile

  ¶ 10:37 PM

  How to guarantee product failure How to guarantee product failure from Roger Cauvin lists five fatal mistakes product managers make when writing requirements. It's a fast read, and well worth the time.

The article hit home with me: I'm reviewing our development process right now. Although we do a good job of writing requirements, many of the roadblocks to shipping on time stem from the fact that we then immediately write a specification and the rest of our process is driven by the specification instead of the functional and non-functional requirements.

Labels: agile

  ¶ 8:25 AM

  How to Use Acceptance Tests to Ship Software Validation tests are tests that measure some aspect of an implementation's behaviour against an expectation and answer whether the software complies with the expectation. For example, a test that measures the time required to perform a specific task is not a validation test. A test that measures the time required to perform a specific task and compares it to a benchmark is a validation test.

One very strong benefit of using validation tests is that creating the tests forces the development team to achieve detailed and objective designs. This extends beyond the coding team to include program and product management: writing tests that validate compliance with requirements force product management to articulate detailed and objective requirements.

Thinking the requirements through in detail is more valuable than thinking the design through in detail: if the design is not solid, you will end up with a poor solution to a good problem. This can be refactored. If the requirement are not well understood, you will end up with a solution to the wrong problem: this is more difficult to change.

The two most important types of validation tests are:

• Acceptance tests, which validate an implementation's compliance with requirements.
• Unit tests, which validate an implementation's compliance with a design.

Acceptance Tests

Acceptance tests validate an implementation's compliance with requirements. One style of development is to write detailed requirements and then translate the requirements into acceptance tests. When the requirements are sufficiently detailed, the acceptance tests flow freely from the requirements and the role of the team is to validate that the acceptance tests properly express the requirements.

A lightweight approach is to write less detailed requirements and to consider the acceptance tests as an extension of the requirements document. This works well in smaller organizations. When using the lightweight approach, it is important that customer or market facing contributors retain 'ownership' of the expression of requirements. A protocol I have seen work very well is for a program manager to write requirements, and then the program manager negotiates acceptance tests with the programming team.

The program manager owns the definition of the acceptance tests, and the programming team ‘validates’ the tests, raising red flags if they have concerns or cannot 'connect the dots' between the requirements and the acceptance tests. For example, a programmer is allowed to reject any acceptance test that validates an implementation rather than a requirement. This is quite properly the province of unit tests and not an issue for the program manager to determine.

Let's review this last point. Consider a high-level Market Requirements Document ("MRD"). What does it mean to "flesh out the MRD with more detail" or to "drill down into one of the requirements"? Well, it doesn't mean "write specs for a solution." That's a common pitfall: when asked for more detail, product managers get sucked into designing software.

More detail for an MRD should mean "describe the problem to be solved in more detail." The most useful detail possible is a complete list of acceptance tests.

Writing an acceptance test is easy: write a sentence that begins: "the software is acceptable when..." Now all you have to do is make sure that your acceptance test is implementation-free, just like any good requirement. This test is now a detailed expansion of some requirement. Write as many acceptance tests as you can.

For incredible leverage, automate your acceptance tests using tools like Fitnesse.

Unit Tests

Unit tests validate an implementation's compliance with a design. Since requirements are implementation-free, there should be no coupling between the definition of unit tests and the definition of acceptance tests.

Unit tests express one and only one fact, which they express in the abstract: code that is written with well chosen and sufficient unit tests can be considered of good quality and likely to be delivered on time with high confidence. Customer or market facing contributors such as program managers have an abstract interest in unit tests for this reason.

Why Unit Test are not Acceptance Tests

Unit tests should not be confused with acceptance tests, for the same reasons that

• the design should not be confused with the requirements
• the project plan should not be confused with the release plan, and,
• technical management should not be confused with product management

A design is one possible solution to the problem of "writing software that complies with the requirements." A project plan is one possible solution to the problem of "implementing a design using the available resources in compliance with the release plan." Technical management is the art of finding and implementing these solutions.

Unit tests should not be confused with acceptance tests because they do not express some requirement of the release plan: it is possible to completely refactor the design and the project plan, rewriting every single unit test, without changing any of the acceptance tests. But changes to acceptance tests reflect changes to the product contract: they are an element of the Plan of Record.

Bugs and Defects

When a release (internal or external) is tested, bugs are inevitable. A bug report expresses a kind of validation test in the negative: "the software ought to... But instead it..." A good bug report explains how to reproduce the problem: "Install the software on a dual Triton system with less an 4GB of RAM, then boot it in greedy mode..."

This is a validation test. Ideally, this test was already expressed as an acceptance or unit test. In practice, a bug report often expresses an implicit test, one that wasn't spelled out as part of the process. This is not a bad thing: tests evolve as the team's understanding evolves.

It's important to distinguish bugs that reflect shortcomings in acceptance from bugs that reflect shortcomings in design. If you look at a bug and it reflects some fundamental aspect of the requirements of the software, you need to treat it with considerably more care than a bug that reflects some shortcoming in design.

I call such bugs "defects." A defect must absolutely, positively be remedied, because if the software does not conform to the acceptance criteria, it is not "done."

For example, you may have a requirement that some aspect of the UI conform to generally accepted principles. Say there's a menu option that displays a shortcut key, but the key doesn't work. That bug is interesting. You can write a unit test for this bug: "pressing control J should invoke the Jump command."

But that isn't an acceptance test. An acceptance test would be "for every menu item that displays a shortcut key, the shortcut key should invoke the command." Why the generalization? Because one way to fix the broken control J would be to not display the shortcut key in the menu. The software would still conform to the acceptance test, but it would fail the unit test.

Bug reports are an excellent source of acceptance criteria, however product management and development need to analyze the tests to decide which bugs are defects and to extract acceptance criteria, just as requirements need to be analyzed to remove implementation, design, and specifications.

I'll end with one anti-pattern: if you don't distinguish bugs that reflect acceptance shortfalls from bugs that reflect implementation shortfalls, you paint yourself into a corner where you cannot manage the bug list: all you can do is try to fix as much as you can and hope for the best.

If you separate the defects out and give them their own special place in your process, you are now (a) learning more about the detailed requirements of your software, and (b) you have a smaller list of defects that must absolutely, positively be fixed. Prioritizing defects over bugs is one excellent way to raise your chances of shipping acceptable software on time.

Labels: agile

  ¶ 9:50 AM

  Selling Agile: The Difference Between Sales and Marketing There's an interesting Yahoo! Group centered around "selling" agile: convincing stakeholders and developers to adopt Agile Methods to improve their software development.

http://finance.groups.yahoo.com/group/SellingAgile/

I spent a few years as a salesman, with decent results. I recall one thing from my sales career that seems quite relevant to the 'problem' of selling organizations on changing their development culture:

Know the difference between Sales and Marketing

Sales is persuading a prospect that now is the time to act and that you are the best choice. Everything else is marketing.

What's the difference? Fundamentally, marketing lowers the cost of getting your message to prospects by publishing a fairly generic message in bulk. Sales increases the effectiveness by arranging for a sales person to engage a prospect interactively.

Effective sales companies use lower-cost marketing to educate customers about their products or services so that customers understand whether or not they have a problem and at the very least know that the company should be on the short list for choosing a solution when the customer is ready to act.

Then, effective sales companies use medium-cost prospecting (like direct mail and tele-sales) to locate customers that may make a decision in the near future. Those 'leads' are turned over to salespeople for closing.

The high-cost sales-people then have just two jobs: urge the customer to act now and urge the customer to buy from the company. If the customer needs to be convinced that there is a problem worth solving, the salesperson shouldn't be talking to the customer.

That's why salespeople spend so much time qualifying. Talk to a top salesperson. They'll tell you that there are only two skills that pay the mortgage: qualifying and closing. Everything else is secondary.

Why do we Agilists care? Because most companies don't think they have problem. Or if they think they have a problem, they think they have a personnel problem, or an estimation problem, or a discipline problem. They don't think their methodology is fundamentally broken.

By my reckoning, this is a marketing problem, not a sales problem. If you talk to these companies about Agile, you need to get them to understand that their process is broken. That's an expensive conversation. It's far, far better to market Agile to those companies. That means write books, publish weblogs, speak at seminars... All low-ish cost ways of getting the message out.

There's one big problem with this. Some Agilists take full-time jobs with non-Agile organizations and want to "sell" internally. That's a problem, because they have failed to perform the crucial first step in Sales: they failed to qualify the customer. If you want to practice Agile, you need to restrict your job search to companies that practice Agile, or at the very least companies that are hiring you because what they're currently doing doesn't work.

If your boss thinks that what you're currently doing is "not bad" or "good enough," then there's no sale to be made. You need to market, not sell. And that's a long, drawn-out proposition.

Labels: agile, popular

  ¶ 12:54 PM

  Requirements Changes and Acceptance Debt

Andre asked:

Part of agile is the idea of not complaining when the spec changes -just go ahead and make the change - even if it means rewriting a large part of the project because the software wasn't originally designed to accommodate the new requested functionality.

How do you deal with this in the real world?

In any environment where there are stakeholders, you must inform the stakeholders of their options and solicit their preference. This is true in Agile, this is also true in Classical project management. The only difference (which I will address) is your ability to handle the change.

Where Agile is beneficial is in reducing the cost so that the likelihood of "rewriting a large part of the project because the software wasn't originally designed to accommodate the new requested functionality" is lower.

How can this be so? How can Agile reduce (not eliminate) the cost?

One of the answers is by reducing Acceptance Debt.

At any one time in any project, the stakeholders will have a finite list of requirements. They will have tested the unfinished product against zero or more of those requirements. If they test, they will pronounce the product to have satisfied zero or more of the requirements.

This is acceptance testing. Code that does not contribute to satisfying one or more requirements accepted by the stakeholder is unaccepted code. Note that you must actually test, and the stakeholder must be satisfied. This eliminates "requirements drift," where you test against a stale requirements document. The stakeholder must validate the acceptance test.

During a development cycle ("iteration" in XP, "sprint" in Scrum, "release" in Classical), new code is unaccepted. You're building "Acceptance Debt" as you write every line. At the end of the iteration, you acceptance test. You eliminate the debt by proving that the code satisfies the stakeholders.

Why is it debt? Because you pay out resources and time to obtain code. You're "out of pocket" until the stakeholder accepts that the code satisfies their requirements.

Agile reduces Acceptance Debt in several ways. First, Agile has short iterations (2 weeks for XP, 30 days for Scrum). You have less unaccepted code at any one time. It's like being on a contract and negotiating progress payments: you have better cash flow and less risk.

Agile also eschews coding for requirements you cannot satisfy during an iteration. This doesn't mean don't think ahead and don't design, just don't write code you can't test.

Classical uses very long development cycles with little or no acceptance testing until the end of the project. Lots of unaccepted code (no, unit testing does not reduce Acceptance Debt). So Classical builds up huge acceptance debt.

So, how does lowering acceptance debt lower the cost of requirements changes?

Well, you can devise a scenario that is an exception to any generalization, but I will suggest to you that most requirements changes tend to keep substantially all of the existing requirements. One or two get lopped off and an entirely new set get added on that you didn't anticipate.

So what happens? Let's look at your acceptance debt. What happens when a requirement you haven't satisfied yet gets dropped? In the Agile world, you have no problem, because you didn't write any code to partially satisfy requirements.

This is different than the Classical World. Most Classical architects develop things in nice layers of abstractions with frameworks and delegates and tiers. So at any one time you have huge acceptance debt in the form of code that doesn't satisfy a requirement today but it might help satisfy one next month. Those architects have a problem when those unsatisfied requirements change.

So, I suggest the Agile project has less acceptance debt from unsatisfied requirements than the Classical project, because the Classical project hasn't satisfied as many requirements, and even the ones that have been satisfied haven't been accepted by the stakeholders.

Now what happens when a requirement you've already satisfied gets dropped? Some or all of the code supporting that requirement just became unaccepted, and you have instant Acceptance Debt. This is not so good. Is it the same for the Agile and Classical World?

No, it is not the same. In the Agile World the stakeholder has accepted the requirement. You didn't send her an email saying some task was done, you didn't show some demo that might have really been PowerPoint or Flash, you stress tested the Product Increment and gave it to them to use in a production setting. They know it was done.

In the Classical world they take your word for it that it was done, but the Product Increment isn't in production. How is this different? In theory it shouldn't be different, it shouldn't matter because they no longer need the software to satisfy the dropped requirement.

In practice, when the stakeholder has already accepted the product increment, they understand the wastage in a visceral sense. It's like buying a sedan, then taking it back to the dealer to ask them to cut the roof off and make it a convertible. If you already took the car for a drive, you appreciate the fact that metal must be cut and welded. But if the car hasn't been delivered yet, you just say "sorry, I changed my mind, change the car for me." The roof is the dealer's problem.

Anyways, the stakeholder is adamant, so you just piled up acceptance debt. So what? Okay, there's less debt for the Agile project. So what? In practice, this debt now weighs you down. It takes more time because you're rooting through the now unaccepted code trying to change it, without breaking anything that satisfied a requirement that hasn't changed.

So, the less acceptance debt you have, the easier it is to satisfy the new requirements. Therefore, the consequences are less, and thanks to getting the stakeholder to accept the satisfied requirements as you went along, the consequences are more visible.

This answer is already way too long, so I'll just mention three other things without explaining them. As explained above, acceptance debt adds rework when requirements change. But acceptance debt also adds uncertainty. So you have more work to do, and it's harder to estimate how much work needs to be done.

Second, the development cycles in the Agile project explicitly include re-examining requirements, encouraging changes to appear earlier. The objective is to hear about the change earlier in the process, again reducing acceptance debt.

Third, you are "test infected" on an Agile project, so as you go through the code ripping out the unaccepted stuff, you find out right away when you accidentally break something, you don't wait for weeks or months, so you again reduce uncertainty. This is very similar to what Agile developers say about the relationship between unit testing and refactoring.

Labels: agile

  ¶ 3:07 PM

  An Email Explaining a Code Review From: Reg Braithwaite-Lee
To: F---- S-------
Subject: An hour before your first Code Review at XXX

F---- :

In about an hour you will be participating in one of the most important events in your career with XXX, your first code review.

Code reviews are the foundation of team software development. The Code Review is where we have an opportunity to synchronize on what's important, what's not important, how things should work, and how much progress we are making.

Other organizations have other paths to team software development. For example, some organizations take an autocratic approach. Your manager would normally review your code personally and dictate changes to you, possibly accompanied by explanations of why the changes are important. Such companies often have "style police," architects or managers that dictate programming conventions and audit code for compliance.

We aren't going to do that. Having the team review the code together means that we can discuss the code and we can also discuss what's important and why. It's an opportunity for peer to peer communication, which is way more important and valuable to us than dictates from managers.

So thanks, you're a part of something very important.

Now that I've explained the importance of this, I want to set your expectations correctly. We are probably going to come up with a lot of 'opportunities for improvement' with your code. Why?

Well, for starters, there's the number of eyes. You look at your code with two eyes. A group looks at it with twelve or twenty eyes or more. It's almost impossible for anything to be so perfect nobody can suggest an improvement. And quite frankly, if you're optimizing every algorithm, you may be working on perfection at the expense of goodness.

Another reason has to do with synchronizing our ideas of importance. Do you know what I think is important to the success of the project? You probably have an incomplete idea. I probably have an incomplete idea of what you think is important. T--, A--, E--, and S-- probably have other ideas.

Under the circumstances, there's probably no piece of code that would meet with everyone's approval. Quite likely, the code you write does a good job of expressing your idea of what's important. If you can express your own ideas, you are coding well.

Part of this review will be discussing what is important and why. That way, we will all share the same ideas. And the next piece of code you write will express those shared ideas. As will the next piece of code S-- or O-- writes.

I want to stress that developing software in a team environment is an ongoing process of refinement and improvement. It simply doesn't work to try to 'start at the finish.' For example, you could have taken the weekend, interviewed me extensively, and rewrote your code to express my ideas. But such a body of code wouldn't help the team learn and communicate.

So it's better for XXX that we 'follow the path' and 'take each step once.' And you're a big part of our next step.

Once again, thank you in advance.

Labels: agile

  ¶ 7:40 AM

  Defining Tasks with Acceptance Tests Here's an email from a few years back:

From: Reg Braithwaite-Lee
Sent: Monday, August 28, 2000 6:52 PM
To: XXX
Subject: RE: Software

XXX wrote:

I have a software guy who is undisciplined - he wants to just be left alone and write software to his spec.

Any tips and hints there for me? :)

The terse response is that you must be synchronized on expectations.

My practise is to set up "acceptance tests." An acceptance test is a written understanding of what it means for a piece of software or task to be "done." An acceptance test has a Boolean output: pass/fail, done/not done.

Acceptance tests start with a one sentence executive summary. The best acceptance tests strive to be objective "The sort function shall be deemed to have acceptable performance when it can demonstrate sorting 100,000 randomly generated strings in x seconds or less."

When you and the developer have agreed on a one sentence summary, you drill down to specific tests. You can probably dictate the summary, but the developer should participate as a reasonably equal partner in fleshing out the tests:

"The sort function shall be deemed to have acceptable performance when it can demonstrate sorting 100,000 randomly generated strings in x seconds or less:

Random strings to be in a text file, one string per line, strings to be 10 characters long. Standard Unix conventions. Test to be run using a simple shell that reads the entire file into RAM before timing the sort. Timing will be established using the systemTimeInMilliseconds() function. The test is a pass if the time for the sort is less than x milliseconds. The machine for the testing will be any of our usual testing systems (currently YYY running Linux)."

Large point: I forbid coding until the acceptance test has been signed off. Moving ahead is tempting for the developer and the manager, but resist! I also do not accept any time estimates for a task that does not have acceptance tests defined. How does (s)he know how long it will take if you haven't agreed on when it will be done?

Small point: for some tasks, setting up and writing the tests takes as long as the coding. This is normal, and an acceptable cost of development. It is a false saving to thug on ahead to avoid the "overhead" of acceptance tests.

Medium Point: Tugging over acceptance tests is an important part of the development process: it is a valuable brainstorming activity and quickly identifies what is important and what is not.

p.s. Something like a sort requires multiple acceptance tests. Here's another for the sort function:

"The sort function shall sort strings into alphabetical order:

Random strings to be in a text file, one string per line, strings to be 10 characters long. Standard Unix conventions. A sorted copy of the file will be generated using Unix standard sort. Test to be run using a simple shell that reads the entire file into RAM and writes the sorted result to a file. The veracity of the sort will be validated by comparing the output with the Unix sort version. The machine for the testing will be any of our usual testing systems (currently YYY running Linux)."

---

Looking back, I didn't really address my friend's concerns directly. First, there was the concern of 'his spec', as in the developer's spec. That's really what this email addresses: making sure that the developer is working on the right thing.

There's another entire problem of 'being left alone', also known as 'going dark.' My email doesn't address that problem at all. Perhaps I'll post something on that topic in the future...

Labels: agile

  ¶ 8:21 AM

  Hazards of Hiring Hazards of Hiring

An excellent article with a balanced look at the hiring process. The author runs a small ISV, so you get a highly pragmatic perspective.

Labels: agile, jobs

  ¶ 10:00 AM

  What's all the fuss with the build process? Hello!

You may have overheard C****, D*****, and B**** talking about overhauling the build process lately. What's all the fuss about?

The short answer is, we want to cut the amount of time required to develop O---- core and add ons, while increasing quality. So we look around, and what do we see? Smart people working hard. So the answer is NOT work harder. The answer is "work smarter."

Of course, not everyone agrees on what it means to "work smarter." Some people might come in here and tell us we need more UML diagrams, or throw out the C++ and start again with a so-called "better" programming language, or perhaps move everybody into their own offices and remove the telephones.

Those suggestions have some merit, but if you look around you'll find some companies that do very well using those ideas, and some that do very well doing the opposite. Let's put those kinds of suggestions aside for the moment. They might work for us, they might not. The problem with those suggestions is that they don't come with much of a guarantee. We have to study them a lot harder before trying any of them.

There's another kind of suggestion, like "hire the best people you can find." Almost every company that ignores this suggestion fails to ship software. It seems to be a "best practice." It comes with a good track record. Suggestions for producing software faster with higher quality that have good track records are priorities for us.

So back to the build process. I'm going to share a FACT with you. If you want to research this yourself, spend a few minutes with Google using keywords like "continuous integration" or "daily build." Here's the fact:

Companies that build their software more often produce higher quality products, faster.

Here are some opinions backing up this fact:

http://www.stevemcconnell.com/bp04.htm
http://www.joelonsoftware.com/articles/fog0000000023.html

Please read them both. All of them. It'll take you less than sixty seconds each. I'll wait while you read them. There will be a test later.

*****

Did you read them both? You didn't? You'll get to them "later"? Come on, read them right now, I'll wait, I really will. Take two minutes and make yourself a more professional programmer!

Okay, you've read them. Thank you. Wasn't that worth it?

Now, hopefully you're excited about daily builds. You might even want to build more often. XP zealots actually say "daily builds are for wimps": they build as they go, triggering a build dozens of times a day. Great. But we have to start somewhere. And that's why we're taking a hard look at our build process and working towards building at least once a day.

So... When you hear talk of the build process, you now know what's going on: we're "working smarter".

You read the articles, right? So you can tell me:

1. Jim McCarty wrote a book that mentions the daily build. What's its name?
2. When projects get really big, the build takes a long time. If you have more than five million lines of code, should you still do daily builds, or is your project too big for this technique?
3. Joel has a test for engineering group. How many questions are in his test?
4. Extra bonus: what's our score in the "Joel Test"?
5. Extra bonus: where can you get Jim's book?

Labels: agile

  ¶ 8:07 AM