Test Abstraction Smells

In our article Test Abstraction: Eight Techniques to Improve Your Tests (published by PragPub), we whittled down a convoluted, messy test into a few concise and expressive test methods, using this set of smells as a guide. We improved the abstraction of this messy test by emphasizing its key parts and de-emphasizing its irrelevant details.

Stripped down, the "goodness" of a test is largely a matter of how quickly these questions can be answered:

• What's the point of this test?
• Why is the assertion expecting this particular answer?
• Why did this test just fail?

That's a nice short-form summary, but it is descriptive rather than prescriptive. In the Pragmatic Bookshelf article, a real-world code example was used to painstakingly demonstrate the techniques used to improve the clarity of tests by increasing their level of abstraction. Here we provide the "cheat sheet" version:

• Unnecessary test code. Eliminate test constructs that clutter the flow of your tests without imparting relevant meaning. Most of the time, "not null" assertions are extraneous. Similarly, eliminate try/catch blocks from your tests (in all but negative-case tests themselves).
• Missing abstractions. Are you exposing several lines of implementation detail to express test set-up (or verification) that represents a single concept? Think in terms of reading a test: "Ok, it's adding a new student to the system. Fine. Then it's creating an empty list, and then adding A to that list, then B, and ..., and then that list is then used to compare against the expected grades for the student." The list construction is ugly exposed detail. Reconstruct the code so that your reader, in one glance, can digest a single line that says "ensure the student's expected grades are A, A, B, B, and C."
• Irrelevant data. "Say, why does that test pass the value '2' to the SUT? It looks like they pass in a session object, too... does it require that or not?" Every piece of data shown in the test that bears no weight on its outcome is clutter that your reader must wade through and inspect. "Is that value of '2' the reason we get output of '42'?" Well, no, it's not. Take it out, hide it, make it more abstract! (For example, we'll at times use constant names like ARBITRARY_CHARGE_AMOUNT.)
• Bloated construction. It may take a bit of setup to get your SUT in the state needed for the test to run, but if it's not relevant to core test understanding, move the clutter out. Excessive setup is a design smell, showing that the code being tested needs rework. Don't cope with the problem by leaving extensive setup in your test, but tackle the problem by reworking the code as soon as you have reasonable test coverage. Of course, the problem of untestable code is largely eliminated through the use of TDD.
• Irrelevant details. Is every step of the test really needed? For example, suppose your operational system requires the presence of a global session object, pre-populated with a few things. You may find that you can't even execute your unit test without having it similarly populate the session object. For most tests, however, the details of populating the session object have nothing to do with the goal of the test. There are usually better ways to design the code unit, and if you can't change your design to use one of those ways, you should at least bury the irrelevant details.
• Multiple assertions. A well-abstracted unit test represents one case: "If I do this stuff, I observe that behavior." Combining several cases muddies the abstraction--which setup/execution concepts are relevant to which resulting behaviors? Which assertion represents the goal of the test case? Most tests with multiple assertions are ripe for splitting into multiple tests. Where it makes sense to keep multiple assertions in a single test, can you at least abstract its multiple assertions into a single helper method?
• Misleading organization. You can easily organize tests using AAA (Arrange-Act-Assert). Remember that once green, we re-read any given test (as a document of SUT behavior) only infrequently--either when the test unexpectedly fails or when changes need to be made. Being able to clearly separate the initial state (Arrange) from the activity being tested (Act) from the expected result (Assert) will speed the future reader (perhaps yourself in 5 months) on his way. When setup, actions, and assertions are mixed, the test will require more careful study. Spare your team members the chore of repeatedly deciphering your tests down the road--spend the time now to make them clear and obvious.
• Implicit meaning. It's not all just getting rid of stuff; abstraction requires amplifying essential test elements. Imagine a test that says "apply a fine of 30 cents on a book checked out December 7 and returned December 31." Why those dates? Why that amount? If we challenged you to tell us the rules that govern the outcome of this test, you'd likely get them wrong. A meaningful test would need to describe, in one manner or another, these relevant concepts and elements:
  
  • books are normally checked out for 21 days
  • Christmas--a date in the 21-day span following December 7--is a grace day (i.e. no fines are assessed)
  • The due date is thus December 29
  • December 31 is two days past the due date
  • Books are fined 20 cents for the first day late and 10 cents for each additional day.
  • 30c = 20c + 10c
  (Consider that each of these concepts could represent a separate unit test case, and that this detailed scenario represents more of an end-to-end test case.)
  A unit test that requires you to dig through code to discern the reasons for its outcome is wasteful.

