Notes on Karlin's and Matt's Talks

Carl Erickson, Atomic Object

Karlin's "Systir Test Framework"

Karlin Fox, Atomic Object software journeyman, talked about the domain specific language approach to system testing and the Atomic Object Systir framework during the second half of the November meeting.

This is a talk Karlin gave recently at the Ruby Developers Conference.

Karlin started with a demo of Systir. A website for ordering pizza was run through its paces with a system test in the Systir framework using Watir as the driver.

TDD is for developers. SDD (story driven development) is for customers. Expressing stories as system tests lets you use them as acceptance tests, and it requires you get good definition on your specification (stories) since you automate their execution. In other words, SDD keeps your requirements and your code synchronized.

Systir encourages writing acceptance tests incrementally, as you develop. It’s lightweight and easy to get going in (assuming you learn a little Ruby first) and can be extended as the need arises.

Typical vendorscript (as Bret Pettichord has called it) is specific to a vendor and may be a poor general puprose language. Systir scripts are DSLs in Ruby, so the full power of Ruby is available as needed.

Matt Heusser pointed out that Systir scripts are executable English, hence not as ambiguous as human language requirement specs.

Systir DSL == Application ideas + User domain language + Testing/programming skills

A Systir DSL grows from an ongoing collaboration between a customer and a toolsmith.

David Crosby pointed out that redundancy can be added to the DSL to make the customer’s test writing/reading easier. For example, the DSL for checking out in a shopping cart could be either “check out as” or “check out by”. It’s easy to define and allow both phrases.

Systir tests can be data-driven or imperative. The best approach depends on the application and the customer defining the tests.

Fit (Ward Cunningham) is another test automation tool for doing SDD. Compared to Systir, Fit supports only a data-driven approach to system tests. Fit’s great for this, but sometimes the imperative approach is more powerful and expressive.

Systir’s been used for a variety of web apps, for a complex Java server, and for a large C#/.NET GUI application.

Karlin wound up with a dive into the famous Mondo pizza website, the system tests for it, and the Ruby driver suporting the Mondo DSL.

Matt’s "Magic Pixie Dust"

Innovation is about redefining a task, or the way a task is done – Gerald Weinberg

Programmers that innovate are going to disrupt things a bit. How do you encourage that and not let it sidetrack the organization?

Is innovation at odds with high levels of process maturity? [Perhaps the self reflective, feed-improvement-back-into-the-system aspects of higher CMM levels would cover process and technology innovation?]

Status meetings are 20 people in a room, sequentially reporting for 5 minutes each. So for 20 person hours of human resource you get a couple hours of knowledge sharing. [Makes our standups look highly efficient.]

An ambiguous spec is one that is written in English – James Bach.

Efficiency is a false god. Without an infinite length work queue there will always be some downtime for developers. So to be efficient, companies size their development groups to always have work to do. So imagine when a call comes in from a customer, reporting a bug. Help desk person enters the bug. A few weeks later the QA person has time to check out the bug. Now the trail is cold, so it’s harder to repeat and understand, and the customer isn’t available. Finally the developer finds and fixes the bug, submits it to the QA person for change control. They’re busy, so it takes a while before they can check out the fix and submit it to the next release build. Sometime much later the customer may get the bug fix. So the efficient organization can have rather bad responsiveness. “Slack”, by Tom DeMarco advises organizations keep 10% idle time to improve performance.

Multitasking results in higher average completion time for projects. And that doesn’t count task switching overhead. [Simple results from OS class – shortest job first scheduling results in lowest average completion time.]

Johana Rothman – at 2 tasks, people are only 40% effective. At 5 tasks they are not effective at all.

Kevin Hykin cited data that said 2 concurrent projects is good, but going over that results in inefficiency.

Lesson from parenting: forcing your will on another human isn’t as effective as communicating choice and consequences.

Every large, painful, deadfish project has a series of lively, effective, fun projects just dieing to get out.

