February 2009

A Software Commons

Where are the places where all stakeholders can meet? Not a physical place, but artifacts, tools, etc.

Assuming that our stakeholders are comprised of customers, developers, testers, database, support, and deployment working in their own silos, what is the common ground between any two?

Worst case:

Customer Developer Tester Database Suppport
Customer - Requirements Requirements Requirements Requirements
Developer Application - Application DB Schema Application
Tester Bug Report Bug Report - Bug Report Bug Report
Database DB Schema DB Schema DB Schema - DB Schema
Support Application Application Application DB Schema -

We can see that in a worst-case, siloed organization, the conduit for communication can differ. Even between two stake holders, the conduit can differ depending on the flow of information (e.g., the conduit between Customer and Support is not the same as Support and Customer). Each conduit is a chance for miscommunication.

So, the common ground between any two can vary. What if we have an idea or issue that spans several silos? More and possibly very different artifacts will have to be taken into account. Because these artifacts were created by different groups, there’s a good chance there is going to be miscommunication and wasted effort.

Now, let’s tweak the terms like “Requirements”, “Application”, “Bug Report”, and “DB Schema” for a best-case description of said artifacts/conduits:

Requirements: Description of what the Application should do with runnable examples and text
Application: The system that will be deployed for users, as well as all the tests, set up scripts, etc
Bug Report: Automated, report-as-soon-as-you-find-it test failure
DB Schema: The DDL and DML used in the database in support of the Application

What we really need is something that takes the best-case description of the artifacts and holds them in a common area for all of the stake holders. This common area would be the spot where we all can talk the same talk, manipulate the necessary artifacts, and if need be, see the appropriate “view” (as a Customer, as Tester, etc…) of the software as a whole.

Where/what is this commons? Well, it doesn’t fully exist yet. Things like Fit, FitNesse, and BDD almost get us there. The next generation of tools such as Twist get us even closer.

Extension is about Consumption

The next time you are about to extend a class, stop and think about who is going to be consuming this extended class. If the extended class (instead of the base class) is in the contract amongst collaborators, why the extension?

If, somewhere along the line, you want your extended class to be used (consumed) as the base class, go ahead and extend. If that isn’t the case, then maybe composition should be preferred.

It really comes down to this:

Extension is about consumption.

Disconnect!

Quick–how many of your tests would fail if you were not connected to a network (for database, files, services, etc)? How many of these are labeled as “unit tests”?

Do you have a way of quickly determining which tests are dependent upon that network connection? Can you easily run all the tests that aren’t dependent upon the network? Do you find that there are errors/failures in surprising areas?

Try it and see. You may learn something interesting about your code’s dependencies.

Purge!

Quick–when was the last time you just deleted the directory for you project(s)? Could you do it right now without any problems? What would you need to recreate your set up?

Once you have your setup, it seems pointless to spend any more time trying to make it easier/faster to create said setup. And maybe it is for *you*. But, the next person coming along probably won’t consider it pointless.

Be hardcore. Purge that stuff right now and see what you need to do to get going again. You’ll find out quickly what you (and your new team member, your CI, your deployment team, etc) need.