You could easily survive without our list of test abstraction smells--and figure out on your own what to do about your tests--as long as you keep one thought in your head: "My goal is to ensure that each unit test clearly expresses its intent, and nothing else, to the next person who must understand this system behavior."

The 4 Ts of Engaging Management

Teams self-organize and self-direct, so much of the Taylorist views of what a manager can do seem to not apply at all. What is the working arrangement between an agile team and their manager?

• Time (schedule) - As a steward of the schedule, a manager needs to know where the teams' effort stands--are they behind or ahead the expected schedule? Does the release need to be delayed or de-scoped? The manager is best positioned to communicate issues and evaluate the larger impact to the organization.  When the schedule needs change, we find that your chance of success is greater the earlier the matter is communicated to management. While human nature may lead one to avoid delivering bad news, it is usually better to share problems with people who are in a position to help.
• Talent (talent pool) - A manager may bring in additional talent in the form of trainers, consultants, staff augmentation contractors, or new employees. Sometimes having an eLearning course, a visiting expert, or a short-term consultant can make a huge long-term difference in the team's technical proficiency.
  A manager may change hiring criteria to bring in the kinds of developers that will help the team to work in a more fluent and productive way.
  Likewise, a manager can remove or reassign a team member who just isn't working for the current team. These kinds of issues require coordination with HR and possibly even legal representation, but are a good use of your manager's time. See also Robert Sutton's research on maintaining a productive workplace.
• Target (direction, goals) - Agility (strictly defined) is the ability to change direction gracefully. Sometimes a change of technology or target audience can greatly improve a product's chance of being accepted in the market. Additionally, agile teams would rather face failures early when they're inexpensive (fail fast) than have hopeless projects run on until resources are exhausted. Any a significant change in direction, whether cost-saving or value-creating, will need to involve management.
• Treasury (funding) - There are times that spending a few hundred or a few thousand dollars can make the difference between the team working fluidly versus struggling and slogging along. Is your biggest need for a distributed build product? A better build server? An alternative testing tool? A local version control server? More reliable intranet? A better library or framework? A minor hardware upgrade? An online training course?

When a problem can only be solved using one or more of the 4Ts, then it is clearly a management problem. Make use of your manager's sphere of influence to improve the team's chance of success.

Agile supports the empowered, competent team. The team should own their problems and push forward with solutions and data-based decision-making.  On the other hand, a team can hardly be called "resourceful" when their management assets go unused. Remember that the manager is a member of the team, and often managers pride themselves on problem-solving.

For problems in the gray area where some solutions are purely technical, it may be wise to involve management in triage. You would be surprised how many times teams have struggled with a work-around only to find that a manager would have been happy to solve the problem outright through his contacts and resources.

In your next retrospective, consider adding solution category called "take it to management." See if it helps your velocity over time.

Management Theater

Great managers can improve teams in meaningful ways: smoothing the workflow, selecting targets worth hitting, wisely managing budget and schedule, and working to align teams with organizational goals. We have fond memories of great managers, technical or otherwise, who led and mentored us, who helped us reach new plateaus of understanding and productivity.

We're not talking about those great managers today.

Instead, we'll discuss a particular form of management dysfunction often seen in development shops. Daniel Pink (in Drive) points out that programming shops are full of people who are motivated by the work and excited to make progress. Intrinsic motivation tends to be quite high, though exceptions exist (see Esther Derby's Stop Demotivating Me). Most shops face problems with procedure, organization, technological limits, overly ambitious schedules, and shortage of knowledge or practice. Less astute managers don't understand the problems in their teams, and misinterpret these as motivational issues. When the problem is technical, it does not help to attempt solving it through motivation.