Developers do have power. Bosses don’t control everything. Offer choices to customers, encourage them to prioritize. Use five magic words: “I’ll get back to you” when pressed for detailed time estimates in meetings. If you can’t do something, don’t commit to it.

"Magic Pixie Dust" and "Systir Test Framework"

Matt Heusser, Karlin Fox

When: November 22nd, 2005, 6:00 pm – 8:00 pm Where: Atomic Object, 941 Wealthy Street SE, Grand Rapids, MI 49506

“Magic Pixie Dust: Improving the pace of development through people,” Matthew Heusser

Companies tend to mis-understand innovation because innovation disrupts process. So if your goal is a defined, stable, repeatable process, you’re going to stifle innovation. This talk describes an alternative to an unthinking, brain-dead, factory-like process for software development: One that relies on creativity and personal excellence to constantly improve the way we develop software.

“Systir: domain specific language approach to acceptance test automation” Karlin Fox, Atomic Object

Systir is a framework for developing domain specific language for building system and acceptance test frameworks for diverse applications. Atomic has used Systir for large C#/.NET applications, diverse web apps, and complex, networked Java servers. This talk with demonstrate the development and execution of Systir tests.

Notes on Andy Lester's Talk

Carl Erickson, Atomic Object

Andy Lester gave a great talk last night. This is clearly a hot-button topic as there was lots of discussion and questions afterwards. Some things I thought were valuable from his talk:

The importantance of adapting practices to fit the circumstances. Andy’s team uses lightweight, homegrown tools for estimation and tracking that would be familiar to any XP team. But unlike the planning game in XP, they do more work up front and they don’t have the customer steering the project from iteration to iteration. It works for Follett.

Fred Brooks is not god. Well, actually he might be, but the jury is still out. Transparency and honesty are essential to successful projects. Andy’s techniques (decompose, estimate, plan a week’s work, plot burndown over time) give a realistic view into project status. The point of the exchange on the divinity of Fred Brooks was if you provide the management a view into the true state of the project they may actually be able to add developers to the team early enough achieve a positive outcome for projects that are behind schedule.

“Iterative releases don’t work!” (long quiet pause in the room, kind of like the old Sprint pin drop commercials) This statement of Andy’s turns out to not be blasphemy but rather semantics. They can’t release to the end customer until the application is complete. But they do internal iterative releases for all the same reasons we do.

Technical debt flattens the velocity curve of projects towards the end of the project. This is why all tasks/stories should be in one of two states: completely done or not started. A bunch of 90% done stories represent technical debt building up. Toward the end of the project this debt comes due, with interest, and project velocity goes to zero as the team spends all their time fixing things they already took credit for in earlier iterations.

Accurate estimates aren’t free. Developers need to help customers understand that accurately estimating a problem is difficult and takes time. At Atomic Object we find that accurately estimating a project requires decomposition and design, and sometimes experiments. All of this takes time; in effect you start solving the problem to estimate it.

Estimation isn’t magic, but it is. Or at least that’s how I started thinking about it. Yes, it’s hard to do accurately (Andy’s got a favorite impression of developers who refuse to estimat the size of a task…) But doing something (even a SWAG) buys you an awful lot. And the process really isn’t magic. Break the big rocks into little rocks and keep breaking until you’ve uncovered as many rocks as possible and each rock is big enough to get your brain around and estimate. A simple process, really, but one that can be the foundation for what we refer to as data-driven project management.

"Preventing Crisis: Project Estimation and Tracking That Works"

Andy Lester

When: October 25th, 2005, 6:00 – 8:00 pm Where: Atomic Object, 941 Wealthy Street SE, Grand Rapids, MI 49506

Crisis is always bad, even when you manage to solve the problem. Crisis always reflects poorly on you and your department.

It’s almost a truism that development crises happen, but you don’t have to work in a Dilbertesque hellhole. Crisis prevention must be an integral part of everything you and your department do. You’ll learn how to:

