Project Collaboration Requires Intent and a Shared Language

May 4th, 2003 by Hal

Johanna Rothman writes about Software Product Development. In a recent posting Language (and Language Environment) Influences Process Johanna writes about the suitability of (software) language for collaborative bottoms-up development. Change a word or two, here and there, and she could have been writing about architecture.


At Symbolics (I left in 1990), we practiced incremental development, iterative planning, and some forms of pair programming. Why? Because the language, LISP, encourages this. It's easy to make small changes. It's easy to take what you have and try something. It's easy to walk someone through small functions and then have that person explain what else you could do. It's easy to grab someone and show them what you have already working, even if other parts don't work yet.

But once I figured out the basics of writing software in LISP, I became a much better project manager. I understood how easy it was to break things into small pieces and write products from the bottom up, rather than the top down. I understood how the engineers needed time to experiment. I could help them timebox their prototype activities. Even though I wasn't a LISP expert, I could use my knowledge of the environment to help the engineers create a product development process that worked.

If you're not happy with your projects, look at the language and environment you use. (Y)ou can create an environment that creates a helpful process — one that allows the technical staff to create small pieces, test them, and build on them. We know that successful software development occurs when we build small pieces from the bottom up and check those pieces with the customers. Make your project environment help your technical staff create successful products.

So what does this have to do with architecture? or any engineer-to-order project? Maybe nothing, or everything. Johanna writes about using a programming language that makes it easy to collaborate and to work from the bottom-up. (Is there any other way to deliver projects?) Not only is LISP suitable to this style of development, I'd dare say the language anticipates a bottoms-up collaborative approach. Not all software development is collaborative and bottoms-up, just like not all architecture and engineering is collaborative and bottoms-up. The language helps. A pattern language for architecture and engineering would help collaboration. However, what's more important is an intent to collaborate and design or engineer from the bottom-up.

The linguistic action perspective to managing projects is a general approach for collaborative bottoms-up planning, and therefore so is the Last Planner System™. There is an intention to let the project evolve as project team members learn with each other while delivering on the promises to the customer. Supporting that intention is a set of practices, like Johanna's description of LISP, that make it easier to start and continue to collaborate and work from the bottom-up.

If you are not sure about the reasonableness of working in this manner, then think back to the last project that for whatever reason ran off the track. What did you do to right that train? If you are like most, then you got the folks together who were executing the project and asked them what they would do. Why not start out this way? Choose an approach (or language) that supports an emergent approach to project delivery.

Related Posts

Social Bookmarking
Add to: Folkd Add to: Linkarena Add to: Digg Add to: Del.icio.us Add to: Reddit Add to: Simpy Add to: StumbleUpon Add to: Slashdot Add to: Netscape Add to: Furl Add to: Yahoo Add to: Spurl Add to: Google Add to: Blinklist Add to: Blogmarks Add to: Diigo Add to: Technorati Add to: Newsvine Add to: Blinkbits Add to: Ma.Gnolia Add to: Smarking Add to: Netvouz Information

Comment On This

Note: This post is over 5 years old. You may want to check later in this blog to see if there is new information relevant to your comment.