You've probably been a witness to most of these. Just in case they're not obvious:

• Begging: "Please, I just really need you to work harder to get this done. Just this one time."
• Browbeating: "Stop your whining and get it done before I replace you with someone who gives a darn about their job!"
• Cheerleading: "I have faith in you, you're the best! Go Team!"
• Punative Reporting: "I want to see daily status reports! Twice daily!"
• Publicity Stunts: "I want every last one of us in this meeting. We need a show of force!"

Such motivational tactics tend to be ineffective. To people struggling with difficult organizational and/or technical problems, emotional appeals seem to be a kind of buffoonery. Of course, if the team succeeds despite the management theater, it merely strengthens the causal connection in the manager's mind. By simply not failing, the team locks their manager into a pattern that ensures that all future crises will be met with emotional and ineffective responses.

We should not be asking how to make managers behave. We should be asking what a team can do to ensure that a manager can provide effective servant leadership. Management theater is not a manager's first choice of action, but rather a tactic of last resource. When a manager does not have sufficient information or timely opportunity to be effective, she must use whatever ethical means remain. Management theater is, therefore, primarily a process smell not of management but of the development team.

Worldwide shortage

I'm told that there are shortages of AgileInAFlash, some channels having projected waits of as much as two months for replenishment.

You can still get AgileInAFlash physical decks at the Pragmatic Programmers site, and you can also pick up electronic copies there to tide you over. The electronic version is not as handy in mentoring settings, but is fine for reading or projecting.

Second Printing

Thanks to the demand of our readers, Agile In A Flash is going to its second printing only 8 months after its initial release. Thanks to all of you!

Mobile Version

Thanks to our hosts at blogger.com, we now have a mobile version, so accessing Agile In A Flash from your mobile device is finally easy and even pleasant.

Doctor Dan's Prescription

Dr Dan's Prescription: An Agile Flashcard a Day keeps the Fail away...

This photo of card #33 was received via twitter from Daniel Thomas (@geekdan) in Brisbane, Australia, complete with the quote above.

I like how they have a low-tech "frame" for the cards, and a place of honor on the team whiteboard. I hope they get some help, humor, or inspiration from the deck.

Dan tweets a lot of interesting links. Give him a follow.

A Card-Enriched Workspace

Friend of the blog Brian Kelly offers us a glimpse of his workspace. I notice that the books on organizational change are above the card on overcoming organizational obstinance, and that the rest are values and practices cards.

The new website-only card, Five Rules for Distributed Teams, is shown on the monitor.  It was released coincidentally with Lisa Crispin and Nanda Lankalapalli's StickyMinds article on Tele-teams. I guess the distributed team meme is in the air.

Brian is the fellow who has been posting the excellent near-daily meditations on the 52 cards of the official Agile In A Flash deck released by Pragmatic Programmers in late January of this year.

We are very proud, indeed.

Rules for Distributed Teams

As the Greatest Agile-In-A-Flash Card Wielding Coaches So Far^(tm), we're often asked for advice (or drawn into arguments) about how to make agile work with distributed teams. Sometimes it's for more humble reasons, though: We've both been remote members of a team, pair-programming with peers daily. We prescribe the following rules for distributed development:

1. Don't. Traditional organizations should avoid the extra strain, trouble, and expense of remote members without a significant reason. For example, building a better team using remote rockstars might provide some justification, but you might also be better off with a capable, local team that works well together. It's often out of your control, though, and in the hands of a really big boss, bean counter, or entrenched culture. You can make it work: Virtual organizations, startups, and the like find great success using virtual tools, pairing, and non-traditional communication pathways. Make sure you really mean it, because it's not a trouble-free add-on to the way your large organization does things now.
   
2. Don't treat remotes as if they were local. Treat your "satellite" developers as competent people with physical limitations. A remote is visually impaired, since he can only see through a web cam, and only when it is on. He cannot see the kanban board, the other side of the camera, and so on. Likewise, he only hears what is said into the microphone and not at all if simultaneous conversations occur. A remote cannot cross the room and talk to people, so interoffice chat (Skype, Jabber, etc) is essential. The local team has to make concessions, repeat conversations, and be the eyes and ears of the remote employees. Do not treat unequal things as equal--accept that there are compromises.
   