• Keep management off your back so you can get real work done.
• Make honest schedules everyone can live with.
• Track your progress effectively to avoid 11th hour rushes.
• Stop your project from stalling, or sliding backwards.
• Handle change requests without stress.
• Go from scapegoats to rock stars.
• These techniques have all been proven under fire, and draw from a number of methodologies.

Speaker Bio

Andy Lester (PetDance) has been a professional programmer for nineteen years and Perl evangelist for a decade. As one of the core Perl developers, Andy’s interests in Perl focus on quality assurance. He maintains eight testing modules on the CPAN, as well as the Perl QA website (http://qa.perl.org). Andy is a frequent speaker at the O’Reilly Open Source Convention, YAPC, and at Perl Monger meetings around the country. He’s spoken around the US on a variety of programming topics including automated testing, Perl security, web agent automation, project management, and effective job searching for programmers. Andy has written or edited for a dozen books. Three of his articles on his popular WWW::Mechanize module are included in O’Reilly’s “Spidering Hacks”. Andy has also written articles for every single Perl magazine published in the US (both of them). By day, Andy manages a crack squad of web programmers for Follett Library Resources (http://www.titlewave.com) in McHenry, Illinois. He lives with his wife Amy, daughter Quinn, and Baxter, the world’s neediest dog.

Reprise of the Agile 2005 Denver Conference

Carl Erickson and Panelists

When: September 27th, 2005, 6:00 pm – 8:00 pm Where: Atomic Object, 941 Wealthy Street SE, Grand Rapids, MI 49506

Welcome back to the start of XP West Michigan’s 3rd season!

Come to the September meeting to learn about Agile 2005 and:

• The surprising mix of attendees and what that might mean • Brian Marick’s observation on careers for agile people • The birth of the Agile Project Leadership Network • Which branch of the government uses agile to great effect • How agile and big up front design work together • The optimal frequency for switching pairs when pair programming • Bob Martin’s view on where agile is heading • What to do when the client gives you a “crazy” story • The best sort of contract for agile software development • How agile beats waterfall when you’re on a raft • The importance of rituals • How to best sneak agile development in the front door • How companies are using agile practices in embedded development • What Kent Beck obsesses about

How can we pack all this into one meeting? The Denver Agile conference in July 2005 was a watershed event in the agile community. XPwm’s September meeting offers those who couldn’t attend this important conference the chance to hear what went on and learn directly from those who were there. Carl Erickson will summarize the conference and moderate a panel discussion by people from Atomic Object and Priority Health who participated in the conference. We’ll have plenty of time for questions and discussion, so come ready to learn. September at XPwm – the next best thing to Denver.

PS – We’ll also be unveiling our new community-oriented website.

"The Top Six Reasons Software Projects Fail and How to Avoid Them"

Rich Sheridan, Menlo Institute

When: May 24th, 2005, 6:00 pm – 8:00 pm Where: Priority Health Conference Center, 3111 Leonard NE

Does your management team know the top six reasons software projects fail? Do they know what practical steps can be taken to avoid them? Management edicts will not create the teamwork required to produce useful software on-time and on-budget. Instead, teamwork must be facilitated through a thoughtfully constructed process.

This program offers some practical insights into how to use agile development techniques to:

• Have a continuous dialog with sponsors during the course of a project.
• Get users directly involved while leaving them where they are. Make planning a continuous process rather than a one time event.
• Avoid the unrealistic expectations that usually come with large software projects.
• Build a highly effective and flexible software team that actually embraces changing business requirements.
• This session will also explore how to:
• Support business goals and improve return on investment using simple project planning tools.
• Build better software with less money, less meetings and less costly mistakes.
• Increase communications with fewer meetings.
• Energize the team and delight users at the same time!
• Put business in control by giving them a steering wheel on development efforts.

The presenter will be Rich Sheridan. As President of Menlo Innovations, Rich, along with his three business partners, formed a company around the passions of building great software and great software teams. He has sponsored dramatic changes to existing teams using techniques from many sources, including Extreme Programming. He has focused on improving the culture, productivity and results of teams with which he works. His experiences as the Vice President of R&D at Interface Systems were captured in the book “Creativity at Work” by Jeff DeGraff and Katherine Lawrence of the University of Michigan Business School. It came at a time when Interface Systems was named the #1 public company in Michigan. Rich is a graduate of the University of Michigan where he received a BS in Computer Science and a Master’s Degree in Computer Engineering. Rich has focused his attention and energy on the power of open and collaborative work spaces as originally practiced by Thomas Edison. Edison’s lab in Menlo Park, New Jersey was the inspiration for the company name. The dramatic success of Menlo, during one of the hardest times for the information technology industry, captured the attention of Forbes magazine, where Rich appeared on the cover in May, 2003. He was recently named one of the top 100 emerging business leaders of the Metro-Detroit region by the Detroiter magazine. An excellent speaker and presenter, Rich readily shares his knowledge and successes from real-world experience. He is now scheduled to be a Guest Lecturer at the U of M Business School. Rich Sheridan, Menlo Institute

"Analytical School of Testing” and “All-Pairs: a Closer Look"

Paul Jorgensen, Grand Valley State University

When: April 26th, 2005, 6:00 pm – 8:00 pm Where: Priority Health Conference Center, 3111 Leonard NE

Dr. Paul Jorgensen of Grand Valley State University will be the speaker at the April meeting of XP West Michigan. Paul will describe what Bret Petticord calls the Analytic School of Testing, and then will take “A Closer Look at All Pairs Testing”. The analytic approach to testing contrasts with Michael Bolton’s March talk on the context driven school. (Sorry, no halos, devil’s horns or magic tricks, but Paul is usually good for a joke or two.)

All Pairs is a method to achieve high test coverage with far fewer test cases than all combinations would require. James Bach’s simple perl tool that helps construct All Pair tests cases will be demonstrated.

Speaker Bio

Paul is a full professor in the School of Computing and Information Systems at GVSU, and is Chair of the School’s graduate program. He also knows something about software testing, and is proposing a third edition of his book, Software Testing-A Craftsman’s Approach.

Satisfice.com - the source for the all-pairs perl implementation demo’d at the meeting is James Bach’s company site.

"Two Futures of Software Testing"

Michael Bolton, DevelopSense

When: March 22nd, 2005, 6:00 pm – 8:00 pm Where: Atomic Object, 941 Wealthy Street SE, Grand Rapids, MI 49506

Niels Bohr, Woody Allen, or Yogi Berra (and perhaps all three) once said “Prediction is very difficult, especially about the future.”

Michael Bolton rises to the challenge and dares to present TWO futures of software testing.

In one vision of the future, testers are the gatekeepers, responsible for assuring product quality. Testing follows a rigourously controlled process, and ad hoc testing is banned. Testers are kept separate from the developers to foster independence and objectivity. Senior testers work from extensively detailed specifications, creating plans, drawing state diagrams, and compiling test scripts from the inception of the project until coding has finished. At that point, any tester, no matter how junior, can read and follow the scripts-testing can even be entirely automated-so that management can be sure that the code is bug-free. All decisions will be based on solid numerical data. Changes to the product will be resisted so that risk can be eliminated.

This vision, which contains a number of truly bizarre fantasies, is the DARK vision of the future.

In the other view, testers are active investigators, critical thinkers, and highly skilled, valued members of the project team. Testers neither accept nor desire responsibility for releasing the product; instead,testers provide important, timely, credible information to managers so that they can make sound and informed business decisions. Testers work collaboratively not only with the developers, but with the entire project community, and are able to report at any time on product and project risks. Testers have an extensive understanding of tools and automation, and decide when-and when not-to use them. Most importantly, testers embrace challenge and change, adapting practices and strategies thoughtfully to fit the testing mission and its context.

Where are we now, and where are we going? In this interactive presentation, Michael shares his visions of the futures of software testing, and the roles of the tester in each of them. The presentation includes a brief exercise and a dialogue, encouraging discussion and debate from the floor.

Speaker Bio

Michael Bolton provides training and consulting in Rapid Software Testing. He writes about testing and quality in STQE Magazine (most recently in the September 2004 issue), TASSQuarterly, and in his own newsletter.

He is the only person authorized and endorsed by James Bach to teach his Rapid Software Testing course. Michael was an invited participant at Cem Kaner and James Bach’s Workshop on Teaching Software Testing in Melbourne, Florida, 2003.

He is Program Chair for the Toronto Association of System and Software Quality, a presenter at this year’s Amplifying Your Effectiveness conference in Phoenix, and a member of Gerald M. Weinberg’s SHAPE Forum.

Michael can be reached through his Web site, http://www.developsense.com

"Agile Requirements Gathering"

Dave Limbaugh, Priority Health

When: February 22nd, 2005, 6:00 pm – 8:00 pm Where: Priority Health, 1231 East Beltline – 3rd Floor

Struggling with one of the hardest aspects of software development?

Don’t miss, “Agile Requirements Gathering,” presented by Dave Limbaugh, Technical Project Manager at Priority Health at the next XP West Michigan meeting, Tuesday, February 22.

Dave will be running an exercise from the 2004 XP Agile Universe conference held in Calgary. This will will be a fun, participatory exercise where you can experience the difference between requirements gathering using traditional versus agile methods.

The meeting will last from 6 pm to 8 pm with a 15-minute intermission for networking and socializing.

Priority Health is hosting the event. They are located at 1231 East Beltline in Grand Rapids. The meeting will be held on the 3rd floor of Building 1231.

Priority Health occupies two buildings. Building 1231 is located on the front part of the property, closest to East Beltline. Use the entrance (glass doors) located at the front, eastern side of the building.

"Agile Overview" and "Acceptance Testing with Fitnesse"

Robert Martin, Object Mentor

When: January 22nd, 2005, 6:00 pm – 8:00 pm Where: Prince Conference Center

XP West Michigan is pleased to present Bob Martin, nationally recognized author, speaker, and agile programming expert to our January meeting. This is another not-to-be-missed meeting you will most definitely enjoy.

His talk will be in two parts. The first part, from 6 pm until 6:50 pm, is an XP Overview that will be fun and informative for Agile novices and initiates alike. Uncle Bob will talk about why projects fail, and what Agile methods can do to prevent failure.

We’ll take a short break from 6:50 pm until 7:10 pm and enjoy light refreshments and networking in the Fireside Room adjoining our meeting room.

The second part of the talk, from 7:10 pm until 8 pm, focuses on one of the most important of the Agile practices: Automated Acceptance Testing. Uncle Bob will talk about the role of QA, and how Automated tests are the new requirements document. The talk will finish with a demonstration of FitNesse, an open-source tools for automating customer-written acceptance tests.

The meeting will be held in the Oak Room at the Prince Conference Center, located on the Calvin College campus. This building is located on the east side of the East Beltline (across the street from the majority of the buildings on that campus).

Speaker Bio

Robert Martin, a software professional since 1970, is founder and president of Object Mentor, Inc., located in Gurnee, Illinois. His company specializes in process improvement consulting, object-oriented software design consulting, training, and skill development services.

Uncle Bob is a regular speaker at international conferences and trade shows and has authored or edited numerous books and trade journal articles, including:

• Designing Object Oriented C++ Applications using the Booch Method
• Patterns Languages of Program Design 3
• More C++ Gems
• Extreme Programming in Practice 
• Agile Software Development: Principles, Patterns and Practices

Uncle Bob’s presentation style is entertaining and humorous, yet highly educational.