3. Don't treat locals as if they were remote. You certainly can install electronic kanban boards, online agile project management tools, instant messaging, cameras, email, and shared document management so that every local can sit alone in a cubicle or office and behave just like a remote employee. Rather than being empowered, you are all equally limited (see point #2). Never limit so that all are equal. Allow all to rise to greatness. The power of people working closely together in teams is significant (see first bullet above).
   
4. Latitude hurts, but longitude kills. Just being remote hurts (see first two bullets), but the complications can be overcome when employees share the same time zone and working hours. The further you move the team across time zones, the fewer common hours they have, and the longer any kind of communication takes to make a round-trip. Agile is predicated on short feedback loops, so 24-hour turn-around is out of the question. If you can't be a single team that works together, create separate agile teams.
   
5. Don't always be remote. Begin your engagement with a nice long on-site visit. A week is barely enough. Two weeks starts to make it work. Visiting for one week a quarter or even a week a month can keep a feeling of partnership alive. Dealing with difficulties is easy among people who know and respect each other. While constant telepresence (Skype, Twitter, IM, etc.) can minimize the problem of "out-of-sight, out of mind," studies show that distributed team success requires teams with strong interpersonal relationships, built best on face-to-face interaction. The bean counters may not be able to comprehend it, but the investment is well worth the return.

Tim: Would I remote again? In fact, I do most of my Industrial Logic work remote. We are in constant touch with each other and pair frequently. I converse with Joshua Kerievsky more in the course of a week than I have any other "boss" (he'll hate that I used that word!) in my employment history. We even work across time zones. We would work more fluently and frequently side-by-side, but we'd probably not get to work together if we all had to relocate. It is a compromise that has surprisingly good return on investment for us. We also have the advantage that we are all mature agilists; it would be very hard for first-timers. It's hard for me, as I have a tendency to "go dark" sometimes.

Jeff: I enjoyed a year of remote development with a now-defunct company one time zone to the east. Pairing saved it for me. The ability to program daily in (virtually) close quarters with another sharp someone on the team helped me keep an essential connection with them. On the flip side, however, I never felt like I was a true part of that team. I missed out on key conversations away from the camera, and I felt that debating things over the phone was intensely ineffective. You do what you must, but I'd prefer to not be remote again.

Card-Carrying Agile Team

Top row: Chris Freeman, George Sparks, Sudheer Pinna, Scott Splavec, Sreehari Mogallapalli, Matt Poush.
Bottom row: Toran Billups, Ryan Bergman, Andrea de Freitas, and Benoy John
Photographer: Vadim Suvorov

Say hello to the team from Sum Total. Back before acquisition, the company was known as GeoLearning, and Tim was one of the coaches to help with their transition to Agile methods. Later, while working on Agile In A Flash, Jeff and Tim were both employed as remote pair-programming team members. The team has done some remarkable things in just the past three years.

Vadim (an excellent developer, brilliant guy, friend) reminds me that he is present in this photo as a reflection in the eyes of all the developers who are standing in front of the camera. If this were a TV detective show, you could zoom in and see him clearly.

Card-Carrying Scrum Master

Dion Nicolaas (not pictured) displays the Agile in a Flash cards on his desk in the TomTom headquarters in Amsterdam, the Netherlands. Showing a different card each day, he has inspired some colleagues to order their own decks!

Daily Meditations

On twitter, follow "buildndeploy" (Brian Kelly) for a daily meditation on Agile In A Flash. Well, mostly daily. He has a day job, and we certainly forgive a missed day. Brian is going through a card a day (when possible) and providing an 140char summary of his thoughts. Follow along by card number (use this index, or your own deck) and see what buildndeploy has to say.

Brian is using our hashtag #agileinaflash, so it is easy to catch up with his prior reflections.

Getting Better (guest blog post)

Today we have a short article from our guest blogger Johnno Nolan, who caught our attention in twitter when he said:

Great 2 hear the team talking soft dev. We go through an Agile in a Flash card every am and critique. Can feel devs caring again

Johnno Nolan's story is still in progress, but I felt that tweet was inspirational enough that I invited him to provide a short blog post, and he kindly submitted the following story.

I've worked here before. We developed with chaos. I left. They persuaded me to come back. They said it would be different. "We can do things a different way. Your way" they said. The chaos would be mine to tame. I accepted and returned.

The cold reality set in. The team was demotivated, resigned to the current system. Worse, we'd tried to implement 'Getting Better' before (I don't like to use the term Agile) but we'd lack courage and when the main change driver had gone, adoption fell by the wayside. There was mistrust, ignorance of doing things that way and then the team was asked to pick back up where they left off. So there's a been an open dialogue of what's been wrong and we've been focusing on the basics to 'Get Better'.

And we are.

I can look back a couple of months and we were not talking, not thinking, just accepting of the norm. Now we're learning together. Sometimes we have bad days, but today was a good one.

Before our stand-ups meetings we talk about one Agile In A Flash card. They say story cards are a placeholder for a conversation and that's exactly how we use them. We don't always agree with the card but we talk about it and try and understand. The cards provide a focal point.

Today was really productive, we finished more than we expected. We passed stories back because we didn't think they were good enough. We talked about design. We returned to the cards and talked more about process. For the first time in months we cared and we're proud of what we are doing.

We're not becoming Agile in a Flash but we're Getting Better Steadily.

Jeff and I are receiving several stories every week about how Agile In A Flash is helping teams re-engage with fundamentals. We'll be entertaining other guest bloggers in the future, in addition to providing some fresh content every month.

Card-Carrying Network Weaver

A welcome to Patrick Wilson-Welsh, seen enjoying his new deck of Agile In A Flash cards at the Agile And Beyond gathering in Dearborn, Michigan, where I dare say we had the most interesting table full of people in the entire room. Patrick really wanted these cards. Let us know how they're working out for you!

Card-carrying Agile Tester

This is Lisa Crispin, brilliant Agile tester and author, trainer, and early adopter of Agile In A Flash. Here you see her sharing deep testing insights with Jo, Edgar and Chester.

No animals were harmed or insulted in the making of this blog post.

Agile On A Desk

Dave Rooney, a card-carrying friend of Agile In A Flash, walked into a manager's office and what do you suppose he saw?

The astute observer will see all the cards are marked with either the compass rose ("The Plan" section) or else a waving pennant ("The Team" section). We intended those two sections to be especially interesting and useful for managers.

It does our hearts good to see Agile In A Flash in use. Your encouragement is always welcome here, in pictures, comments, tweets, purchases, or referrals!

Card-carrying Professional Scrum Developer Trainer

This is Andreas Ebbert-Karroum who is busy in Germany, leading codecentrics Agile Software Factory. He looks very happy to have his Agile In A Flash deck.

Card-carrying Team Effectiveness Amplifier

Say hello to George Dinwiddie. George is a well-known and well-respected software development coach and consultant, software blogger, and a Card-carrying Team Effectiveness Amplifier, and a friend of the Agile In A Flash effort (not to mention the authors).

Can you feel how the warmth of his personality radiates from this picture? Yeah, he's like that in person.

Restoring The Trust

Make sure you see Uncle Bob Martin's video Restoring The Trust, about the agile balance.  A certain deck of cards is prominently featured (thanks, Bob!) in the opening and closing moments.

There are a few other cards relating to balance, but clearly the Manifesto card is very close to Bob's heart,  as he is one of the original authors and signers of the both Craftsman and Agile manifestos.

Card-carrying Seer of System Dynamics

(in dramatic Black & White, no less!)

This is Esther Derby, a management consultant and Agilist who is helping companies to put a more human face on software development. We highly recommend her conference talks and blog. Here Esther has a brand-new deck of "Agile in a Flash" and a happy smile.

What's On Your Wall?

Tim describes how the Agile In A Flash cards help make his workspace more informative.

Agile in a Flash Card Index

In order to keep Agile in a Flash very low cost and actually make a buck or two, Tim and I were pressured to keep the number of cards to a very minimum. That's why you'll see no author bios, for example, and no index / table of contents. (Of course, if the book takes off and you buy bajillions of copies, we can likely justify an index.)

Without further ado, here's the index of cards (which also tells you, by omission, which blog entries here are not in this deck--if, uh, all goes well with sales, we'll be doing a second deck):

The Idea:

1. Why Agile?
2. The Agile Values, aka the Agile Manifesto
3. Principles Behind the Agile Manifesto
4. Role-Playing in Agile
5. Agile Success Factors
6. Courage
7. Redefining Discipline
8. Pillars of Software Craftmanship
9. Toyota Production System (TPS) Principles
10. The Right Process
11. Got Organizational Obstinance?
12. Got Individual Obstinance
13. Don't Get Too Deep in Technical Debt

The Plan:

14. Incremental Everything
15. Embrace Change
16. Reach Consensus on Story Priority
17. INVEST in Your Stories
18. Categorize Requirements with FURPS
19. Sail on the Three C's
20. Shrink XL Stories to Fit
21. Acceptable Acceptance Tests
22. Acceptance Test Design Principles
23. Story Estimation Fundamentals
24. A Winning Hand for Planning Poker
25. Iterate with Principle
26. Communication-SMITH with Information Radiators

The Team:

27. Shu-Ha-Ri
28. The Only Agile Tools You'll Ever Need
29. Successful Stand-up Meetings
30. ABCs of Pair Programming
31. Retrospectives
32. When Not Pairing
33. How to Be a Team Player
34. Collective Code Ownership
35. Coding Standards
36. Is Your Team Circling the Drain?
37. Pair Programming Smells
38. Stop the Bad Test Death Spiral
39. How to Stay Valuable

The Code:

40. Eight Crucial Practices of Agile Programmers
41. Build Superior Systems with Simple Design
42. The Seven Code Virtues
43. ReallyMeaningful Names
44. The TDD Cycle
45. FIRST Properties of Unit Tests
46. Triple A for Tight Tests
47. Prevent Code Rot Through Refactoring
48. Refactoring Inhibitors
49. Field Guide to Mocks
50. Break Unit Test Writer's Block
51. Test Double Troubles
52. TDD Process Smells

How to use the deck

People have been asking how to best use the cards in their teams.

We've had several notes via twitter or email about teams reading and discussing them at retrospectives or standup, and even using them in lightning talks at conferences.  We are happy to see them used in this way.

But people have been asking how normal, individual, non-coach team members can use the cards. Jeff provides our recipe for use of Agile in a Flash:

• Pick a card that's relevant and read its front
• Read the back
• Re-read the front to help ingrain the short list
• Consider tacking the card up, so that it's in your face, helping you ingrain the concepts
• Seek and re-read related cards to get a more complete picture of the topic
• Visit the corresponding post here on the blog site if you seek more detail on the topic and why we said some of the things we did
• Visit the links located on many of the cards and at the blog site if needed

Don't forget to google the subject matter, because there is more written than we could fit in either the deck or the blog. Other opinions and recommendations are equally valid.

Please share and discuss the cards with your community, starting with the local software team and its neighbors but extending to conferences, user groups, or any other willing listeners. New insights can come from anywhere.

Javaranch Event

The Big Moose Saloon welcomes writing team Ottinger and Langr to a special event:

This week, we're delighted to have Jeff Langr & Tim Ottinger helping to answer questions about the new book Agile in a Flash. See this page for a description of the book.

The promotion starts Tuesday, February 22th 2011 and will end on Friday, February 25th 2011.

We'll be selecting four random posters in this forum to win a free copy of the book provided by the publisher, Pragmatic.

Please see the Book Promotion page to ensure your best chances at winning!

Sit in, ask or answer some questions, see if you can't win your free Agile In A Flash deck. If you don't win one, don't worry. We still have a few left for sale.

Sighting Report

From an undisclosed location in Des Moines, Iowa, comes this sighting report. It is likely a book store, judging by intact plastic wrap and "Alphabetical By Author" sticker on shelf. It also looks like they're down to their last copy. Snag it now, before their supply is totally exhausted!

Card-Carrying Mad Railer

David van Leeuwen, Card-carrying Mad Railer, shows off the new deck of Agile In A Flash that he won in a drawing at the Madison, WI conference.

Lisa Crispin and Courage at Belgium Testing Days

Our deck of cards makes a surprise appearance at Belgium Testing Days 2011 thanks to Lisa Crispin and her experience with the Courage card.

It is pleasing to see the cards having a supporting role in the lives of respected professionals, and to see them appear in a testing conference instead of a more predictable place like an Agile or programming conference. Markus Gärtner provides descriptions of several talks in this blog.

Card-Carrying agile author

Jeff Langr, programmer geek and computer addict shows off his Agile in a Flash deck in front of a warm fire in Colorado Springs. Look, Ma, no shrink-wrap! Tim, have you opened yours yet???

Card-Carrying Embedded Software Engineer

Card-carrying embedded-software engineer James Grenning, fellow-author, fellow-ex-ObjectMentor consultant, owner of Renaissance Software, great guy.  Here James shows off his deck of cards at a Starbucks near Mundelein, IL.  Doing embedded software, but don't know how to do it test-first? See James Grenning (and buy his book Test Driven Development for Embedded C to be released very soon).

Card-carrying Rocketeers

Card-carrying Hash Rocket team members show off their deck of Agile In A Flash cards gifted to them at their office in Chicago.  They are a really great, kind, competent group of people worthy of your business. Tim loves their open workspace and open hearts.

Card-carrying Django Developer

Card-carrying Django developer, Cezar Jenkins, shows off the autographed deck he won at the Chicago Python users group meeting. His superior memory allowed him to edge out the other attendees and seize the prize!

Card-carrying Agile Author

Card-carrying agile author and programmer, Tim Ottinger, smugly shows his plastic-wrapped Agile In A Flash deck at home.  Tim is the originator of the Agile In A Flash concept, and co-author of the deck with Jeff Langr (without whom this project would have died on the vine). Feeling smug? You betcha.

Card-carrying software journeyman

Card-carrying software journeyman, Corey Haines, shows off his deck and a broad smile at a Chicago Starbucks outlet.

Getting the Word Out

By now, many of our readers (perhaps all) have recieved copies of the Agile In A Flash. The feedback we have received has been very positive and we are very encouraged. I understand that a few decks even traveled to the Agile Manifesto event in Salt Lake City.

Our goal is to get this tool into the hands of coaches, trainers, managers, product owners, and development teams all over the world. Since the book has only been out for less than one month, we don't have a lot of information about our sales, but we know from twitter that we are selling on several continents and that people are finding value in the books.

Our goal is to get the cards in the hands of the people who are really doing the work: your project team and its neighbors in the business where you work. If you are interested in helping promote the Agile In A Flash project:

• Let your employers know that you are getting value from the deck, and maybe ask to outfit the whole team!
  
• If you are a member of a user group or software interest group of any kind, talk to us about promotional give-aways. We might hook you up with discount coupons or maybe even a deck or two. 
• On Feb 22, Java Ranch is holding a promotional event for us. Join us!
• A review at your favorite on-line book retailer will encourage others to try Agile In A Flash.
• Keep us in your tweets and status updates.
• Send us a "Card Carrying" picture. We'll post them here. Maybe someone will be inspired!
• Send us your great promotional ideas. We're all ears.
• This blog could use a Digg or Reddit or HackerNews vote.
• Vote us up at CodeBix

Anniversary

Agile In A Flash is published in the 10th anniversary year of the Agile Manifesto. It hit the shelf only weeks before the reunion gathering in Salt Lake City. We thank the original authors and signatories for providing us with a good foundation for our practice, and we look forward to whatever lies ahead.

Join the celebration by popping over to the Tenth Anniversary site. Read the articles, check out the photos, and join the dialog.

Two Agile Works that Work Great Together

Have you seen The Agile Samurai yet? We're currently reading it, and really enjoying it. You may see some new Samurai-inspired cards on this site in coming weeks. Jonathan Rasmusson has had kind things to say about Agile In A Flash as well.

Pragmatic programmers have recognized the value of these two works together, and offer a special deal on the physical works tucked away in their latest podcast announcement:

Don’t forget our special discount on our latest agile-themed titles. Save 35% on the paperbacks if you purchase both Agile in a Flash and The Agile Samurai. Just put both paperback books in your cart, and the 35% discount will be automatically applied. While supplies last. Does not apply to prior purchases, or to ebooks; do not read while operating heavy machinery, pages may be slippery when wet.

The Big Four

There are many concerns for software design and architecture, including functionality, scaling, performance, extensibility, backward compatibility, platform compatibility, future-proofing, the list goes on and on. However, for a system to continue to be workable (maintainable, readable, extensible, correctable) there are primarily these four large concerns.

Software developers have pondered the question of "design rot" as long as there has been software, and have realized that the internal structure of a software system is vitally important to its continued success, just as external factors are critical to user acceptance.

Object-oriented design has provided tools for managing continued workability, but many developers today have not received a well-grounded education in software structure. They are instead pushed to make software that lacks internal structure, but works and is appealing in concept or user interface.

We are presenting a series of articles via the Pragmatic Bookshelf magazine, which we hope will fill in the gaps:

• Cohesion
• Coupling
• Abstraction
• Volatility

Promo Video Contest

Tim and I aren't videographers (although I do like his video, see the previous post in this blog). Nor are we in real, day-to-day teams right now (I'm doing on-customer-site consulting, tough to get permissions and such). So we're looking for someone to provide us with a cool video that shows your team's use of Agile in a Flash, and helps promote the book.

We're offering as a prize a ten-pack of cards ($110 at PragProg) for the video we choose as the best. In return, you'd grant us rights and permissions to use the video and whoevers' likenesses for promotional use.

Please email me (jeff at langrsoft.com) if you have any further questions about the contest.

Contest deadline: February 28, 2011

Legal stuff: This is all arbitrary, and Tim and I reserve all rights, including the right to not choose a video if none suits our promotional needs.

The Deal

Agile In A Flash is not a replacement for coaching, training, consulting, and those wonderful books that my colleagues have written.  Agile in a Flash is a great way to get started, and a great tool for coaches, trainers, and consultants to use in teaching Agile software development to their clients and colleagues.

This is our first released video about the cards. Stay tuned.

Released.

It's here! After a few years of writing, a lot of editing, a bit of promotion, and a whole lot of work, Pragmatic Programmers has released Agile In A Flash.

To our knowledge there is not another product like this one anywhere in the world, on any topic. We've worked hard to make something useful and unique for our Agile community. We have spent a lot of time on format and form factor, phrasing, clarifying points when possible, and weeding out the cards that seemed less useful. As a result of our extreme culling and revisits, you will find powerful advice in a surprisingly small package.

Pragmatic Programmers helped us to make it affordable for teams and companies alike, and individual copies are not out of "impulse purchase" range.  This was a departure from their normal publishing activities, but they believed in it and did a lot of legwork to make it possible.  They've been supportive and amazing, and I hope you will reward them with your custom.

Thank you for your comments, reviews, tweets and retweets.  Today the project is entirely "real" and we appreciate all our readers have done (and may continue to do) to make this crazy little idea work.

New PragProg article: Code Coupling

Our latest in our series of "big ideas in software" is now available and appearing in the PragPub January 2011 issue. This is the second article out of four, each covering one of cohesion, coupling, abstraction, and volatility. In this article on coupling, we talk about the impacts of too many dependencies in your software, and what you can do to prevent it.

In addition to the HTML version, you also find PDF, epub, and mobi versions of the article here.

Agile in a Flash is slated for publication on January 20! You can advance-order now from Amazon; you'll also soon be able to order in bulk, at a discount, from PragProg directly (and this is the kind of thing for which you'll want a separate copy for everyone on your team).

Meanwhile, Tim and I are banging out the next article, on abstraction, in the series. If you have any advance thoughts on what you'd like to see covered, drop a comment here or send us a line.

Thanks for reading!